Hints for debugging a weird sw-cursor issue ?

Carsten Haitzler (The Rasterman) raster at rasterman.com
Wed Aug 31 23:33:10 UTC 2016

On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie <airlied at gmail.com> said:

> On 31 August 2016 at 22:10, Hans de Goede <hdegoede at redhat.com> wrote:
> > Hi All,
> >
> > I've noticed a weird sw-cursor issue when a slave-output is active
> > (I believe this is a sw-cursor issue because show_cursor never
> >  gets called when a slave-output is active at server start).
> >
> > I'm seeing this with both 1.18 and master and with both the
> > intel and the modesetting drivers (running gnome3 / gnome-shell).
> >
> > Everything is fine until I start glxgears (*) then the cursor becomes
> > invisible (flickering on the intel driver) when it is near the
> > top of the screen. Basically there is a horizontal bar where
> > the cursor does not show. Note this goes for the entire monitor,
> > not just where glxgears is running. This bar is near the top of
> > the screen, but not completely at the top, there is a small area
> > near the top where the cursor still shows.
> >
> > Interestingly enough if I disable vblank for glxgears the problem
> > remains, but the bar becomes smaller (less high).
> >
> > So anyone got any clues for debugging this ?
> Sounds like some wierdass tearing,
> since swcursor has to paint the cursor on the screen, so you might
> be seeing frames where the cursor hasn't been painted yet.

that'd likely be it. remember that on an update of the screen, if the update
draws where the cursor is, the cursor is "destroyed" then some time after this
it's repainted on top directly to the fb. thats how sw cursors have been done
in x as long as i can remember. when the cursor paints it also makes a copy of
the region it paints to to an offscreen buffer area so if the cursor itself
moves/changes, it pastes that back on again to wipe the cursor, then does the
above "draw it to the fb" again.

there's a good chance the cursor draw is being hooked to some vblank interrupt
and thus if cursor is close to the top the draw is not done yet when screen
scans out... thus the bar at the top. i should assume your display is likely
composited right? which means it may be that that area is being drawn
regardless of where glxgears is. compositor is drawing it.

good luck with this one. i have an idea that'd make it better but not perfect.
your solutions are not going to be pretty with various downsides but they may
fix the flickering/invisible thing. :)

> Dave.
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com

More information about the xorg-devel mailing list