I own an xp-pen drawing display tablet and I am having problems calibrating it on my Kinoite machine. I am assuming the reason for this is Wayland.
Although my device is not officially supported neither from linuxwacom or DIGImend the input itself (pen movement, pressure, tilt and buttons as well as the tablet’s buttons and wheel) surprisingly works out of the box (at least for the software I use, which is krita) EXCEPT for the screen orientation.
This is something I would fix with calibration (pressing on 4-5 points on the screen to properly set what I think it’s called “transformation matrix”), which is also needed to fix minor offsets in the input, but it appears to be quite hard on wayland specifically.
Coming from x11, I used to do this with xinput_calibrator/xcalibrate or similar projects (such as GitHub - Wcubed/calibrate_pen_display: A drawing tablet position calibration script for linux) but those are x11 specific and apparently won’t work on wayland.
According to the ArchWiki (Graphics tablet - ArchWiki) xsetwacom will not work either on wayland due to the fact tablets on wayland are managed libinput but I’ve not seen any guide or documentation to perform calibration with it that is as easily and comfortable as the options I mentioned above.
Hello @coffeetime03 ,
From the link you provided to the ArchWiki regarding tablets, it states both Gnome and KDE fully support graphics tablets monitors and key mapping. For Gnome I would think a series of gsettings affecting mutter would be where to look. You can check available gsettings with dbus-launch gsettings list-schemas. On KDE, the compositor is Plasma I think, but I have not used KDE in a long time so I can’t really say off the top of my head what you may need to look at for calibrating the tablet. Perhaps @hamrheadcorvette would offer some guidance as they use KDE for their work in related field.
This is a detail I should have included in my initial post. On kde I can find the drawing tablet section in the settings and it does allow me to link it’s input to a monitor (which I’ve used to correctly target the device to it’s own display) and also to configure/customize the 2 buttons on my pen (not the ones on my tablet or its scroll wheel) but it does not contain any option to calibrate the input. It does contain an orientation field, but all the available orientation settings appear to be incorrect and mirrored wrongly in one way or another (the closest one to my actual tablet I would say is the inverted portrait option).
Even if there was a correct orientation options, it still would not take away the need for calibration to get rid of incorrectness by smaller offsets.
I also think it’s worth saying that my tablet is also not fully supported by OpenTabletDriver. I’ve tried installing it in a toolbox/distrobox without much success.
Yeah calibration of the digitizer is sort of fundamental to the function of correct scaling translation, for say produced documents. I CADD often, and gave up a long time ago on using an actual tablet for it and settled on a track ball with 4096 resolution, but it still will give me issues when working on very large objects at scale. I spend a lot of time “cleaning up” connection points in my 2d drawings.
Meanwhile, for a shorter term solution, I was considering either trying to temporarily switch back to Xorg (I have some other very small issues with wayland unrelated to this thread) or trying installing OpenTabletDriver again.
Another very interesting idea I’ve got from looking for a libinput based calibrator is to try out xwayland.
Since out of those options the OpenTabletDriver one seems like the most feature rich one, how am I supposed to go around installing it in a toolbox/distrobox? I’ve not found much info about it so I am very unsure about tampering with my host system (without knowing exactly what I am doing) but I am guessing I’m supposed to uninstall (unlayer?) the existing kernel driver from the host and manually move the udev rule from the container to the host. Any guidance on this path?
About xwayland, I’ve not been able to have it working. I’ve started the session with Xwayland :12 -decorate which opens xwayland’s window but I cannot start any applications in it with commands such as env DISPLAY=:O konsole or DISPLAY=:12 konsole (they don’t appear in the new window and echo $XDG_SESSION_TYPE still returns “wayland”).
I don’t like how this approach is going, so I am likely going to try another one.
First I am trying using OpenTabletDriver again (but I would still like some feedback about my idea regarding moving the udev rule to host and removing existing drivers), then if it doesn’t work I am going to try installing xorg back.
I thought xwayland was just a part of Wayland to provide a compatibility layer for programs not quite ready for full wayland operation. I didn’t think it was something you as a user would invoke.
@coffeetime03 ,
Have you tried some of the libwacom stuff? Like libwacom-utils which is a package for working with devices with libwacom.
[jakfrost ~]$ dnf search libwacom
Last metadata expiration check: 1 day, 0:59:56 ago on Fri 07 Jun 2024 07:05:36 AM.
================================================== Name Exactly Matched: libwacom ==================================================
libwacom.x86_64 : Tablet Information Client Library
libwacom.i686 : Tablet Information Client Library
====================================================== Name Matched: libwacom ======================================================
libwacom-data.noarch : Tablet Information Client Library Data Files
libwacom-devel.i686 : Tablet Information Client Library Development Package
libwacom-devel.x86_64 : Tablet Information Client Library Development Package
libwacom-utils.x86_64 : Tablet Information Client Library Utilities Package
and info …
[jakfrost ~]$ dnf info libwacom-utils
Last metadata expiration check: 0:00:29 ago on Sat 08 Jun 2024 08:05:49 AM.
Available Packages
Name : libwacom-utils
Version : 2.11.0
Release : 1.fc40
Architecture : x86_64
Size : 17 k
Source : libwacom-2.11.0-1.fc40.src.rpm
Repository : updates
Summary : Tablet Information Client Library Utilities Package
URL : GitHub - linuxwacom/libwacom: libwacom is a tablet description library
License : HPND
Description : Utilities to handle and/or debug libwacom devices.
Yes, initially I thought it was only managed by the compositor but got confused by the fact the issue mentioned “having the calibration working only for xwayland window” which wouldn’t really make sense, in my opinion, with that little amount of control.
Actually I’m a Gnome User ! Always have been :gnome: & , I did some testing a long time ago during a Rollout on KDE and those threads are still here on the forums.
Your best bet is to install X11. I’m not on Kinoite and cannot test for you today but we have a couple threads going where we are testing Tablets in both KDE & Gnome with X11 & Wayland.
So outside of the usual I cannot provide anymore information.
I’ve installed plasma-workspace-x11 so right now I am running a xorg session.
It seems like the somewhat limited support I had for my tablet inside KDE is wayland specific:
The configuration I had on wayland is gone. Now, rather than being mapped to a screen (although incorrectly calibrated), the input is spread across all my screens.
The “drawing tablet” tab completely disappeared from KDE’s settings.
What I did not expect, however, is all my xinput commands having no effect at all with both running in a container and in host. Not only xinput map-to-output did not reduce the area the input is mapped to, the calibration scripts (as well as setting the Coordinate Transformation Matrix to some random values using xinput set-prop) also did not have any effect.
This could be related to me not having installed xp-pen’s proprietary drivers, for which I would have tried OTD instead, due to the partial functionality when running wayland KDE.
I’m going to comment so I can be reminded tomorrow to come back here and add what I can. I don’t want to confuse you, but I was under the assumption there was another X11 tool to install on KDE to get a good X11 experience on Plasma6 ?
What tool are you talking about?
Could it be that perhaps further setup is needed to have devices actually act as xinput devices rather than just installing the plasma-workspace-x11 and xinput packages?
I want to share one more thing I noticed while trying out reinstalling OpenTabletDriver, in case it is of any help or insight to anybody.
Running udevadm monitor on the host does react when I plug in the device but it doesn’t when I run it in the distrobox.
I was under the assumption that distrobox seemlessly integrates udev rules and such but, unless I am forgetting some argument, it does not seem like it. It is likely the reason OpenTabletDriver does not work within distrobox containers. I doubt that it would be any different with xp-pen’s proprietary drivers.
I also tried, without success, installing OpenTabletDriver directly on the host using rpm-ostree install ./OpenTabletDriver.rpm (using the rpm package provided by Linux Installation Guide - OpenTabletDriver).
EDIT: I managed to install it with the same command. There is also a Flatpak version of it.
Please continue sharing your experiences and any other test you come across. I’ll be doing a larger testing round this week, and will be updating these threads with my findings.
Atomic OS’s need a lot of attention in this space if Fedora is moving to a more Atomic future.
If you are talking about OTD (OpenTabletDriver), I doubt there is anything wrong on the legal side. I would agree adding it to the Fedora Repo could be a nice idea (especially for updating and auditing, I feel somewhat uncomfortable with the local package OTD provided on the host).
As for adding it by default in the installation I am not so sure, if this is what you mean by “added to the builds”. I say this because OTD conflicts with existing drivers which can potentially work better on supported devices such as wacom devices or supported DIGImend devices. As far as I know OTD is an awesome project but much smaller in size compared to linuxwacom or DIGImend, I don’t know how those devices behave under OTD.
I don’t know much about this though, so take my words with a grain of salt. I am sure it could be an interesting discussion.
, I did some testing a long time ago during a Rollout on KDE and those threads are still here on the forums.
