How a kernel update broke my stylus... Need help!

What's the problem?

In short, after a Linux kernel update (6.5.8-200.fc.x86_64 on Fedora KDE), I can't use the top button of my pen on my tablet. This is really affecting my digital painting workflow!

Right-clicking on the pen is an essential part of my workflow. Right-click on a layer in Krita to get the menu, right-click while using the Transform tool to get the transformation options, right-click on the canvas to get the pop-up palette! ...And I'm not even talking about how difficult it is to handle files and the D.E. without right-clicking.

And if that makes you smile, imagine someone hardcoding the behaviour of your main device like the right-click on your mouse or touchpad (or anything else you have been using for more than 20 years) to something completely useless, and pushing it through kernel updates. And the icing on the cake, they left you with no user tool to change it back.

That's where I am now, and you can probably understand why I decided to write a blog post about it. Because my ability to use my tablet and thus continue my webcomic Pepper&Carrot under Linux is now tied to an older kernel, 6.4.15-200.fc38.x86_64, until a kernel developer fixes this situation.

Grub page at startup: I now have to select the second kernel to escape the bug..

What happened?

Context: My XPPen 24 Artist Pro is my default tablet for productivity since April 2023. This tablet doesn't have a proper tablet driver under GNU/Linux. But it works thanks to a generic driver in the Linux kernel for the Uc-Logic/Ugee device; that is the name of the digitiser inside the tablet, the circuit board if you prefer. I also top this with some code from the Digimend-Kernel-Module. It requires a set of X11 rules and tweaks that I document in my review, but once that is done, you can customise the stylus buttons using the xsetwacom command line tool.

Unfortunately, in the newer Linux kernel of my distribution (6.5.8-200.fc.x86_64), there were some new commits that affected the behaviour of this generic hid-input.c driver. I don't know where it came from, but it was decided to hardcode a behaviour for styluses to have an 'eraser mode' instead of a 'right-click' on the second (top) button of the stylus.

For reference, here is the default on GNU/Linux, and has been since at least 2009 when I started drawing with it:

• Button 1 (pen tip) = left mouse click; to select, to draw, etc...
• Button 2 (down, on the side of the pen) = a middle mouse button, for panning the canvas or scrolling pages.
• Button 3 (at the top of the pen) = a right click, for context menus.

The stylus of the XP-Pen Artist Pro 24, with the location of the second button underlined.

Where did the idea come from to map an eraser mode to a stylus button?

I can only speculate about this, but as far as I know, this type of behaviour was introduced by Microsoft for their Surfaces device on Ms Windows as a probable workaround for being too cheap to put an eraser on the other end of the stylus.

These Surfaces were aimed at business people and, as you can imagine, the pen was not intended to be used for drawing, but for signing documents or annotating PDFs. A side button eraser made sense to them. But what about right-clicking, you might ask? Well, these are 'touch' devices; the user could always use their finger with a long press and trigger a contextual right-click menu.

Soon after, I think Lenovo, HP and other tablet PC manufacturers were quick to imitate this new behaviour as brave sheep, and also to save some money on making styluses without a proper eraser on the other side.

So I can understand why a kernel developer thought it would be a good idea to bring this to GNU/Linux devices. Except they didn't just add it as a feature. It was forcing the behaviour on all users of the generic driver at the lowest possible level.

So I've lost my right-click on the second button of my stylus. And my device doesn't have a "touch mode".

Worse, ironically it even forces this behaviour on the stylus of my newer XPPEN 16 Artist Pro (Gen2) that I'm testing. Brace yourself: a stylus with a real eraser... This left me speechless.

The bug even affects stylus with an Eraser device, as on this stylus of the XP-Pen Artist Pro 16 (Gen2).

Can't you just customise a button on your Linux system?

This is the best part: no, you can't.

Because you see, instead of just sending a single event that could later be customised by a CLI tool like xsetwacom, a desktop environment like kcm-tablet Plasma Panel, or even a udev rule; this kind of behaviour is hardcoded in, so the button sends too many events to map to anything. The button doesn't trigger a key, it switches the whole device to something else when pressed.

From my understanding; forcing this behaviour for the Uc-logic/Ugee generic tablet has been done for a long time; but a "bug" kept the stylus of my XPPEN Artist 24 Pro out of it, and this commit probably fixed it in the worst for me. I now know it is there for a long time, because even with the "old" kernel, my newer XPPen 16 Pro (gen2) also reacts this way.

And no tools can fix it now. Are we doomed to have an eraser on the second key?

Or is there anything else we can do?

Please help if you can.

Update:

2023-11-09: It works! Benjamin Tissoires made a solution. I tested it and I'm no longer locked to a kernel, you can know more about it on the Mailing list. The solution solves the issue for the two devices I have.
2023-11-07: You can follow the discussion on the Linux kernel mailing list here.
2023-11-01: (Additional technical infos) Here are two evtest screenshots of the two devices with the newer kernel while performing a top button on the stylus (click to enlarge).