Wacom calibration troubleshooting on Fedora

My colleague Madeline Peck have the same laptop that we each got late this past fall. It’s the Lenovo Thinkpad X1 Yoga Gen 6, and it is a dream computer, with integrated Wacom screen and stylus 🙂

Recently though, Madeline noticed the cursor was a bit off from where she placed the stylus on the screen. The issue only seemed to be happening in Krita, but was enough to cause an issue. I suggested trying the GNOME Wacom calibration tool in GNOME Settings, thinking that even though there was a slim chance it’d help (since the issue only affected Krita), at the very least it wouldn’t do any harm and might improve the X,Y calibration of the tablet.

It threw the calibration off a good 4 inches. Repeated calibrations using the tool didn’t improve the issue.

A few notes:

• High DPI screens here (3840 x 2400)
• Integrated Wacom screen in a laptop form factor (identifies itself as ISDv4 527e)
• Fedora 35, fairly recent install (~2 mo)
• Using Wayland (the F35 default)

Investigating the issues

Now there’s two issues here, one of which is Krita-specific, and one which affects the entire GNOME desktop.

Krita miscalibration

The Krita-specific issue I believe had something to do with an older code base. On the same hardware with the same OS, I could not reproduce the issue. Madeline was running the latest Fedora RPM of Krita (v. 4.5.x) whereas I was running the latest Krita flatpak (v. 5.0.x.) When Madeline removed the RPM and installed the flatpak, that Krita-specific issue went away.

GNOME desktop miscalibration

Now, the desktop-wide issue, in order to get a functional stylus setup back as quickly as possible, involved figuring out where the calibration data is written out from in the GNOME Wacom calibration tool, and either copying a known working set of calibration data (from my laptop), or resetting it. (The GNOME Wacom tool unfortunately does not have a reset button anywhere in the UI.)

GNOME Settings Wacom calibrator code

I started with the source code for the GNOME Wacom tool and in the main.c I noticed the usage function that prints off usage information, and it had the following line:


fprintf(stderr, "\t--precalib: manually provide the current calibration setting (eg. the values in xorg.conf)\n");


I was a little too excited about this (it didn’t end up helping, but I thought it might be a way to reset the calibration to match my functioning device’s) but I did search for the “–precalib” flag assuming it may be coming from elsewhere. Indeed, it comes from xinput_calibrator – but this appears to be a tool for Xorg, and since we’re running Wayland, we’re using libwacom.

libwacom

So I started digging into how libwacom works, to see if libwacom does any kind of calibration for Wacom. I looked at the packages installed on my system:


[duffy@pocapanda ~]$ rpm -qa | grep wacom
xorg-x11-drv-wacom-serial-support-0.40.0-2.fc35.x86_64
xorg-x11-drv-wacom-0.40.0-2.fc35.x86_64
libwacom-data-1.12.1-1.fc35.noarch
libwacom-1.12.1-1.fc35.x86_64


I took a look at what stuff was inside the libwacom package:


[duffy@pocapanda ~]$ rpm -ql libwacom
/usr/bin/libwacom-list-devices
/usr/bin/libwacom-list-local-devices
/usr/bin/libwacom-show-stylus
/usr/bin/libwacom-update-db
/usr/lib/.build-id
/usr/lib/.build-id/1a
/usr/lib/.build-id/1a/9d86c5f1ae89f44b9f556d77abf4c04d2e520a
/usr/lib/.build-id/1c
/usr/lib/.build-id/1c/bb4db3e08afe981d9a4672b601bfa54298b610
/usr/lib/.build-id/79
/usr/lib/.build-id/79/8f2d55d77471d6460f53362cfd30781c9435a5
/usr/lib64/libwacom.so.2
/usr/lib64/libwacom.so.2.6.1
/usr/share/doc/libwacom
/usr/share/doc/libwacom/README.md
/usr/share/licenses/libwacom
/usr/share/licenses/libwacom/COPYING
/usr/share/man/man1/libwacom-list-devices.1.gz
/usr/share/man/man1/libwacom-list-local-devices.1.gz


And I took a look at where the libwacom-data package was putting stuff on disk:


