RFC: Bug #4633 (Initial mouse pointer incorrect with EXA)
alanh at fairlite.demon.co.uk
Fri Nov 11 03:05:14 PST 2005
On Fri, 2005-11-11 at 11:51 +0100, 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.
I think I like this approach best. It'll also cure Thomas' problem with
the SiS rotation and hw cursor upload.
> * The driver could wrap EnableDisableFBAccess() and restore the
> offscreen HW cursor data after FB access gets re-enabled.
> * Other approaches?
More information about the xorg