[Intel-gfx] [PATCH xf86-video-intel] sna: Switch back to hwcursor on the next cursor update

[Chris Wilson]

Quoting Ville Syrjala (2018-10-19 17:55:02)
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> Once we've switched to using the swcursor (possibly
> due to the cursor ioctl failing) we currently keep
> using the swcursor until the modeset.
> 
> That's not particularly great as the swcursor has several
> issues. Apart from the (presumably expected) flicker,
> the cursor also tends to leave horrible trails behind
> around dri2/3 windows (happens with tearfree at least).
> 
> To avoid some of that let's try to switch back to the hwcursor
> a bit sooner. We can do that neatly via the convenient swcursor
> block handler.

Ok, so that forces the sw cursor to be switched off on the very next
xf86CursorSetCursor() after being enabled. If the HWCursor fails, the
cursor should be invisible until the next block handler. Won't that
cause the cursor to flicker even more? Hmm, except that the swcursor
should be restored within a frame. So more or less simply doubling the
work of using swcursor? (Probably not actually, since swcursor is
effectively an undo and paint every time and now we just make those two
distinct steps) Certainly achieves the goal of forcing HW cursor back on
at the earliest opportunity.

I think I have just argued that this doesn't actually impact on swcursor
rendering, just extends the loop.

> References: https://bugs.freedesktop.org/show_bug.cgi?id=106935
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

Tentative
	Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
I think I would like to review the impact on swcursor a bit more,
FAIL_CURSOR_IOCTL be my friend.
-Chris