[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
