Hi,
On 01-09-16 01:33, Carsten Haitzler (The Rasterman) wrote:
On Thu, 1 Sep 2016 06:36:32 +1000 Dave Airlie <airl...@gmail.com> said:
On 31 August 2016 at 22:10, Hans de Goede <hdego...@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
_______________________________________________
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
