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 :(
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
