Hints for debugging a weird sw-cursor issue ?

[Michel Dänzer]

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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer