As filed originally in https://bugzilla.gnome.org/show_bug.cgi?id=688456 We receive motion events for a mouse sitting still on a Wacom tablet (in my case on an Intuos4 tablet). Peter said: > 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.
Created attachment 71710 [details] [review] 0001-dix-skip-subpixel-only-core-motion-events-57383.patch tentative patch, breaks three test cases here but I think this is a test case issue.
Much better, gets rid of some of the jitter, but it's not enough to fix some pretty bad problems: - in some (physical) positions, the cursor will move between 2 very close locations. This will be visible on the screen, and causes gnome-terminal not to be able to hide the cursor for example. - Some events are still delivered such that leaving the cursor within reach of the URL completion popup of the web browser will cause an unwanted item to be selected. Could still be a problem with the first item.
What physical device is this, and when/how does it occur? Does evtest show a fuzz for x/y on that device? does evtest show events when this occurs? I have similar issues with one of the USB mice I have, but the movement is random, hardware-related and too high to filter it (tens of pixels).
Intuos 4 M with the 5-button mouse.
(In reply to comment #3) > does evtest show events when this occurs?
Created attachment 76473 [details] foo This is the output of evtest dropping the mouse, and removing it from the tablet, without moving it.
Thanks. evtest shows a fuzz of 4 for the x/y axes. In the wacom driver we use a default of 2 atm, I'll look into updating the wacom driver to use the device-specific value. However, the input data also shows that the actual input data is higher than the claimed fuzz (highest here appears to be 6 device units). So the problem would remain. I suggest using Option "Suppress" in a config snippet for the wacom device to avoid the jitter. As long as the movement is across pixel boundaries, we cannot really discard them in the server since we have no heuristics to detect erratic movement vs real movement.
This is a mass change of bugs. Bugs assigned to me that haven't been updated in the last 3 years are closed as WONTFIX, because, well, let's at least be honest about it. Please do not re-open unless you have a really good reason to do so (e.g. you're fixing it yourself). If it hasn't been fixed in the last 3 years, it probably won't be fixed anytime soon either. Sorry.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.