On Mon, 1 Jul 2002, Felix Kühling wrote: > On Sun, 30 Jun 2002 15:06:34 -0400 (EDT) > Leif Delgass <[EMAIL PROTECTED]> wrote: > > > On Sun, 30 Jun 2002, Alan Hourihane wrote: > > > > > On Sun, Jun 30, 2002 at 12:39:30 +0200, Felix Kühling wrote: > > > > Hi mach64 folks, > > > > > > > > after several weeks of extreme busyness/absence I am back now and > > > > testing the mach64-0-0-4 and 0-0-5 branches again (still the best I can > > > > do :( ). It's great that you got 2D accel working. However, there is > > > > still one problem. > > > > > > > > Moving a GL window caused the X-server to segfault with both the latest > > > > versions of mach64-0-0-4 and 0-0-5. Moving any other window while 3D was > > > > active was no problem. I experimented a bit with this and it turned out > > > > that the problem only occurs when I use > > > > > > > > Option "XaaNoScreenToScreenCopy" > > > > > > > > in the Screen section. (I did this since it caused drawing errors in > > > > some situations.) > > > > > > > > I got a backtrace of the segfault: > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > 0x00000000 in ?? () > > > > #0 0x00000000 in ?? () > > > > #1 0x08741a5f in ?? () > > > > #2 0x0825129f in ?? () > > > > #3 0x0817e351 in miMoveWindow (pWin=0x8912d18, x=0, y=0, pNextSib=0x8939780, > > > > kind=VTMove) at miwindow.c:553 > > > > #4 0x080d8d17 in ConfigureWindow (pWin=0x8912d18, mask=3, vlist=0x88f2088, > > > > client=0x88d5560) at window.c:2507 > > > > #5 0x080beda2 in ProcConfigureWindow (client=0x88d5560) at dispatch.c:772 > > > > #6 0x080b9608 in Dispatch () at dispatch.c:462 > > > > #7 0x080cde39 in main (argc=5, argv=0xbffffb84, envp=0xbffffb9c) at main.c:454 > > > > > > > > call LoaderPrintSymbol printed this in XFree86.1.log: > > > > 0x8741138 ATIInitializeXVideo+927 > > > > Module "/usr/X11R6-mach64005/lib/modules/drivers/atimisc_drv.o" > > > > Section ".text" > > > > 0x82511f0 DRICopyWindow+af > > > > Module "/usr/X11R6-mach64005/lib/modules/extensions/libdri.a:dri.o" > > > > Section ".text" > > > > > > > > It seems that there is a call to a null pointer in the end. Just a > > > > guess: Could it be a call to the ScreenToScreen copy function which I > > > > disabled in the XF86Config? > > > > > > Yes. It is indeed the problem. ATIDRIMoveBuffers() calls > > > this XAA function. > > > > > > I guess if this is disabled you need to fallback to software > > > copying, or disable DRI (ouch). > > > > > > Alan. > > > > I copied the code for ATIDRIMoveBuffers from the radeon driver. Does > > radeon have a fallback for this? ATIDRIInitBuffers also uses XAA > > functions (SoldFill), but that could be changed to use the drm clear > > ioctl. > > > > Felix, what problems were you seeing with XaaScreenToScreenCopy enabled? > > If you see a message in the X log about MMIO caching after "Direct > > rendering enabled", try updating from cvs (0-0-5-branch) or using the > > latest binary and see if the problem is still there. > > The 2D problems have nothing to do with DRI, I also see them with > XFree86 4.1. I get really messed up graphics in some situations, certain > web sites or gtk+ themes. I could fix one gtk+ theme by changing the > size of the background pixmaps from 4x4 to 8x8 IIRC. There is a > screenshot at www.dd.chalmers.se/~kuhlfeli/GarbledScreenshot.png. One > Website that often reproduces the problem is www.mplayerhq.hu, sometimes > more, sometimes less. I reported the problem twice to xfree86.org, but > got no response. I'm afraid it's broken hardware :(
OK, this shouldn't segfault anymore with the current CVS. At the moment, there's no software fallback for Init/MoveBuffers (Init buffers uses Xaa solid fills), the functions just return if the Xaa function callback pointer is NULL. Note that hardware blits and fills are still used for 3D clears/swaps even if XaaNoScreenToScreenCopy or XaaNoSolidFillRect are configured. -- Leif Delgass http://www.retinalburn.net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek We have stuff for geeks like you. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
