Hints for debugging a weird sw-cursor issue ?

[Dave Airlie]

On 1 September 2016 at 11:28, Michel Dänzer <michel at daenzer.net> wrote:
> On 01/09/16 10:24 AM, Michel Dänzer wrote:
>> On 01/09/16 08:33 AM, 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.
>>>
>>> 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. :)
>>
>> FWIW, one solution for this is TearFree.
>
> Also, obviously HW cursor support for GPU screens would avoid it in the
> first place.

There was a patch that mostly did this posted a while back, might be worth
picking up, however doesn't fix the USB devices which have no hw cursor,
though there was some kernel hacks posted to make the USB kernel driver
composit a cursor when sending data to the usb device.

Dave.