Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote: Well, yes, it's hard to package future changes. :) (BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes likely happened after 2003/10/05.) Oops, you're right. They were from November. PS: You get the trunk with -r HEAD or just no -r at all. Now this is going to sound doubly stupid, but I *swear* I checked out CVS HEAD yesterday, and all that showed up was FreeType and X-TrueType stuff along with some basic directory structure. Which is why I went searching for further instructions and thought perhaps I was supposed to use -rtrunk instead. I've just checked a complete copy and am building it now. Thanks for the tutelage. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Keep in mind that if you have previously checked out a branch, the 'no -r' option will keep you on that branch. If you have previously checked out a branch into your working area, make sure you do a update with '-A' which forgets the sticky tags (in this case a branch). Regards, Matthew Ryan Underwood wrote: On Wed, Jan 21, 2004 at 03:24:23PM +0100, Michel Dänzer wrote: Well, yes, it's hard to package future changes. :) (BTW, the XFree86 tag is only relevant in XFree86 CVS, and Ville's fixes likely happened after 2003/10/05.) Oops, you're right. They were from November. PS: You get the trunk with -r HEAD or just no -r at all. Now this is going to sound doubly stupid, but I *swear* I checked out CVS HEAD yesterday, and all that showed up was FreeType and X-TrueType stuff along with some basic directory structure. Which is why I went searching for further instructions and thought perhaps I was supposed to use -rtrunk instead. I've just checked a complete copy and am building it now. Thanks for the tutelage. -- Matthew Tippett - [EMAIL PROTECTED] Project Team Leader, Linux Platform Software ATI Technologies Inc., Markham, Ontario, Canada Ph: +1 905 882 2600 x8014 Fx: +1 905 882 9339 Cell: +1 416 671 0673 --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Ville, On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I can't reproduce any font corruption with crack-attack (or any other gl app) and quake2 just segfaults when I try to run it. Maybe it doesn't like to run with the demo pak file... But running quake3 and crack-attack at the same time does cause some really nasty texture corruption. They appear to step on each others' textures... Just to let you know, it appears the RENDER bug has been solved. I think I didn't properly replace the driver before. :) However, I was doing my own driver hacking, so I was forced to replace it correctly this time. The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. I just uploaded a patch to the bug tracker that makes DPMS work on the second head among other things (i2c/maven related). -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 03:52:37AM -0600, Ryan Underwood wrote: Ville, On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I can't reproduce any font corruption with crack-attack (or any other gl app) and quake2 just segfaults when I try to run it. Maybe it doesn't like to run with the demo pak file... But running quake3 and crack-attack at the same time does cause some really nasty texture corruption. They appear to step on each others' textures... Just to let you know, it appears the RENDER bug has been solved. I think I didn't properly replace the driver before. :) However, I was doing my own driver hacking, so I was forced to replace it correctly this time. Ah good. The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mga_xmesa.c.diff?r1=1.66r2=1.67hideattic=0 http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mgaioctl.c.diff?r1=1.37r2=1.38hideattic=0 The _mesa_notifySwapBuffers() call is the important bit. Without that the pipeline wasn't flushed properly. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. I just uploaded a patch to the bug tracker that makes DPMS work on the second head among other things (i2c/maven related). if you copied any code directly from the mga FB driver, you need to ask Petr Vandrovec if you can release it with a X11 license because the FB driver is GPL'ed. I think in the past Petr said he didn't care, but it's worth asking again. FWIW, I'd love to see native maven support in the X11 driver. Alex -- Ryan Underwood, [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood [EMAIL PROTECTED] wrote: On Tue, Jan 20, 2004 at 12:57:11PM +0200, Ville Syrjälä wrote: The only problem I have with the mga driver right now is lack of mouse cursor in UT, though there is a claim in bugzilla that you fixed it. Do you have any details on the fix? http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mga_xmesa.c.diff?r1=1.66r2=1.67hideattic=0 http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/xc/xc/lib/GL/mesa/src/drv/mga/Attic/mgaioctl.c.diff?r1=1.37r2=1.38hideattic=0 The _mesa_notifySwapBuffers() call is the important bit. Without that the pipeline wasn't flushed properly. Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. The changes may have been committed after the 3D drivers moved to mesa cvs. Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote: On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. Right, I just used them as a matter of convenience, no having to maintain separate XFree86 installation and such. Rebuild, dpkg -i *.deb, and test. Your package version is 2003.10.05-2 which is much newer than the above CVS tag. Seemed strange to me that there would be no trunk merges in 7 months, but I guess that is the case. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Jan 21, 2004 at 01:30:15AM +0100, Michel Dänzer wrote: On Wed, 2004-01-21 at 00:02, Ryan Underwood wrote: Are those fixes on a branch somewhere? It appears trunk's version is: /* $XFree86: xc/lib/GL/mesa/src/drv/mga/mga_xmesa.c,v 1.19 2003/03/26 20:43:49 tsi Exp $ */ but that is from Michel's trunk packages, so I don't know if he is completely up to date. Just look at the package version... if you want to follow or even do development, my snapshot packages aren't for you, use CVS directly. I remembered another reason I used your package. When I tried to check out DRI CVS, I used: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri -z4 co -rtrunk xc trying to get the trunk branch as CvsBranches in the Wiki mentions. However: cvs [server aborted]: no such tag trunk How should this preferably be done? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] No code was copied, only some defines. I need other people to check the code and tell me if it will break on other video cards. I only have a G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which need to be tested, and some changes were made to the main driver code too so there is a potential I made a mistake that would affect even non-G series matrox cards. The main thing I am worrying about is how some of the maven registers I used will behave on different cards. Right now I am trying to get DDC working on port 2 so I can be sure my i2c code is 100% correct. You might ask Petr or one of the kernel fbdev or directfb developers. they might be able to help you. unfortunately all my matrox cards have either died or or are no longer around :( Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 02:13:50PM -0800, Alex Deucher wrote: --- Ryan Underwood [EMAIL PROTECTED] wrote: [snip] No code was copied, only some defines. I need other people to check the code and tell me if it will break on other video cards. I only have a G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which need to be tested, and some changes were made to the main driver code too so there is a potential I made a mistake that would affect even non-G series matrox cards. The main thing I am worrying about is how some of the maven registers I used will behave on different cards. Right now I am trying to get DDC working on port 2 so I can be sure my i2c code is 100% correct. You might ask Petr or one of the kernel fbdev or directfb developers. they might be able to help you. unfortunately all my matrox cards have either died or or are no longer around :( I got DDC working. It was my second monitor that was the problem; its EDID data seems to be corrupt. It doesn't even work on the first head, and I can read my first monitor's EDID on the second head, so looks like we are in business. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[nemesis-lists@icequake.net: Re: [Dri-devel] MGA font corruption revisited - now reproducible]
[reposting... attachments caused message to be killed] On Wed, Dec 10, 2003 at 12:53:53PM +0200, Ville Syrjälä wrote: If you remove/comment out the following line $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World in the top Makefile make World shouldn't actually build anything. After that you should be able to build only the driver. I uploaded my patched mga_drv.o to my website http://www.sci.fi/~syrjala/dri/ so you might want to try that before building yourself... Here is a long story, prepare yourself. I ran crack-attack and the corruption didn't occur this time. After running quake2, there was still another problem. The fonts themselves are not corrupted, but the AA fonts, instead of having the normal background behind them of whatever the application puts there, have a black square for the background. It is almost like the data in that square was erased. Again, running UT and exiting it, and then causing the application to redraw, clears that problem up. I attached a screenshot of what it looks like. Like the font-corruption problem, this happens across all applications that use Xft-rendered fonts, there is a black background behind the rendered area in every place. later: I ran crack-attack once as mentioned and the corruption didn't occur, leading me to think it was fixed. Then I ran it again later after running quake2, and the corruption occurred again. :( The fonts are only corrupted after being redrawn. By that I mean immediately after exiting crack-attack, everything looks fine, but if I highlight a user in licq, his entry is immediately corrupted, and remains corrupted. Now I ran quake2 again, and the crack-attack corruption is gone in what seems to be the portion of the licq window that would have been overlaid by the GLX framebuffer (causing redraw of that stuff). It is replaced by the quake2 blank background corruption instead in those places. If I then highlight the other users users, they then change from crack-attack corruption to quake2 corruption -- the font is correct but the background is black. I attached screenshots of both the crack-attack corruption as well as the quake2 corruption so you can see what I talk about. It is strange that running UT clears up both of the corruptions reliably. Can you run crack-attack and quake2 to reproduce it? http://dbz.icequake.net/share/crack-attack-corruption.jpg http://dbz.icequake.net/share/quake2_corruption.jpg http://dbz.icequake.net/share/q2.log.bz2 I have also used UT to clear up the state when a SDL application crashes without parachute and leaves the mouse unable to be used. (I don't know of any other way to recover the mouse when it is not responding to input; at least I can use keyboard navigation to start UT from window manager's menu.) Seems like UT does some things correctly that other applications are not doing. Something else, 4 out of 5 times, quake2 does not cleanly exit, strace ends here (10 is the fd of /dev/dri/card0): [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe0b0) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0x4008642b, 0xbfffe510) = 0 [pid 12025] ioctl(10, 0x4008642a, 0xbfffe138) = ? ERESTARTSYS (To be restarted) [pid 12025] +++ killed by SIGKILL +++ It hangs on that last ioctl which is where I kill the application. How do I translate those ioctls into hardware commands so I know where to look for the problem? I guess mga_dri.so is sending some command to the DRM layer that it never bothers to return from here. I attached the whole strace if you are curious. On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? My second monitor blanks from the X screen blanker, but remains on, consuming power. The first one powers off as expected. I posted earlier about this to the XFree86 list, including a list of changelog entries corresponding to second-head DPMS on G400, but didn't elicit any responses. -- Ryan Underwood, [EMAIL PROTECTED] - End forwarded message - -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Dec 10, 2003 at 06:32:18AM -0600, Ryan Underwood wrote: On Wed, Dec 10, 2003 at 12:53:53PM +0200, Ville Syrjälä wrote: If you remove/comment out the following line $(MAKE_CMD) $(MFLAGS) $(WORLDOPTS) World in the top Makefile make World shouldn't actually build anything. After that you should be able to build only the driver. I uploaded my patched mga_drv.o to my website http://www.sci.fi/~syrjala/dri/ so you might want to try that before building yourself... Here is a long story, prepare yourself. I ran crack-attack and the corruption didn't occur this time. I can't reproduce any font corruption with crack-attack (or any other gl app) and quake2 just segfaults when I try to run it. Maybe it doesn't like to run with the demo pak file... But running quake3 and crack-attack at the same time does cause some really nasty texture corruption. They appear to step on each others' textures... I've only tried with gtk apps because I don't have qt installed. Something else, 4 out of 5 times, quake2 does not cleanly exit, strace ends here (10 is the fd of /dev/dri/card0): [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe0b0) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0xc0286429, 0xbfffe330) = 0 [pid 12025] ioctl(10, 0x400c6445, 0xbfffe4f0) = 0 [pid 12025] ioctl(10, 0x4008642b, 0xbfffe510) = 0 [pid 12025] ioctl(10, 0x4008642a, 0xbfffe138) = ? ERESTARTSYS (To be restarted) [pid 12025] +++ killed by SIGKILL +++ It hangs on that last ioctl which is where I kill the application. How do I translate those ioctls into hardware commands You need to match the 8 lsbs of that middle number to the ioctl numbers specified in drm.h and mga_drm.h. so I know where to look for the problem? That last one is the DRM_LOCK ioctl. It returns -ERESTARTSYS when there's a signal pending. I suppose the app just sits there and doesn't handle the signal for some reason. Some SDL magic? It's not a driver problem AFAICS. On another topic, do you use a dualhead G400? If so, are you able to properly use DPMS on the second head? I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Thu, Dec 11, 2003 at 02:02:36PM +0200, Ville Syrjälä wrote: I don't run XFree86 except when trying to hunt DRI related bugs. It's been well over a year since I really used XFree86 and I honestly don't remember if DPMS ever worked with the second head. I don't have a second monitor to test right now. Thanks for your tries and your insight. I will try to hunt these bugs when exams are over. In the meantime let me know if you come up with any patches and I can test them out. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote: Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) I've attached a patch that should hopefully fix this problem. The render code just forgot to reset the multi texturing registers. I've not actually tested the patch but I don't see anything else wrong with the code... Is there anywhere I can get a G400 databook for reference, or is that not publicly available? They're not available anymore :( It's a real shame since they seemed to be quite friendly towards open source developers at one point. I can almost understand that they don't want to release any parhelia docs but I don't understand why they stopped giving out the older docs... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ Index: mga_reg.h === RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_reg.h,v retrieving revision 1.8 diff -u -r1.8 mga_reg.h --- mga_reg.h 27 Jan 2002 20:05:35 - 1.8 +++ mga_reg.h 10 Dec 2003 06:27:05 - @@ -475,6 +475,9 @@ #define MGAREG_ALPHACTRL 0x2c7c #define MGAREG_DWGSYNC 0x2c4c +#define MGAREG_TDUALSTAGE0 0x2cf8 +#define MGAREG_TDUALSTAGE1 0x2cfc + #define MGAREG_AGP_PLL 0x1e4c #define MGA_AGP2XPLL_ENABLE0x1 #define MGA_AGP2XPLL_DISABLE 0x0 Index: mga_storm.c === RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/drivers/mga/mga_storm.c,v retrieving revision 1.20 diff -u -r1.20 mga_storm.c --- mga_storm.c 25 Mar 2003 11:21:06 - 1.20 +++ mga_storm.c 10 Dec 2003 06:27:07 - @@ -341,6 +341,10 @@ tex_padw = 1 log2w; tex_padh = 1 log2h; +WAITFIFO(2); +OUTREG(MGAREG_TDUALSTAGE0, 0); +OUTREG(MGAREG_TDUALSTAGE1, 0); + WAITFIFO(15); OUTREG(MGAREG_TMR0, (1 20) / tex_padw); /* sx inc */ OUTREG(MGAREG_TMR1, 0); /* sy inc */ @@ -425,6 +429,9 @@ tex_padw = 1 log2w; tex_padh = 1 log2h; +WAITFIFO(2); +OUTREG(MGAREG_TDUALSTAGE0, 0); +OUTREG(MGAREG_TDUALSTAGE1, 0); WAITFIFO(12); OUTREG(MGAREG_DR4, red 7); /* red start */ @@ -522,6 +529,10 @@ tex_padw = 1 log2w; tex_padh = 1 log2h; +WAITFIFO(2); +OUTREG(MGAREG_TDUALSTAGE0, 0); +OUTREG(MGAREG_TDUALSTAGE1, 0); + WAITFIFO(15); OUTREG(MGAREG_TMR0, (1 20) / tex_padw); /* sx inc */ OUTREG(MGAREG_TMR1, 0); /* sy inc */
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Dec 10, 2003 at 09:03:34AM +0200, Ville Syrjälä wrote: On Tue, Dec 09, 2003 at 01:24:16PM -0600, Ryan Underwood wrote: Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) I've attached a patch that should hopefully fix this problem. The render code just forgot to reset the multi texturing registers. I've not actually tested the patch but I don't see anything else wrong with the code... Cool! Is it possible to build the driver modules separately from the XFree86 world, and if so, can you point me at some instructions on how to accomplish that? Is there anywhere I can get a G400 databook for reference, or is that not publicly available? They're not available anymore :( It's a real shame since they seemed to be quite friendly towards open source developers at one point. I can almost understand that they don't want to release any parhelia docs but I don't understand why they stopped giving out the older docs... Must be some new management over there... *sigh* -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, 10 Dec 2003, Ryan Underwood wrote: They're not available anymore :( It's a real shame since they seemed to be quite friendly towards open source developers at one point. I can almost understand that they don't want to release any parhelia docs but I don't understand why they stopped giving out the older docs... Must be some new management over there... *sigh* Never attribute to malice what can be sufficiently explained by laziness or stupidity. Maintaining documentation is not something companies tend to get paid for, and they do it because it indirectly helps sell hardware: the better supported the hardware is, the more likely it will work well, and the more likely you'll get a good name and sales. But when it comes to old hardware that doesn't bring the company any revenue any more, the only reason to maintain documentation (even if the maintenance is just having people be aware of it, and making it available on a web-site and having the proper indexing to find it) is to show that you're committed to your products, so that people who buy the new ones can trust you. And a lot of companies don't seem to think that it's worth the pain. They'd rather screw their old customers over and try to get them to upgrade to the new product. Which works well enough, I guess, since it clearly is fairly rare to try to support your old stuff any longer than absolutely necessary. Sometimes consumer protection laws (especially in Europe) tend to have _requirements_ that you have things like replacement parts and documentation available for up to five years after you stopped selling the product. At other times, contractual obligations with other companies require the same. But on the whole, technical documentation doesn't fall under that heading (while pure maintenance manuals often do - if they existed in the first place). Major documentation policies usually only exist at the big old-time companies. For example, I could buy the Technical Reference: Personal Computer AT reference from IBM in 1991 - even though the thing was written in 1985. Because a company like IBM tends to have all these customers that really pay for _support_ more than new hardware. Their paying customer base literally cares about the fact that they know that they can get support and docs for hardware that may be quite old. In contrast, think about the best customer base of a graphics card vendor for a moment. The best customers there are the ones that upgrade once a year, and if they throw away their old card in disgust because it no longer plays the newest games titles, all the better. I hope that will change. I _think_ it will change. But it's likely to change only when we get rid of the new gfx card every six months mentality. Linus --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Dec 10, 2003 at 08:52:03AM -0800, Linus Torvalds wrote: Must be some new management over there... *sigh* Never attribute to malice what can be sufficiently explained by laziness or stupidity. ^ Why do you think I mentioned management? :) But when it comes to old hardware that doesn't bring the company any revenue any more, the only reason to maintain documentation (even if the maintenance is just having people be aware of it, and making it available on a web-site and having the proper indexing to find it) is to show that you're committed to your products, so that people who buy the new ones can trust you. It's unfortunate that while they still have the sales information and white papers for their old chips up on their website, it's next to impossible to get a human being that will even *entertain* your request for documentation, much less grant it. One would think that for old hardware, supporting it by posting documentation and code would be a bigger priority than maintaining product info for something they don't even sell anymore? And a lot of companies don't seem to think that it's worth the pain. They'd rather screw their old customers over and try to get them to upgrade to the new product. Which works well enough, I guess, since it clearly is fairly rare to try to support your old stuff any longer than absolutely necessary. I really wish it were possible to negotiate term limits on NDAs. Unfortunately, even providing docs under NDA seems like an immense favor nowadays. Major documentation policies usually only exist at the big old-time companies. For example, I could buy the Technical Reference: Personal Computer AT reference from IBM in 1991 - even though the thing was written in 1985. Because a company like IBM tends to have all these customers that really pay for _support_ more than new hardware. Their paying customer base literally cares about the fact that they know that they can get support and docs for hardware that may be quite old. Too bad, really; in all honesty I'd pay for a support subscription for my hardware because it's the hardware that fits my needs perfectly, and changing any of it would simply be less economical than buying all new stuff, not necessarily in terms of raw expense, but in terms of time spent re-hacking all scripts, changing configurations, etc. And too frequently the shiny new hardware focuses on the whiz-bang features and neglects things that you took for granted with the older stuff. I think support subscriptions would be too much of a trickle effect to bother with for old stuff, but we will probably see this in the future. One of the reasons support was given as part of the package in the past was because you had to convince people to buy into your market *at all*, much less choose your particular product. (Who needs a 3D game card, there aren't any worthwhile games around? - Me, 1996) Now that market segments like the video card market have a clearly defined inelastic demand component (the fanboys who rush out for a new video card every 6 months), the companies that produce the cards have less incentive to throw in things like support at no additional cost. In contrast, think about the best customer base of a graphics card vendor for a moment. The best customers there are the ones that upgrade once a year, and if they throw away their old card in disgust because it no longer plays the newest games titles, all the better. I think that's the conspiracy theory aspect of it. It's hard to explain otherwise why the company with a 5 year old product with a huge install base won't even do its existing customers the perfectly reasonable favor of posting a few PDF files on their website, or making printed copies available for a reasonable fee. I think they really do want to disassociate themselves from any past products in the hopes you'll just give up and upgrade. And many people give in to the coercion -- that's the advantage of having a support monopoly on your product, after all. You get to decide when your customers upgrade. You only hope they upgrade to *your* product though, so you don't want to start screwing them *too* soon into the previous product's life cycle. I hope that will change. I _think_ it will change. But it's likely to change only when we get rid of the new gfx card every six months mentality. That's probably not the key issue. After all, most hardware is on an evolutionary cycle now. NVIDIA's new products add the latest whiz-bang features to a core that's going on six years old now. ATI's base hardware is younger, but still an evolutionary approach is taken there too. Matrox has numerous products based on the design of the G400, which was a step up from the G200 -- only recently did they feel it was time to make the leap to a new architecture. VIA/S3 chips haven't changed much since the Virge days. These aren't revolutionary things that are happening when new gfx
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Wed, Dec 10, 2003 at 12:25:36PM -0600, Ryan Underwood wrote: In an open software architecture like the DRI, we should do our best to support proprietary vendors when they give us the means to do so, but all the pissing and moaning about what they will and won't do should go either to /dev/null or, more productively, towards opencores.org and a fully open windowing accelerator and programmable 3D graphics pipeline core. I forgot one other place the pissing and moaning can go to: the sales department of all the vendors *except* the one you either are about to buy a new graphics card from, or have just bought one from. Hopefully letting them know that their silliness is hitting them in the bankbook might cause them to mention such things as Linux to managers and shareholders, which might give those the crazy idea that allocating more resources towards providing better support for open source developers just might help them sell more video cards in the end. Lots of 'might' in that paragraph.. well, it doesn't cost much to fire off an email or make a phone call anyhow. Perhaps consider it like playing the lottery. $1 here, $1 there doesn't hurt anybody. The difference in this lottery is that if anyone wins, we all win. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
[Dri-devel] MGA font corruption revisited - now reproducible
Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) Is there anywhere I can get a G400 databook for reference, or is that not publicly available? On Tue, Dec 09, 2003 at 07:55:20AM -0800, Alex Deucher wrote: renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___
Re: [Dri-devel] MGA font corruption revisited - now reproducible
You could dig into it if you wish. if this is indeed the problem, you will have to figure out a way to maintain the state of the 3d enigne between the render accel and the DRI. you might want to ask Ian about it. you can also check the archives. there was some discussion about this in regards to using the 3d engine on radeon for Xv (YUV textures) and render accel. databooks were available, but I'm not sure they are giving them out anymore. Although I doubt you will really need them as the code is already there, you just need to make it play nice. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Thanks for the insight. Is this already something that has been extensively looked at without success, or would it be worth my time to dig into the code and try to find the cause? I've thought about it, but afraid that I will just hit a brick wall someone else already ran into with it. ;) Is there anywhere I can get a G400 databook for reference, or is that not publicly available? On Tue, Dec 09, 2003 at 07:55:20AM -0800, Alex Deucher wrote: renderaccel. the reason for the curruption is that both the 2d driver and the 3d driver are using the 3d engine. since they are not keeping state (render accel my write on 3d textures and vice versa, etc.), games will corrupt fonts and vice versa. Unfortunately it's a tough problem to solve. I don't recall how you turn off render accel on mga, you can probably find that on google. turning it off should solve the problem since render (used for AA fonts) will use teh software paths instead. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: By turn off HW render, you mean RenderAccel off, or NoAccel on ? BTW, I should clarify my previous post by saying that the fonts across _all_ Xft applications are corrupted when any of them is corrupted by DRI usage; no other non-AA fonts or pixmap data are affected, however. It is only AA fonts, and across _all_ AA applications when it occurs. Would installing a debug X server help track the cause of the corruption down? On Tue, Dec 09, 2003 at 06:59:30AM -0800, Alex Deucher wrote: turn off HW render accel. both HW render and 3D use the 3D engine and I don't know if they both keep state properly. that's probably were your corruption comes from. Alex --- Ryan Underwood [EMAIL PROTECTED] wrote: Hi, I've had some problems with certain DRI applications occasionally corrupting fonts in programs that use Xft. The corruption was noticeable after the DRI program exited. Strangely, it could be mitigated by running another different DRI program afterwards; this seems to be the only way to get rid of the corruption (moving the window off screen or minimizing/maximizing it doesn't work). Here are the steps to reproduce with 100% success for me: - Install licq (1.2.7 here) - Install the Qt licq plugin - Choose the bheart skin for licq-qt - Ensure that anti-aliases fonts are being used (QT_XFT=1) - Run either Quake2 (0.2.1) or crack-attack (1.1.9) - Exit the game Voila, your fonts should now be corrupted in that program. (The rest of the pixmaps are okay). crack-attack seems to corrupt worse than quake2. Now, run Unreal Tournament (UTPG latest version, which coincidentally still won't display a mouse cursor for me in recent mga DRI driver). After exiting UT, the corruption is gone 2 out of 3 times. I can also reproduce it using pan (with GDK_USE_XFT on) but the licq case is the most blindingly obvious. This has been going on for probably over a year now so I'd like to start heading towards a solution if possible. I am running Debian with Michel's XFree86 4.3.99 DRI trunk package, a recent DRM modules, 2.4.23 kernel, and a MGA G400 MAX. The same thing happened with previous MGA G400 16MB. I think something in the mga DRI driver is stomping on memory used for the fonts, but only under certain circumstances (triggered by e.g. quake2 and crack-attack). any ideas? -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click
