The subpixel-precise root and event coordinates contained in an XIDeviceEvent do not seem to always exactly equal the value one would expect. In particular, when compared to the valuator data which is its source, the values sometimes take on an unexpected noise or jitter. I have tested with several Wacom tablets and seen the issue with each. After disabling the driver's smoothing and filtering and forcing the acceleration profile to -1 (None)[1], I run both evemu-record and 'xinput test-xi2' to gather data. Comparing the kernel events to the valuators, I see that they are either left as-is (if the tablet is mapped to the whole desktop) or correctly modified to reflect the transformation matrix (if the tablet is mapped to just one monitor). The root and event coordinates, however, don't match up with expectations, with the delta changing from event to event. See, for instance, the following table: Hardware | Raw Valuator | Valuator | Root | Expected | Delta ----------+--------------+----------+--------+----------+--------- 9456 | 9456.0 | 9456.0 | 164.70 | 167.70 | -3.00 9589 | 9589.0 | 9589.0 | 167.17 | 170.17 | -3.00 9675 | 9675.0 | 9675.0 | 170.76 | 171.76 | -1.00 9735 | 9735.0 | 9735.0 | 171.87 | 172.87 | -1.00 9809 | 9809.0 | 9809.0 | 172.24 | 174.24 | -2.00 9880 | 9880.0 | 9880.0 | 174.55 | 175.56 | -1.01 9974 | 9974.0 | 9974.0 | 175.29 | 177.30 | -2.01 10033 | 10033.0 | 10033.0 | 177.39 | 178.39 | -1.00 10066 | 10066.0 | 10066.0 | 179.00 | 179.00 | 0.00 10121 | 10121.0 | 10121.0 | 178.02 | 180.02 | -2.00 This table contains the X values reported by the kernel, the RawMotion event valuator, the Motion event valuator, and the Motion event root coordinate. The "expected" value is calculated using the information about my particular setup[2]. Looking at much more data than shown above, I notice that the Delta is always an integer value[3] and that while it is usually small in some cases it is several pixels large. It also looks like the delta can vary over time: looking at only the X coordinate, I see that events at the same X will occasionally have different deltas. I'm not sure what's going on here... It seems to be causing some trouble for Krita and Qt developers[4], who are considering processing the valuators instead of using the root/event coordinates because of the jitter. As mentioned earlier, I've disabled everything I could think of that would modify the coordinates behind my back (driver smoothing, driver filtering, server acceleration) but perhaps I'm missing something? [1]: `xsetwacom set $ID rawsample 1 && xsetwacom set $ID suppress 0 && xinput set-int-prop $ID "Device Accel Profile" 32 -1` [2]: I was using a Cintiq 24HDT as the single monitor on my system. With the tablet geometry being 103680x64800+200+200 and both the desktop and monitor geometry being 1920x1200+0+0, the first table entry can be calculated as follows: (9456-400) / 103680 * 1920 * 1.0 = 167.70 [3]: The occasional "0.01" in the Delta column is due to "Root" not being reported with full precision. [4]: https://bugreports.qt.io/browse/QTBUG-48151
Created attachment 118555 [details] Script to check if jitter is present I've attached a script that may be useful in checking for the existence of the issue. Run with the device ID of a Wacom tablet, it will gather data from `xinput test-xi2` and calculate the expected values as well as the apparent delta.
ok, I think I found the core issue. The data in the events is originally correct, fill_pointer_events() does the right thing. But during ProcessDeviceEvent we call GetSpritePosition() and overwrite the event's root x/y coordinates. And that can be a pixel or so out, though I'm not 100% sure why yet, probably a rounding error elsewhere.
ok, it's not a rounding error, it's a bigger problem. The event flow in the server is that the slave device event is processed first, then the master device event. If the SD is attached it doesn't have a separate sprite but instead uses the one from the master device. That's where the discrepancies come from. When the new event comes in, the slave calls GetSpritePosition() to get the current position of the sprite (it may have moved since the last event, either from another slave or through warp pointer requests, confinements, etc.). It uses that position in the event root coordinates, but the position is still the one from the last event. Then the master device is updated, the sprite position changes to the new (correct) position, the data in the master device's event is correct. So the jitter is equivalent to the delta between the last event and the current one, but because of truncating from doubles to ints and back it is amplified a bit. The jitter is always close to an integer, i.e. a full pixel. Or close to zero. Example: * slave device is at to 101.1/200.0, * master updates sprite to 101/200 * slave device moves to 100.5/200.0 ** event root_x/y is 100/200, fractional parts are 0.5/0.0 * GetSpritePosition() in ProcessDeviceEvent() returns 101/200 * fractional parts are added to coordinate again, result is 101.5/200.0, causing a jitter of 1.0 I don't know how to fix this yet.
How is it going with that?
no-one is currently working on this
Well what should we do about it then? It's not acceptable for Qt users if this is really still unfixed for so long. Do we have to process the valuators ourselves? Do you still not know how to fix the X server?
I still don't know how to fix the X server and tbh I don't have a lot of time to work on this, sorry.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/586.
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.