RFC: Bug #4633 (Initial mouse pointer incorrect with EXA)

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michel Dänzer wrote:
> The backtrace in comment #17
> (https://bugs.freedesktop.org/show_bug.cgi?id=4633#c17) shows that the
> problem is caused by xf86RandRSetMode() calling
> EnableDisableFBAccess(index, FALSE), which causes EXA to kick out all
> allocated offscreen areas, even locked ones such as the one for the
> radeon driver's HW cursor data. The driver doesn't know about that, so
> the card still reads the cursor data from the same, now invalid
> location, hence the corrupted cursor until the server uploads a new
> cursor image.
> 
> I can think of several basic approaches to fix this, but I'm not sure
> which one is the best, so I'd like to collect some other opinions before
> embarking on one.
> 
>       * EXA could preserve locked offscreen areas across
>         EnableDisableFBAccess() calls.
>       * xf86RandRSetMode() might be able to take care of this by calling
>         something like UnrealizeCursor() before disabling FB access and
>         RealizeCursor() after re-enabling it.


Please don't change EXA's current behavior, it will break the sis driver
very probably. (And EXA's behavior is better for RandR rotation because
the driver is among the first to allocate offscreen memory for its
shadow buffer.)

I have nothing against the RealizeCursor approach, though.

>       * The driver could wrap EnableDisableFBAccess() and restore the
>         offscreen HW cursor data after FB access gets re-enabled.
>       * Other approaches?

Thomas

- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDdJ7ezydIRAktyUcRAgDcAJ49mym1mfGlQ3qxCwTTOyr4WU4nSwCeITNP
SbesMvLJpPpGSlrOEFGSLjE=
=ZK9P
-----END PGP SIGNATURE-----