Tormod Volden writes: > On Thu, Oct 17, 2013 at 9:43 AM, Robert Jacobs wrote: > > What kind of testing is needed? Just simple "HEAD doesn't have obvious > > regressions on my hardware"? If so, I did test a very close variant to > > the patch that's in LP 1180986, and it mostly worked, but as I said, I > > got droppings on the second head. > > What would be nice, especially if we would consider a point release, > is to have it tested against the latest xserver.
Is that xserver-xorg-core in sid? Or do I need to pull HEAD from cgit.fd.o ? > Mouse droppings, is this traces of the mouse pointer not being cleaned > up? Did dual head at one point work for you without such droppings? In > this case testing of older versions (of server and driver) can help to > spot the regression. Anyway, dual head with mouse droppings is better > than no dual head. Yeah, mouse droppings from the outline moves by ctwm, regardless of whether using EXA or nothing. Bad interactions between the line drawing X calls and whatever is being done for the mouse cursor on the second head. Doesn't happen with XAA or NoAccel on 1.5.0, something worse happens with EXA on 1.5.0 (but we don't care). Also doesn't happen with WindowMaker's outline moves. But those look fancier. (They're [255-pixel] rather than flat color) What follows isn't even the same bug, I should prooobably open a new one. It happens with upstream HEAD using EXA, without dualheading. EXA causes segfaults under any non-trivial load, e.g. openbox trying to draw its menu. Causes stack corruption in an memcpy call so I can't figure out what's going on in gdb, but valgrind tracks it back to: ==6278== Invalid read of size 4 ==6278== at 0x482D160: memcpy (mc_replace_strmem.c:878) ==6278== by 0x51AC4B2: mgaDownloadFromScreen (mga_exa.c:743) ==6278== by 0x51C2FF5: ??? (in /usr/lib/xorg/modules/libexa.so) ==6278== by 0x1000AF: ??? ==6278== Address 0xac is not stack'd, malloc'd or (recently) free'd ==6278== Using this to track it down in gdb finds that Breakpoint 2, mgaDownloadFromScreen (pSrc=0xb6122008, x=0, y=0, w=176, h=16, dst=0xb6122088 "", dst_pitch=1024) at mga_exa.c:730 732 char *src = pSrc->devPrivate.ptr; devPrivate here contains only 0s. Well, ok, fine, I go and add a check to see if src is NULL here and if so it returns FALSE, and now it seems to work fine. Uh, you'll want a patch, here: --- mga_exa.c~ 2013-10-17 15:28:53.082541399 -0700 +++ mga_exa.c 2013-10-17 15:28:53.082541399 -0700 @@ -730,6 +730,9 @@ PMGA(pSrc); char *src = pSrc->devPrivate.ptr; + + if (src == NULL) return FALSE; + int src_pitch = exaGetPixmapPitch(pSrc); int cpp = (pSrc->drawable.bitsPerPixel + 7) / 8; ---tear here--- I made an annotated version, it works correctly about 9% of the time... is that bad? Do you have any ideas why the pSrc->devPrivate structure would be {0,0,0,0} ? Here's another random one: Program received signal SIGSEGV, Segmentation fault. 0xb7a3a46c in mgaCheckComposite (op=3, pSrcPict=0x806d4b70, pMaskPict=0x805ffd70, pDstPict=0x806d4d98) at mga_exa.c:359 359 MGAPtr pMga = xf86ScreenToScrn(pSrcPict->pDrawable->pScreen)->driverPrivate; (gdb) p pSrcPict->pDrawable $8 = (DrawablePtr) 0x0 I can be paranoid and add checks that it's never dereferencing NULL, but that seems wrong. Surely that means something significant is missing? Why would the acceleration methods be being passed what seems to be garbage input? - Robert -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1vwx5x-0003vg...@eamp.org