Hints for debugging a weird sw-cursor issue ?

[Hans de Goede]

Hi,

On 01-09-16 01:33, Carsten Haitzler (The Rasterman) wrote:
> 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.

Yes I'm using a compositor and I've been thinking about this problem last night
and I've come to the same conclusion as you (it is a race between the display
engine scanning out the front buffer and the xserver drawing the cursor on the
front-buffer.

> 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. :)

Actually, also last night, I've come to the conclusion that the right thing
to do here it to get hw cursors to work with slave outputs. I cannot think
of any technical reasons why this would not work (with a slave output on
a proper GPU which has hw overlay support).

Regards,

Hans