Bug#613593: xserver-xorg-video-radeon: [regression] X fails to start

[Stephen Kitt <steve@sk2.org>]

On Mon, 28 Feb 2011 16:10:39 +0100, Michel Dänzer <daenzer@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