Re: [Dri-devel] Compiling mesa-4-0-branch
I've manualy imported the fix in mesa-4-0-branch and it works fine without fbdev. Radeonfb is buggy, so I didn't try that yet. I submited Michel patch along with another fix for UseFBDev mode with readeon to the XFree main CVS yesterday. It works fine if you have the latest bug fixed radeonfb, which is, so far, only in the PPC kernel trees but should show up in Marcelo's rsn. Ben. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
Michel Dänzer wrote: What's the kernel message printed when loading the module, in particular the version? The only thing I could think of is that you're using an Alan Cox kernel and have configured it for the wrong XFree86 version or something. I've tried with 2.4.9-ac11, but the DRI was correctly configured for XFree 4.1, and also with vanilla 2.4.14 and 2.4.16. I've just noticed something strange, though : even though the xserver packages are all 4.1.0-9, it seems the server itself hasn't been completely updated : XFree86 Version 4.0.99.3 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 26 April 2001 (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.0.99.3, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.1 From what I understand, this means I've been trying to use the DRI modules for 4.1 with a partially 4.0 xserver. I say partially because some other parts of the server appear to be correct 4.1 : (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor=The XFree86 Project compiled for 4.1.0.1, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 So I figure I only have to get the server back to speed with a correct, fully 4.1 version, and things should work again. The single remaining problem is that I have no idea how to do that without blowing my distribution to pieces. I've tried reinstalling packages like xserver-common, to no avail. -- Daniel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
On Mon, 2001-12-03 at 12:27, Daniel Polombo wrote: XFree86 Version 4.0.99.3 / X Window System (protocol Version 11, revision 0, vendor release 6510) Release Date: 26 April 2001 (II) Loading /usr/X11R6/lib/modules/extensions/libdri.a (II) Module dri: vendor=The XFree86 Project compiled for 4.0.99.3, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.1 From what I understand, this means I've been trying to use the DRI modules for 4.1 with a partially 4.0 xserver. I say partially because some other parts of the server appear to be correct 4.1 : (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor=The XFree86 Project compiled for 4.1.0.1, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 So I figure I only have to get the server back to speed with a correct, fully 4.1 version, and things should work again. The single remaining problem is that I have no idea how to do that without blowing my distribution to pieces. I've tried reinstalling packages like xserver-common, to no avail. The X server and its modules are in xserver-xfree86. If reinstalling that doesn't fix this, you have a non-distribution X which is picked up. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
On Mon, Dec 03, 2001 at 01:40:12PM +0100, Daniel Polombo wrote: Michel Dänzer wrote: The X server and its modules are in xserver-xfree86. If reinstalling that doesn't fix this, you have a non-distribution X which is picked up. There was indeed an X11R6-DRI in which some things were picked up, including the wrong XFree86. I fixed that, and now the X server announces itself as a 4.1.0.1, as do all the libs : (II) Loading /usr/X11R6/lib/modules/linux/libdrm.a (II) Module drm: vendor=The XFree86 Project compiled for 4.1.0.1, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.1 However, this still doesn't work, and I still get the same error : ambre:~$ /usr/lib/xscreensaver/gears drmR128Clear: return = -22 Sounds like your kernel driver isn't uptodate. If you type 'dmesg' to look at the kernel messages the r128 kernel module should identify itself as version 2.1.6. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
Alan Hourihane wrote: Sounds like your kernel driver isn't uptodate. If you type 'dmesg' to look at the kernel messages the r128 kernel module should identify itself as version 2.1.6. Looks good to me : ambre:~$ dmesg | grep -i r128 [drm] Initialized r128 2.1.6 20010405 on minor 0 -- Daniel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
On Mon, 2001-12-03 at 14:11, Daniel Polombo wrote: Alan Hourihane wrote: Sounds like your kernel driver isn't uptodate. If you type 'dmesg' to look at the kernel messages the r128 kernel module should identify itself as version 2.1.6. Looks good to me : ambre:~$ dmesg | grep -i r128 [drm] Initialized r128 2.1.6 20010405 on minor 0 What does a client say when you start it with LIBGL_DEBUG=verbose? Just another stab in the dark ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
On Mon, Dec 03, 2001 at 02:11:33PM +0100, Daniel Polombo wrote: Alan Hourihane wrote: Sounds like your kernel driver isn't uptodate. If you type 'dmesg' to look at the kernel messages the r128 kernel module should identify itself as version 2.1.6. Looks good to me : ambre:~$ dmesg | grep -i r128 [drm] Initialized r128 2.1.6 20010405 on minor 0 Then we need to see the full /var/log/XFree86.0.log file. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
On Mon, Dec 03, 2001 at 02:34:56PM +0100, Daniel Polombo wrote: Alan Hourihane wrote: Then we need to see the full /var/log/XFree86.0.log file. Here it comes (attached). O.k. That looks good. What does the last 10 or so lines of 'dmesg' say ? Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
Alan Hourihane wrote: O.k. That looks good. What does the last 10 or so lines of 'dmesg' say ? I'm not sure this is what you want, but : [drm:r128_cce_vertex] *ERROR* process 27792 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28769 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28771 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28801 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28843 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28846 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28848 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 29033 using buffer owned by 0 -- Daniel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
On Mon, Dec 03, 2001 at 03:02:35PM +0100, Daniel Polombo wrote: Alan Hourihane wrote: O.k. That looks good. What does the last 10 or so lines of 'dmesg' say ? I'm not sure this is what you want, but : I need the output from the loading of the drm module to when these *ERROR*'s started. Alan. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
Hi all It seems people are actively testing mach64 branch. So I have a couple of questions: 1. Could anyone please periodically make binary snapshots including only X server, necessary libs and little (~10 lines) readme? 2. Is mach64 driver binary compatible with XFree 4.1.0 or does it depend on some 4.2 APIs? Unfortunately I cannot afford take the whole XFree branch and build it on my machine, but I would really like to play in testing dri/mach64. Thanks a lot, Sergey V. Udaltsov ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
As far as I know this is not so simple as a X server and libs. You also have the kernel modules... and those are tied to the kernel version configuration you have. If the problem you have is hard disk space (you need about 500 Mb) you could try to build on a remote machine disk, mounted via samba or nfs. If the problem is slow/expensive internet connection I think that I it would be no problem if I hosted a bzipped tarball of the mach64 branch snapshot. Regards, Jose Fonseca On Mon, 2001-12-03 at 15:11, Sergey V. Udaltsov wrote: Hi all It seems people are actively testing mach64 branch. So I have a couple of questions: 1. Could anyone please periodically make binary snapshots including only X server, necessary libs and little (~10 lines) readme? 2. Is mach64 driver binary compatible with XFree 4.1.0 or does it depend on some 4.2 APIs? Unfortunately I cannot afford take the whole XFree branch and build it on my machine, but I would really like to play in testing dri/mach64. Thanks a lot, Sergey V. Udaltsov ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI segfaults after debian update
Alan Hourihane wrote: I need the output from the loading of the drm module to when these *ERROR*'s started. Here it is, all un-edited. [drm] AGP 0.99 on Intel i815 @ 0xe400 64MB [drm] Initialized r128 2.1.6 20010405 on minor 0 uhci.c: USB Universal Host Controller Interface driver v1.1 PCI: Found IRQ 11 for device 00:1f.2 PCI: Sharing IRQ 11 with 02:06.0 PCI: Sharing IRQ 11 with 02:06.1 PCI: Sharing IRQ 11 with 02:0f.0 PCI: Sharing IRQ 11 with 02:0f.1 PCI: Sharing IRQ 11 with 02:0f.2 PCI: Setting latency timer of device 00:1f.2 to 64 uhci.c: USB UHCI at I/O 0xdce0, IRQ 11 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected usb.c: registered new driver hid hid-core.c: v1.8 Andreas Gal, Vojtech Pavlik [EMAIL PROTECTED] hid-core.c: USB HID support drivers mice: PS/2 mouse device common for all mice kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.15, 06 Nov 2001 on ide0(3,6), internal journal EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.15, 06 Nov 2001 on ide0(3,7), internal journal EXT3-fs: mounted filesystem with ordered data mode. hub.c: USB new device connect on bus1/2, assigned device number 2 NTFS driver v1.1.20 [Flags: R/O MODULE] input0: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse ® with IntelliEye] on usb1:2.0 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. eth0: Setting promiscuous mode. device eth0 entered promiscuous mode device lo entered promiscuous mode [drm:r128_cce_vertex] *ERROR* process 640 using buffer owned by 0 VFS: Disk change detected on device ide0(3,64) ISO 9660 Extensions: Microsoft Joliet Level 3 ISO 9660 Extensions: RRIP_1991A device eth0 left promiscuous mode device lo left promiscuous mode [drm:r128_cce_vertex] *ERROR* process 27792 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28769 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28771 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28801 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28843 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28846 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 28848 using buffer owned by 0 [drm:r128_cce_vertex] *ERROR* process 29033 using buffer owned by 0 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
As far as I know this is not so simple as a X server and libs. You also have the kernel modules... and those are tied to the kernel version configuration you have. AFAIR there is a way to build kernel modules without precise kernel version dependance (correct me if I am wrong) - as long as all external symbols as resolved, the module will be loaded. If the problem you have is hard disk space (you need about 500 Mb) you could try to build on a remote machine disk, mounted via samba or nfs. :) If I only had this machine:) There are only 2 machines in the company with Linux: my laptop and server. Nobody is going to let me build something on the server (and it does make sense:). If the problem is slow/expensive internet connection I think that I it would be no problem if I hosted a bzipped tarball of the mach64 branch snapshot. In sources? :( I am not sure it will help me (see above). BTW, what would be the size of the archive (because traffic is an issue for me)? So, the question is: whether there is a way to build kernel modules for generic 2.4.x? Will this cause trouble? Also, my second question is still remaining: will the server and libs be compatible with XFree 4.1.0 from RH7.2 distro? Regards, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] binary snapshots Was: hw cursor in mach64
On Mon, 2001-12-03 at 16:24, Sergey V. Udaltsov wrote: As far as I know this is not so simple as a X server and libs. You also have the kernel modules... and those are tied to the kernel version configuration you have. AFAIR there is a way to build kernel modules without precise kernel version dependance (correct me if I am wrong) - as long as all external symbols as resolved, the module will be loaded. I don't know much about that.. Anyway I think that the best option is to use a share on a computer with a enough hard disk space. See below. If the problem you have is hard disk space (you need about 500 Mb) you could try to build on a remote machine disk, mounted via samba or nfs. :) If I only had this machine:) There are only 2 machines in the company with Linux: my laptop and server. Nobody is going to let me build something on the server (and it does make sense:). You don't need a Linux machine. AFAIK, a plain samba mount (i.e., a Windows share in Linux world) should be ok. If you still have problems with symbolic links just change the 'ln -s' to 'cp' and you should be fine. Unless you tell me I also don't have access to a Windows computer with 500 Mb free.. :) If the problem is slow/expensive internet connection I think that I it would be no problem if I hosted a bzipped tarball of the mach64 branch snapshot. In sources? :( I am not sure it will help me (see above). BTW, what would be the size of the archive (because traffic is an issue for me)? I'm not sure. I think that about 20Mb... for the sources. (I don't have my laptop with me so I can't give precise figures. Anyway just give a look in the size of XFree 4.1.0 source and binaries rpms to get a good ideia.) So, the question is: whether there is a way to build kernel modules for generic 2.4.x? Will this cause trouble? Also, my second question is still remaining: will the server and libs be compatible with XFree 4.1.0 from RH7.2 distro? It's possible to build the modules separately. The Redhat for instance does that in its kernel source. To answer to your 2nd question: yes. It's exactly the same distribution I have on my laptop... Regards, Sergey Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] binary snapshots
On Mon, 2001-12-03 at 17:38, Sergey V. Udaltsov wrote: fine. Unless you tell me I also don't have access to a Windows computer with 500 Mb free.. :) :) OK. I am convinced. I'm not sure. I think that about 20Mb... for the sources. (I don't have my laptop with me so I can't give precise figures. Anyway just give a look in the size of XFree 4.1.0 source and binaries rpms to get a good ideia.) :((( Not too small (I expected something like this). Taking that 90% of the code is the same libs and progs as in standard XFree - does it make sense to download 20M over 56K? This is something that you have to decide for yourself... It's possible to build the modules separately. The Redhat for instance does that in its kernel source. The question was whether is possible to build modules for any 2.4.x kernel. But if you use the same kernel as me - see below. To answer to your 2nd question: yes. It's exactly the same distribution I have on my laptop... Wow! So probably your binaries are be just good for me (if you have installed the latest updated kernel from RH which is 2.4.9-13). If so, could you put them somewhere?:) Even if your kernel is not exactly this, I could give a try... (using insmod -f :) Ok. I have no problem in doing that. Give-me a couple days and I'll give you a url. If anyone else is also interested please e-mail me privately saying so. Cheers, Sergey Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? --Leif On 3 Dec 2001, Jose Fonseca wrote: I've been testing the mach64-0-02-branch on my laptop (ATI Mobility 4Mb) and in Unreal a semi-transparent garbled sprite appears on the middle of the screen - it's the hw cursor that wasn't properly erased because this behavior disappears when the X server is started with the 'sw_cursor'. This appears during game and menus - it seems that Unreal draws itself the cursor by software regardless of the availability of hardware acceleration. Any ideas? Regards, Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
On Mon, 3 Dec 2001, Otto E Solares wrote: On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote: I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? i had exactly the same problem in quake3 and rtcw with the white walls until i disable gl extensions on options and problem gone, but the problem with a rectangle on center on the screen is boring me, will try disabling hw cursor. Well, I tried lightmap with gl extensions disabled and the lighting definitely looks better, but it runs slower (compiled vertex arrays are also disabled). I noticed that with extensions/multitexturing on, I see GL_MAX_ACTIVE_TEXTURES_ARB: 2 on the console. Maybe quake needs 3 textures: wall + lightmap + damage? -- Leif Delgass http://www.retinalburn.net ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
On Mon, Dec 03, 2001 at 03:09:13PM -0500, Leif Delgass wrote: I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? Try disabling multitexture, if you have the Q1 gamedata then I would not mind hearing if it works with twilight with a few different settings. Zephaniah E. Hull. --Leif -- 1024D/E65A7801 Zephaniah E. Hull [EMAIL PROTECTED] 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. ALL programs are poems, it's just that not all programmers are poets. -- Jonathan Guthrie in the scary.devil.monastery msg02012/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Deadlock on mesa-4-0 and mesa-3-5 branches radeon drv?
On Sat, Dec 01, 2001 at 01:17:16PM -0700, Brian Paul wrote: Keith Whitwell wrote: Jorge Luis Williams wrote: Hello, I've run into what appears to be a dead-lock while running tessellation demo by David Blythe which is included in the Glut-3.7 source distribution (glut-3.7/progs/advanced/tes.c) I'll look at this. This might be related to the problem I forwarded to you with the GLUT walker demo. If assertions aren't activated, the TL code enters an infinite loop with that demo. Nope, I don't see it going into an infinate loop at all. It seems to be freezing on a call to select??? Here's what I can get of the backtrace... #0 0x4022bbfe in __select () from /lib/libc.so.6 #1 0x4005263c in __DTOR_END__ () from /usr/lib/libglut.so.3 #2 0xc2 in ?? () I guess the problem is related to glut?? It's weird that I don't see it when I disable triangle strips. If there is an infinate loop it's not in the tess process at all -- X does seem to be working really hard though after tess freezes. PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 7206 root 15 0 85384 9148 3144 R99.9 1.0 15:45 X Here's the bt for X -- unfortunately I don't think I have enough debug symbols to really make it usefull. #0 0x4011b4e4 in __ioctl () from /lib/libc.so.6 #1 0x0 in ?? () Hope this helps.. Just out of curiosity has any one been able to sucessfully use the radeon driver on the 3.5 or 4.0 branch on an SMP system -- maybe the problem is related to this? jOrGe W. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] hw cursor in mach64
Leif, I've managed to solve that same problem by leaving NoLighting=False and changing UseMultiTexture=0. Fortunatly we can get the source for the OpenGLDrv at http://openut.sourceforge.net . I'm sure that that will help us find the source of these problems... Regards, Jose Fonseca On 2001.12.03 20:09 Leif Delgass wrote: I get the garbled pointer in UT too. Also, the only way I can get wall/ceiling/floor textures to show up is by disabling lighting altogether (with NoLighting=True under [SDLDrv.SDLClient]). Otherwise I just get white instead of textures. I had the same thing with q3demo until I set lighting to vertex instead of lightmap. I get a garbled pointer in q3demo with lightmap, but I haven't seen it in vertex lighting yet. Does anyone know what might be the problem with textures and lighting, (maybe a problem with multitexturing)? --Leif On 3 Dec 2001, Jose Fonseca wrote: I've been testing the mach64-0-02-branch on my laptop (ATI Mobility 4Mb) and in Unreal a semi-transparent garbled sprite appears on the middle of the screen - it's the hw cursor that wasn't properly erased because this behavior disappears when the X server is started with the 'sw_cursor'. This appears during game and menus - it seems that Unreal draws itself the cursor by software regardless of the availability of hardware acceleration. Any ideas? Regards, Jose Fonseca -- Leif Delgass http://www.retinalburn.net Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] PPC Radeon Status?
Hello all, I'm wondering what the status of linux support for Radeon chipsets on PPC is. All i've been able to find on the web is that it might work with XFree86 4.1.0 with some patches, and that XFree86 4.2 should support it. I'm thinking about getting one of the new model titanium Powerbooks with Radeon Mobility chips, so I'd be very interested to know if there's any chance of getting it working, and if so if there's any chance of DRI and Xv support. Thanks Leigh ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
