GNOME Bugzilla – Bug 755465
cursor flickers like mad when hidden
Last modified: 2015-10-13 10:04:42 UTC
Created attachment 311947 [details] flickering shown on gnome-terminal Forwarding from https://bugzilla.redhat.com/show_bug.cgi?id=1264782 : When the cursor is hidden by a Wayland client, it flickers like mad, within what looks like a 256x256 area (my native hardware size). This is most visible when typing in gnome-terminal or GEdit. Running mutter-wayland on a native KMS backend. The attached video shows this in gnome-terminal: pressing a character (which hides the cursor) starts the flickering, and moving the mouse ends it. This does not occur for XWayland clients: GEdit shows it when running under Wayland, but unsetting $WAYLAND_DISPLAY has it doing the right thing. In either case, it's not about the timing of when to draw the cursor: as you can see from the video, the cursor position jumps wildly within the box. So something else is much more seriously wrong with the cursor handling in that release. Running git master from today.
Have you tried in weston? I can witness the same thing in weston, so I suspect the bug may lie in gtk instead.
There are two different problems here. 1) The cursor position jumps wildly within the box I reckon that's bug 751835 which shows on some hardware. As a test. disable the HW cursor (I have a test patch ready to demonstrate that if you need it) and the pointer will not show as "jumping" (the actual position of the cursor does not change, it's where the image appears within the HW cursor area that makes it look like it moves because the content is not refreshed when it should). But that's exacerbated by the second issue: 2) The cursor flickers when hidden As stated in comment #1 I reckon the bug is in gtk+ instead. Reverting commit 587afb5 [1], commit 1dc4eea [2] and commit 6457ee5 [3] fixes the issue with flickering. [1] https://git.gnome.org/browse/gtk+/commit/?id=587afb5 [2] https://git.gnome.org/browse/gtk+/commit/?id=1dc4eea [3] https://git.gnome.org/browse/gtk+/commit/?id=6457ee5 So I think we should fix #2 for a start as it's regression, and once #2 is fixed, #1 will not show as bad as it does now. => Moving to gtk+ for fixing #2.
I don't think we've seen this again ?
Closing for now. Please reopen if you see it again.
Just for the record, I cannot reproduce anymore in gtk+ 3.18.0, most likely fixed with commit 603ea3b
Yes, something along the way did fix this. Thanks!
*** Bug 747116 has been marked as a duplicate of this bug. ***