GNOME Bugzilla – Bug 688456
Cursor doesn't hide with Wacom tablet
Last modified: 2015-11-28 22:00:00 UTC
When using xev, I get: MotionNotify event, serial 28, synthetic NO, window 0x2400001, root 0x161, subw 0x0, time 19742380, (136,141), root:(139,269), state 0x10, is_hint 0, same_screen YES MotionNotify event, serial 28, synthetic NO, window 0x2400001, root 0x161, subw 0x0, time 19742440, (136,141), root:(139,269), state 0x10, is_hint 0, same_screen YES MotionNotify event, serial 28, synthetic NO, window 0x2400001, root 0x161, subw 0x0, time 19742744, (136,141), root:(139,269), state 0x10, is_hint 0, same_screen YES etc. The mouse doesn't move, but sends events. gnome-terminal should check the distance moved before showing the cursor.
Created attachment 229140 [details] [review] widget: Only show the cursor on motion if moved Some devices, like Wacom tablets, will emit mouse motion events even when the mouse doesn't move on the tablet. This means that the mouse cursor will show up on the screen very shortly after hiding. We now check the motion event against the last location of the mouse cursor to avoid this behaviour.
Would it make sense to check if the move is > drag threshold away from the last position (gtk_drag_check_threshold) instead of just comparing != ? That way it could compensate even against a jittery mouse.
(In reply to comment #2) > Would it make sense to check if the move is > drag threshold away from the last > position (gtk_drag_check_threshold) instead of just comparing != ? That way it > could compensate even against a jittery mouse. I don't think that we want to do that in vte. If it's implemented somewhere, it would be in the driver for that mouse, probably. Actually, I'd be inclined to point to a wacom driver problem here, and we could avoid this change in vte altogether. Peter?
Server problem actually. Two reasons this can happen: * devices with more than 2 axes may send events where only other axis values change, not x/y. the server doesn't filter those IIRC * devices with subpixel motion may move x/y but by less than a pixel and we still send core events for that even though they can't do subpixel. Both of the above can be seen with the wacom tablets, the second one will be harder to ix than the first but pls file a bug regardless. As for jitter: we have that in the drivers already, but you may still want to consider an application-specific jitter to guard against accidental bumps of the device in those apps where it makes sense.
Filed as https://bugs.freedesktop.org/show_bug.cgi?id=57383 Let's see if the problem still happens when the server is fixed (I've also noticed that it causes problems with text entries if the mouse cursor ends up overlapping the completion, and the screensaver never going to idle).
What's the status of the server bug?
unchanged. harder to fix than expected and currently not on the priority list
Created attachment 311273 [details] [review] widget: Only show the cursor on motion if moved Rebased the patch against current master. The move to C++ caused the file to be renamed.
Given that the server bug doesn't look like getting fixed, do you want to this workaround committed to vte? I think in the fuzzy-movement case we should also skip the hilight update on the line above, so probably this if should be moved up to the else {} making it an else if () {}. (And add a comment explaining the issue and linking this bug.) Finally: is this bug X specific, or will it also occur on wayland?
It's X specific. X started with integer-only coordinates, XI2 added subpixel precision. The problem is that subpixel events still send core events and to filter those out we'd require a per-client state of the last event coordinates/event mask sent. Then you can compare if the current coordinates are the same ones as the last ones and drop the event. The event delivery code in X isn't the easiest to grasp though, it's a bit complex to actually get this done. Wayland has 24.8 fixed-point coordinates, so this isn't an issue there.
I committed the workaround now.