GNOME Bugzilla – Bug 784009
Wacom pen calibration does not properly fix cursor offset
Last modified: 2017-07-05 21:56:20 UTC
When a Wacom tablet is calibrated through GNOME Control Center, the cursor offset is not properly corrected. Using the calibration utility can even make the offset noticeably worse in some cases. It appears that issues in both g-c-c and Mutter are to blame: the former saves incorrect data into gsettings and the latter may incorrectly apply whatever settings have been saved.
Created attachment 354116 [details] [review] mutter: backends: Correct argument order of *_set_tablet_area
Created attachment 354117 [details] [review] mutter: backends/native: Interpret tablet padding as being input-centric
Created attachment 354118 [details] [review] g-c-c: Use axis rather than padding in calibration calculations
Comment on attachment 354116 [details] [review] mutter: backends: Correct argument order of *_set_tablet_area Hmm, this one doesn't look right... According to the setting description at https://git.gnome.org/browse/gsettings-desktop-schemas/tree/schemas/org.gnome.desktop.peripherals.gschema.xml.in#n117 : "(Values are) Respectively applied to left,right,top and bottom sides" And I see mutter is consistent with this: https://git.gnome.org/browse/mutter/tree/src/backends/meta-input-settings-private.h#n89 https://git.gnome.org/browse/mutter/tree/src/backends/x11/meta-input-settings-x11.c#n602 https://git.gnome.org/browse/mutter/tree/src/backends/native/meta-input-settings-native.c#n446 I'm not saying it was the most brilliant idea to change argument order in the new setting, but probably means it's g-c-c which is doing it backwards.
Comment on attachment 354117 [details] [review] mutter: backends/native: Interpret tablet padding as being input-centric Looks good! Thanks for tracking this down.
(In reply to Carlos Garnacho from comment #4) > > I'm not saying it was the most brilliant idea to change argument order in > the new setting, but probably means it's g-c-c which is doing it backwards. Ah, had no idea the order changed as well. I'll whip up an alternate patch.
Created attachment 354128 [details] [review] g-c-c: wacom: Correct order of area calibration values Alternative version of the argument order correction patch. Applies to g-c-c instead of mutter.
Created attachment 354129 [details] [review] mutter: backends/x11: Account for non-zero device origin when setting tablet area Another small correction for X11 I just noticed...
Comment on attachment 354129 [details] [review] mutter: backends/x11: Account for non-zero device origin when setting tablet area Thanks, I hadn't noticed the small delta.
Comment on attachment 354128 [details] [review] g-c-c: wacom: Correct order of area calibration values That is consistent with the schema format.
Created attachment 354748 [details] [review] wacom: Drop old_axes from calibration API The calibration utility was modified in cf408c27b0 to return unitless padding measurements instead of axis values for storage in gsettings. Unfortunately, the code still assumes in some places that it is working with axes rather than paddings. This causes subtle math errors that result in undesired cursor offsets after the calibration is applied. Fortunately, this can be simplified, since tablet area is always reset to the default state before starting calibration, we are sure that the value will remain constant. Since both axes are in the same 0..1 scale, calibration code doesn't need to swap X/Y back and forth to calculate each axis scale. Additionally, the code to get the calibrated axis values has been moved into its own function along with a new function that returns padding values suitable for consumption by g-c-c. All calculations are performed internally in the 0..1 range. https://bugzilla.gnome.org/show_bug.cgi?id=784009 Co-Authored-By: Carlos Garnacho <carlosg@gnome.org>
I picked your patch and changed it so it keeps using 0..1 ranges, as far as I could test the end result is just the same, but please confirm it fixes the calibration oddities you were seeing :) Your second patch (the one marked a-c-n) still applies on top.
Review of attachment 354748 [details] [review]: This patch looks solid to me and appears to work fine. All the "precalib" related code from main.c could also be removed, but that could easily be ignored or done in a later patch.
(In reply to Jason Gerecke from comment #13) > Review of attachment 354748 [details] [review] [review]: > > This patch looks solid to me and appears to work fine. All the "precalib" > related code from main.c could also be removed, but that could easily be > ignored or done in a later patch. Hmm, thinking twice about it, the calibrator test doesn't touch up settings, so it may actually have other applied calibration than the default. That said, I much prefer having cleaner code than catering for a feature in a noinst app that is clearly oriented to non-users, I wonder how much people found/used the xorg.conf.d snippet producing feature :). I filed bug #784473 to follow up with that anyway.
Comment on attachment 354129 [details] [review] mutter: backends/x11: Account for non-zero device origin when setting tablet area Pushed attachment #354129 [details] to mutter master/gnome-3-24
Review of attachment 354118 [details] [review]: Just to be clear: this patch has been superseded by attachment 354748 [details] [review].
I think everything is pushed now :). Attachment 354118 [details] pushed as 978ccdc - wacom: Correct order of area calibration values Attachment 354748 [details] pushed as 50b39dc - wacom: Drop old_axes from calibration API