On Mon, 28 Feb 2011 16:10:39 +0100, Michel Dänzer <daen...@debian.org> wrote: > > ==19774== Source and destination overlap in memcpy(0x5c84c70, 0x5c84c70, > > 408) ==19774== at 0x40258E5: memcpy (mc_replace_strmem.c:497) > > ==19774== by 0x49BD3EA: exaMemcpyBox (exa_migration_classic.c:59) > > ==19774== by 0x49BD8C4: exaCopyDirty (exa_migration_classic.c:234) > > ==19774== by 0x49BDDF3: exaCopyDirtyToFb (exa_migration_classic.c:298) > > ==19774== by 0x49C0048: exaDoMigration_mixed > > (exa_migration_mixed.c:113) ==19774== by 0x49BB75C: exaDoMigration > > (exa.c:1131) ==19774== by 0x49C6E08: exaTryDriverComposite > > (exa_render.c:734) ==19774== by 0x49C75C7: exaComposite > > (exa_render.c:1033) ==19774== by 0x811E11C: damageComposite > > (damage.c:640) ==19774== by 0x810F3BF: CompositePicture > > (picture.c:1710) ==19774== by 0x49C6933: exaTrapezoids > > (exa_render.c:1181) ==19774== by 0x810F0A7: CompositeTrapezoids > > (picture.c:1751) > > The only way I think this could happen is if the UploadToScreen hook > fails. Indeed, I've only noticed now that you have > > Option "EXANoDownloadFromScreen" "on" > Option "EXANoUploadToScreen" "on" > > in xorg.conf. Does it work better without these options? The driver > doesn't really support running without these hooks anymore.
Nice catch, thanks! Removing the options does indeed allow the server to start, and so far everything is working correctly. Would you like a patch to ignore (with a warning) these options if they're set? Regards, Stephen -- 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/20110301113304.522b6...@sk2.org
