CVS via ssh down...
This isn't meant to criticize, but having to go on IRC to figure out that SSH is down until further notice isn't exactly a great way to run a service, I know it is the weekend (I do most of my work on the weekends) but a mail to one of the mailing lists or something in the News page on the main freedesktop.org site in future might be helpful, I assume Daniel is waiting for 2.4.27 to be released, did someone mention getting access via pserver? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
drm latest function table patch..
The latest patch against the drmfntbl-0-0-1 branch of the DRM is at http://www.skynet.ie/~airlied/patches/dri/drm_ftbl_latest.diff This will be checked into the branch when fd.o gets sorted out... It dumps: DRIVER_CTX_[CD]TOR HAVE_KERNEL_CTX_SWITCH DRIVER_BUF_PRIV_T DRIVER_AGP_BUFFERS_MAP I haven't fixed up BSD in my tree yet, I'm not sure what to take aim at next (probably a dragon in nwn...), but HAVE_CTX_BITMAP and maybe the MTRR ones... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm latest function table patch..
Dave Airlie wrote: The latest patch against the drmfntbl-0-0-1 branch of the DRM is at http://www.skynet.ie/~airlied/patches/dri/drm_ftbl_latest.diff This will be checked into the branch when fd.o gets sorted out... It dumps: DRIVER_CTX_[CD]TOR HAVE_KERNEL_CTX_SWITCH DRIVER_BUF_PRIV_T DRIVER_AGP_BUFFERS_MAP I haven't fixed up BSD in my tree yet, I'm not sure what to take aim at next (probably a dragon in nwn...), but HAVE_CTX_BITMAP and maybe the MTRR ones... Dave. In via_drv.h and i830_drv.h, if somethings gone, it should be removed properly, not just commented: +// drm_map_t *buffer_map; Otherwise, looking good. Keith --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
On Fri, 6 Aug 2004, Jon Smirl wrote:
This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most video
drivers) please give this patch a try and send some feedback/bugs.
pci_map_rom() - map the rom and provide virtual address, transparently
return shadow/copy if needed. Normal drivers call this
pci_map_rom_copy() - same as pci_map_rom except the ROM will copied,
future reads of ROM will use copy. Hardware with minimal decoding calls
use this
pci_unmap_rom() - release the ioremap if there is one
The ROMs also appear in sysfs and you can use hexdump to see them.
If the Radeon ROM is all . Load a radeon device driver and it will
appear. Radeon cards have a bug that loading the driver will fix.
+unsigned char *
+pci_map_rom_copy(struct pci_dev *dev, size_t *size) {
+ struct resource *res = dev-resource[PCI_ROM_RESOURCE];
+ unsigned char *rom;
+
+ rom = pci_map_rom(dev, size);
+ if (!rom)
+ return NULL;
+
+ if (res-flags (PCI_ROM_COPY | PCI_ROM_SHADOW))
+ return rom;
+
+ res-start = (unsigned long)kmalloc(*size, GFP_KERNEL);
What's the maximum size of a PCI ROM? Larger than kmalloc() can handle?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Gwe, 2004-08-06 at 18:16, Jon Smirl wrote: fbdev is in exactly this model and it isn't causing anyone problems. The simple rule is that if you want to upgrade fbdev past the current version you have to do it in entirety. You do that for fbdev but pulling bk://fbdev.bkbits.net/. But Joe user doesn't do that, that is something only developers do. And thats one of the big reasons its such a mess and doesn't work out. Nobody is testing or reviewing it until some huge merge point occurs at which point you run the risk of people saying Actually your design sucks, or in the 2.6 case finding out too late so that there is a patch kit to upgrade your 2.6 to the 2.4 console driver --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Sat, Aug 07, 2004 at 01:11:21AM +0100, Dave Airlie wrote: fbdev only has one distribution vector - the kernel, DRM has multiple distribution vectors, kernel, DRI snapshots, X releases, they all contain their own DRM modules, also people with older kernels should be able to which is the root problem. Make sure the kernel is the canonical source and all those problems magically disappear. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 05:54:52PM +0100, Keith Whitwell wrote: Yes, while I support the current rework and de-templatization of the code, I don't support any attempt to split the drm modules to try and share code at runtime - ie. I don't support a core/submodule approach. We had that argument already in 2000/2001 when we had the big XFree 4.1 DRM update. There's no reason drm should be different from all other kernel subsystems. If you really fear this is a problem add a monotonely increasing DRM_VERSION define for driver to check against and even better don't make any not backwards-compatible changes unless you're doing a major version bump. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 12:54:26AM +0100, Dave Airlie wrote: I guess one (unpleasant) way to make it work would be to add the version to all the symbols in the device-independent layer. Instead of drm_foo you'd have drm_foo_100 or drm_foo_101 or whatever. You could then have multiple modules loaded or a module loaded with a built-in version. I'm not sure how happy that would make the kernel maintainers (not to mention how happy it would make us). :( It's basically like what we have now, except the current code has the device's name add to all the symbols and is built into the device-dependent module. Ugh, ugh. How do other multi-layer kernel modules handle this? For example, how does agpgart or iptables do it? Just make sure the driver core and subdrivers are always in sync. That's an entirely sensible thing and how all other subsystems with lowlevel calls work. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Sat, Aug 07, 2004 at 02:31:07PM +0100, Alan Cox wrote: And thats one of the big reasons its such a mess and doesn't work out. Nobody is testing or reviewing it until some huge merge point occurs at which point you run the risk of people saying Actually your design sucks, or in the 2.6 case finding out too late so that there is a patch kit to upgrade your 2.6 to the 2.4 console driver Sorry, but the reason for the fbdev mess is that James is completely unable to do proper project managment. The model works fine for every other kernel subsystem. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
Maximum size of a standard PCI ROM is 128KB. On non-x86 platforms the
code will pick the length up from the size of the PCI window. That
window has no limit.
On the other hand, map_rom_copy is only called by the device driver for
a board that has minimal PCI decoding. The PCI spec allows the address
decoding for something like the ROM and framebuffer to be shared. A few
vendors have implemented this and the result is that you can't read the
ROM and framebuffer at the same time. This is why you need to make the
copy. We only know of a couple PCI boards that have implemented this.
This memory is not performance critical and can be swapped, is there a
better way to allocate it?
--- Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Fri, 6 Aug 2004, Jon Smirl wrote:
This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most
video
drivers) please give this patch a try and send some feedback/bugs.
pci_map_rom() - map the rom and provide virtual address,
transparently
return shadow/copy if needed. Normal drivers call this
pci_map_rom_copy() - same as pci_map_rom except the ROM will
copied,
future reads of ROM will use copy. Hardware with minimal decoding
calls
use this
pci_unmap_rom() - release the ioremap if there is one
The ROMs also appear in sysfs and you can use hexdump to see them.
If the Radeon ROM is all . Load a radeon device driver and it
will
appear. Radeon cards have a bug that loading the driver will fix.
+unsigned char *
+pci_map_rom_copy(struct pci_dev *dev, size_t *size) {
+ struct resource *res = dev-resource[PCI_ROM_RESOURCE];
+ unsigned char *rom;
+
+ rom = pci_map_rom(dev, size);
+ if (!rom)
+ return NULL;
+
+ if (res-flags (PCI_ROM_COPY | PCI_ROM_SHADOW))
+ return rom;
+
+ res-start = (unsigned long)kmalloc(*size, GFP_KERNEL);
What's the maximum size of a PCI ROM? Larger than kmalloc() can
handle?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
[EMAIL PROTECTED]
In personal conversations with technical people, I call myself a
hacker. But
when I'm talking to journalists I just say programmer or something
like that.
-- Linus Torvalds
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes
on
Linux.com, ITManagersJournal and NewsForge in the past few weeks?
Now,
one more big change to announce. We are now OSTG- Open Source
Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
On Fri, 2004-08-06 at 16:09, Alex Deucher wrote: did you have those problems with DRI cvs or are they new with xorg? The streams code has be reshuffled a bit. also try with option BCIForXv false (or something like that; I forget the exact name). Don't see any changes with option BCIForXv false. The duplicated/translated image is new, a small problem in xine with xv is old, happens with DRI cvs and still with xorg. Only the old little problem happens with DRI cvs and still in xorg, but could a xine problem. thanks I'll look into it as soon as I get a chance. Alex Testing some 3D games emilia pinball, foobillard and Chromium works perfectly. you can found the new problem on tuxracer and quake3 demo. hope that can help something thanks, thanks for testing. testings are welcomed, I'll try help you, where I could help you. sorry for my bad English. thanks, Alex best regards, -- Sérgio M. B. -- Sérgio M. B. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
On Sat, 2004-08-07 at 16:43, albert vilella wrote: I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps, is just pulling the cvs and compiling? Albert. just pulling the cvs apply this patch http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff ( I just finished the preliminary merge. It seems to work ok in limited testing. for those interested the patch is here: http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff ) and uncomment on xc/config/cf/xorgsite.def #define BuildDevelDRIDrivers YES before compiling best regards, -- Sérgio M. B. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella [EMAIL PROTECTED] wrote: I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps, is just pulling the cvs and compiling? download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then follow the mesa/xorg build instructions. build instructions: http://dri.sourceforge.net/cgi-bin/moin.cgi/Building xorg patch: http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff Alex Albert. On Sat, 2004-08-07 at 17:18, Sérgio Monteiro Basto wrote: On Fri, 2004-08-06 at 16:09, Alex Deucher wrote: did you have those problems with DRI cvs or are they new with xorg? The streams code has be reshuffled a bit. also try with option BCIForXv false (or something like that; I forget the exact name). Don't see any changes with option BCIForXv false. The duplicated/translated image is new, a small problem in xine with xv is old, happens with DRI cvs and still with xorg. Only the old little problem happens with DRI cvs and still in xorg, but could a xine problem. thanks I'll look into it as soon as I get a chance. Alex Testing some 3D games emilia pinball, foobillard and Chromium works perfectly. you can found the new problem on tuxracer and quake3 demo. hope that can help something thanks, thanks for testing. testings are welcomed, I'll try help you, where I could help you. sorry for my bad English. thanks, Alex best regards, -- Sérgio M. B. -- jabberid [EMAIL PROTECTED] --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
On Sat, 2004-08-07 at 17:08, Alex Deucher wrote: On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella [EMAIL PROTECTED] wrote: I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps, is just pulling the cvs and compiling? download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then follow the mesa/xorg build instructions. build instructions: http://dri.sourceforge.net/cgi-bin/moin.cgi/Building xorg patch: http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff I don't know what you mean about download Mesa cvs, xorg cvs comes with one Mesa and I am using it. am I doing any thing wrong ? I use this scripts: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg login (check out ) cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -P xc mkdir build cd build lndir ../xc (create_drmkl.sh) cd build/extras/drm/linux/ sh ../scripts/create_linux_pci_lists.sh ../shared/drm_pciids.txt (if you want linux kernel drm ) cd .. scripts/create_lk_drm.sh /opt/xorgcvs/ 2.4 (or ) cd build/extras/drm/linux/ make cp savage.o /lib/modules/`uname -r`/kernel/drivers/char/drm (update cvs) cvs -q -d :pserver:[EMAIL PROTECTED]:/cvs/xorg update -P xc and finally in /etc/X11/xorg.conf Section Module # ... Load glx Load dri # ... EndSection Section DRI Mode 0666 EndSection regards, -- Sérgio M. B. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
Il Sat, Aug 07, 2004 at 07:59:29AM -0700, Jon Smirl ha scritto: *This message was transferred with a trial version of CommuniGate(tm) Pro* Maximum size of a standard PCI ROM is 128KB. This is the maximun that kmalloc can allocate. On non-x86 platforms the code will pick the length up from the size of the PCI window. That window has no limit. Hum, this is bad... what's the tipical size of video ROMs? On the other hand, map_rom_copy is only called by the device driver for a board that has minimal PCI decoding. The PCI spec allows the address decoding for something like the ROM and framebuffer to be shared. A few vendors have implemented this and the result is that you can't read the ROM and framebuffer at the same time. This is why you need to make the copy. We only know of a couple PCI boards that have implemented this. This memory is not performance critical and can be swapped, is there a better way to allocate it? Problem is that kmalloc may be unable to find many contiguous memory pages. You can check and see if the ROM is really big and use vmalloc, if not then you use kmalloc (if I remember correctly my radeon has a 4KB ROM - vmalloc would be overkill). Luca -- Home: http://kronoz.cjb.net Ci sono due cose che l'uomo non puo` nascondere: essere ubriaco ed essere innamorato. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
All of the video ROMs I have are 48KB - 64KB in size. But, the copy code is only triggered by the driver for older PCI cards with minimal decoding. I am unaware of any video cards with this problem so they won't make the copy. The only cards I seem to recall having this problem are some older QLogic disk controllers. We should fix this alloc as best as we can but most normal users will never see it. Another solution I'll add is a pci_disable_rom() call that will make the ROM disappear from sysfs. This would give the minimally decoded PCI board the option of avoiding the copy and just disabling it. The copy only needs to happen if user space apps are going to use the ROM contents after the device driver has loaded. To get the true size of your ROM look at the front of it for 55 AA the third byte is then len / 512. Fourth byte is the JMP for the reset vector. Note that the code does not copy SHADOW ROMs. These ROMs have already been copied by the system BIOS to C. The code uses the existing copy. --- Kronos [EMAIL PROTECTED] wrote: This memory is not performance critical and can be swapped, is there a better way to allocate it? Problem is that kmalloc may be unable to find many contiguous memory pages. You can check and see if the ROM is really big and use vmalloc, if not then you use kmalloc (if I remember correctly my radeon has a 4KB ROM - vmalloc would be overkill). Luca -- Home: http://kronoz.cjb.net Ci sono due cose che l'uomo non puo` nascondere: essere ubriaco ed essere innamorato. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
On Sad, 2004-08-07 at 17:37, Kronos wrote: You can check and see if the ROM is really big and use vmalloc, if not then you use kmalloc (if I remember correctly my radeon has a 4KB ROM - vmalloc would be overkill). You can also read it out to userspace in a loop in chunks thus needing only a single 4K page or you could mmap it --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
--- Alan Cox [EMAIL PROTECTED] wrote: On Sad, 2004-08-07 at 17:37, Kronos wrote: You can check and see if the ROM is really big and use vmalloc, if not then you use kmalloc (if I remember correctly my radeon has a 4KB ROM - vmalloc would be overkill). You can also read it out to userspace in a loop in chunks thus needing only a single 4K page or you could mmap it We have to copy the whole thing when the driver tells us to. After we copy the ROM the hardware is going to use the address decoder for something else. There is no safe way to get back to the ROM again other than to unload the device driver. = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Savage DRI DDX to xorg merge
On Sat, 07 Aug 2004 17:26:54 +0100, Sérgio Monteiro Basto [EMAIL PROTECTED] wrote: On Sat, 2004-08-07 at 17:08, Alex Deucher wrote: On Sat, 07 Aug 2004 17:43:23 +0200, albert vilella [EMAIL PROTECTED] wrote: I can test it on my Prosavage [ProSavage8 KM266/KL266] if it helps, is just pulling the cvs and compiling? download mesa cvs, xorg cvs, then apply my patch to xorg cvs, then follow the mesa/xorg build instructions. build instructions: http://dri.sourceforge.net/cgi-bin/moin.cgi/Building xorg patch: http://www.botchco.com/alex/xorg/savage-dri-to-xorg.diff I don't know what you mean about download Mesa cvs, xorg cvs comes with one Mesa and I am using it. am I doing any thing wrong ? Sorry I didn't realize that the savage DRI had been merged into xorg already. I see it has. Alex I use this scripts: cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg login (check out ) cvs -d :pserver:[EMAIL PROTECTED]:/cvs/xorg co -P xc mkdir build cd build lndir ../xc (create_drmkl.sh) cd build/extras/drm/linux/ sh ../scripts/create_linux_pci_lists.sh ../shared/drm_pciids.txt (if you want linux kernel drm ) cd .. scripts/create_lk_drm.sh /opt/xorgcvs/ 2.4 (or ) cd build/extras/drm/linux/ make cp savage.o /lib/modules/`uname -r`/kernel/drivers/char/drm (update cvs) cvs -q -d :pserver:[EMAIL PROTECTED]:/cvs/xorg update -P xc and finally in /etc/X11/xorg.conf Section Module # ... Load glx Load dri # ... EndSection Section DRI Mode 0666 EndSection regards, -- Sérgio M. B. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] New kernel API for ROMs
On Sad, 2004-08-07 at 18:40, Jon Smirl wrote: We have to copy the whole thing when the driver tells us to. After we copy the ROM the hardware is going to use the address decoder for something else. There is no safe way to get back to the ROM again other than to unload the device driver. Good point on mmap not working yes. We can still copy it in 4K chunks to userspace though not keep it in kernel. The rom boot stuff in the design is in user space. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM function pointer work..
On Fri, Aug 06, 2004 at 10:46:45AM -0700, Jon Smirl wrote: There are three main ways to get a driver: 1) vendor release - most stable, I get one every two weeks 2) Linus bk - very up to date, not as well tested, once a day 3) copy DRM CVS into Linus bk - bleeding edge, hope you know what you are doing. In the case of bleeding edge Fedora, (Ie FC3 t1 right now), 1 and 2 are the same. Ie, we rebase to the upstream -bk release almost daily. (The only time we don't is when both myself and Arjan are otherwise occupied, like recently at OLS etc, but it's rare that both of us are too busy to do a rebase). The current release version of Fedora (Ie, FC2 right now) has a slightly less aggressive update cycle, typically only when either a) the upstream kernel has fixed a lot of bugs that have been biting users, or b) there's a security problem to justify another update. Dave --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