[duffy@pocapanda ~]$ rpm -ql libwacom-data
/usr/lib/udev/hwdb.d/65-libwacom.hwdb
/usr/lib/udev/rules.d/65-libwacom.rules
/usr/share/doc/libwacom-data
/usr/share/doc/libwacom-data/COPYING
/usr/share/libwacom
/usr/share/libwacom/bamboo-0fg-m-p-alt.tablet
/usr/share/libwacom/bamboo-0fg-s-p-alt.tablet
/usr/share/libwacom/bamboo-0fg-s-p.tablet
/usr/share/libwacom/bamboo-16fg-m-pt.tablet
/usr/share/libwacom/bamboo-16fg-s-p.tablet
/usr/share/libwacom/bamboo-16fg-s-pt.tablet
/usr/share/libwacom/bamboo-16fg-s-t.tablet
/usr/share/libwacom/bamboo-2fg-fun-m-pt.tablet
/usr/share/libwacom/bamboo-2fg-fun-s-pt.tablet
/usr/share/libwacom/bamboo-2fg-m-p.tablet
/usr/share/libwacom/bamboo-2fg-s-p.tablet
/usr/share/libwacom/bamboo-2fg-s-pt.tablet
/usr/share/libwacom/bamboo-2fg-s-t.tablet
/usr/share/libwacom/bamboo-4fg-fun-m.tablet
/usr/share/libwacom/bamboo-4fg-fun-s.tablet
/usr/share/libwacom/bamboo-4fg-s-pt.tablet
/usr/share/libwacom/bamboo-4fg-s-t.tablet
/usr/share/libwacom/bamboo-4fg-se-m-pt.tablet
/usr/share/libwacom/bamboo-4fg-se-s-pt.tablet
/usr/share/libwacom/bamboo-one-m-p.tablet
/usr/share/libwacom/bamboo-one.tablet
/usr/share/libwacom/bamboo-pad-wireless.tablet
/usr/share/libwacom/bamboo-pad.tablet
/usr/share/libwacom/cintiq-12wx.tablet
/usr/share/libwacom/cintiq-13hd.tablet
/usr/share/libwacom/cintiq-13hdt.tablet
/usr/share/libwacom/cintiq-16-2.tablet
/usr/share/libwacom/cintiq-16.tablet
/usr/share/libwacom/cintiq-20wsx.tablet
/usr/share/libwacom/cintiq-21ux.tablet
/usr/share/libwacom/cintiq-21ux2.tablet
/usr/share/libwacom/cintiq-22.tablet
/usr/share/libwacom/cintiq-22hd.tablet
/usr/share/libwacom/cintiq-22hdt.tablet
....


(So on and so forth the list continues.)

Those Wacom command-line utilites looked potentially helpful, though. So we ran libwacom-list-local-devices:


[duffy@pocapanda ~]$ libwacom-list-local-devices
devices:
- name: 'ISDv4 527e'
bus: 'i2c'
vid: '0x056a'
pid: '0x527e'
nodes:


I figured out that the .tablet files in /usr/share/libwacom had a file that corresponded to the device name:


[duffy@pocapanda libwacom]$ ls * | grep 527e
isdv4-527e.tablet


I took a look at the file, which included the following:


[Device]
Name=ISDv4 527e
ModelName=
DeviceMatch=i2c:056a:527e
Class=ISDV4
Width=12
Height=7
IntegratedIn=Display;System
Styli=@isdv4-aes;

[Features]
Stylus=true
Touch=true
Buttons=0

So it was thusly that I dug around in /usr/share/libwacom. Based on that and the libwacom README, I figured that libwacom isn’t managing calibration – it does have device profiles in a .tablet format, but these don’t contain calibration data or defaults that I could tell.

Where is that calibration data installed???

It’s in dconf!

I flailed about in ~/.config, no luck. Then I thought, maybe dconf? I searched online for “dconf wacom” and found this helpful page on the Arch wiki:

https://bbs.archlinux.org/viewtopic.php?id=271284

So we took a look at what the dconf values were on Madeline’s tablet:


$ conf read /org/gnome/desktop/peripherals/tablets/056a:527e/mapping
'absolute'
$ dconf read /org/gnome/desktop/peripherals/tablets/056a:527e/area
[0.0014756917953491211, 0.49991316348314285, -0.0015972219407558441, 0.50215277448296547]
$ dconf read /org/gnome/desktop/peripherals/tablets/056a:527e/output
['', '', '']


On my tablet it said:


$ dconf read /org/gnome/desktop/peripherals/tablets/056a:527e/mapping
'absolute'
$ dconf read /org/gnome/desktop/peripherals/tablets/056a:527e/area
[0.0, 0.0, 0.0, 0.0]
$ dconf read /org/gnome/desktop/peripherals/tablets/056a:527e/output
['', '', '']


The Arch Linux wiki article suggested just doing a reset on the values, so we did that for the area since that was the only key value that differed between the two laptops:


dconf reset -f /org/gnome/desktop/peripherals/tablets/056a:527e/area


That fixed it! 🙂

Why??

A couple of ideas I got from Ray of how this could have happened:

For the GNOME Wacom calibration tool repeatedly failing: these are ~4Kish screens at 3840 x 2400, and with a discrepancy that large it may be some kind of hi-DPI calculation issue. Perhaps the calibration tool isn’t taking into account the scale factor for the GNOME UI.

For the Krita issue – I think it was just older code; perhaps Fedora 35 has some libraries that cause the pointer to be slightly offset or something in Krita? The gap between stylus and cursor wasn’t nearly as large in Krita, so it might be a more minor thing like that.

I had the same model of laptop throughout this, so I knew I can try to reproduce on my own and get a proper bug report going. My priority was to fix it ASAP. This post is oriented towards helping anyone who finds themselves stuck in the same situation getting out of it! (I will update this post with a link when I have a bug report written up.)

UPDATE: Jason Gerecke kindly pointed me to a pre-existing bug report on this issue: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1441