Quoting Ville Syrjala (2018-10-19 17:55:02) > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxx> Tentative Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> I think I would like to review the impact on swcursor a bit more, FAIL_CURSOR_IOCTL be my friend. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
