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_id78&alloc_id371&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
