Re: Hints for debugging a weird sw-cursor issue ?

2016-09-02 Thread Hans de Goede 

Hi,

On 01-09-16 04:42, Dave Airlie wrote:

On 1 September 2016 at 11:28, Michel Dänzer  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  said:

On 31 August 2016 at 22:10, Hans de Goede  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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Hints for debugging a weird sw-cursor issue ?

2016-09-01 Thread 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  said:


On 31 August 2016 at 22:10, Hans de Goede  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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Dave Airlie 
On 1 September 2016 at 11:28, Michel Dänzer  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  said:
 On 31 August 2016 at 22:10, Hans de Goede  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.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread 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  said:
>>> On 31 August 2016 at 22:10, Hans de Goede  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
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Michel Dänzer 
On 01/09/16 08:33 AM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie  said:
>> On 31 August 2016 at 22:10, Hans de Goede  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.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread The Rasterman 
On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie  said:

> On 31 August 2016 at 22:10, Hans de Goede  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@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)ras...@rasterman.com

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Dave Airlie 
On 31 August 2016 at 22:10, Hans de Goede  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.

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

Hints for debugging a weird sw-cursor issue ?

2016-08-31 Thread Hans de Goede 

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 ?

Regards,

Hans


*) It does not matter how I start it, with DRI2 or DRI3, with
DRI_PRIME=1 or without
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel