Hints for debugging a weird sw-cursor issue ?

[Hans de Goede]

Hi,

On 01-09-16 04:42, Dave Airlie wrote:
> 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

OK, I've found this and I'm working on rebasing and testing it. I'll
also address Aaron Plattner's comments to the last version.

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

Interesting I think that the kernel solution will likely be the
best way to deal with this. With your drm-maintainer hat on,
would you accept a (cleaned up) version of these patches ?

Also any chance you can easily find the original patches, or
have a copy you can forward to me ?

Regards,

Hans