How a kernel update broke my stylus... Need help!
Blog post: https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
How a kernel update broke my stylus... Need help!
@davidrevoy one small detail cuz i own a surface pen: the eraser is actually an eraser on the back, albeit without pressure sensitivity. it is also a button (has 2 different actuation modes), and there's only one side button on surface pen.
@davidrevoy oh nooooo! (Un) fortunately I'm still on Mint's kernel series, but I hope someone will fix this...
@davidrevoy Did you include the cartoon with your bug report? If yes I bet it gets fixed sooner.
@davidrevoy Is there an option to just stick with LTS kernels on Fedora? I usually stick with LTS kernels because of situations like this 🤔 But it's good that you're reporting this issue.
@davidrevoy Since the kernel has a long standing policy not to break userspace, I expect that they will fix this — for example by accepting that the original commit had a conceptual problem that wasn’t detected due to the bug.
They write "These changes are tested in the following hid-tools regression tests:
https://gitlab.freedesktop.org/libevdev/hid-tools/-/merge_requests/127 " and I would hope that without the other bug this would have detected that the stylus button gets rendered useless that way.
But first of all: Good luck!
@davidrevoy This is just beautiful 😀
Never had such a beautiful illustration of Linux breaking stuff.
Also, my reading of https://gitlab.com/cki-project/kernel-ark/-/commits/fedora-6.5/drivers/hid/hid-input.c makes me think that it was busted by this commit?
Please file a bug report in the Red Hat Bugzilla against the kernel package. https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=38&component=kernel
@davidrevoy If you are able to compile a kernel by yourself, you could test if it actually is the one commit that you mentioned in your blog post.
Also, definitely let the kernel devs know that this broke your system.
You should probably file a bug report on github though.
@davidrevoy this is something open source projects sadly do too often. Just recently, Blender changed how point lights were interpeted lately, without any discussion on older files or implications for non-photorealistic rendering (that's been fun back and forth with the devs and I)
I suggest letting the kernel devs know, I'd imagine they'd take this pretty seriously (since rule number 1 of Linux kernel development is "don't break the userspace")
@davidrevoy didn't updated yet my kernel.. take care the old one that is working is not removed by an "autoclean" or something like this
I have to check, but few years ago a kernel change broke my XP Pen tablet recognition too
before this change, tweaking setup was easy, after it was really hard (had to play with udev to fix broken things, not on pen side but more related to tablet buttons)
@davidrevoy I use Krita/Inkscape on my SP6 running Linux and know this type of pain very well.
@davidrevoy I think I might have some interesting context for this:
Wacom "Penabled" does not have a second button but you can still get pens that have a second button for it. In those cases the second button switches the pen into a mode where the tablet thinks it's an eraser.
The Wacom Linux drivers have a workaround for that that detects when the pen suddenly turns into an eraser and interprets this as "upper button pressed".
Might be related in some way?
@davidrevoy I have a principle:
If you want stability, it's better not to touch
Any renewal is evil!
Maybe someone doesn't like it, but it's the only way to get a working machine always.
@davidrevoy : mais comment t’es arrivé à la conclusion que c’était le kernel?
J’aurais investigué tout tout tout avant le kernel!
It's like an actual https://xkcd.com/1172/ They fix a bug affecting the XPPEN Artist 24 Pro, and this @davidrevoy appears pointing out that broke his workflow and Linux shouldn't be forcing two eraser buttons on stylus devices, go figure.
Your post does show that you did your due diligence and found the culprit that caused that problem...
@davidrevoy In an extreme case, you could have the older driver packaged into a dkms rpm package. These get recompiled whenever the kernel is updated, so you don't have to compile the whole kernel with your customised drivers but you do get to have control over this one module.
But obviously, forking even a small bit of code can be a lot to take on. Better to get it fixed upstream somehow.
@davidrevoy I'm not sure your tablet model would work with it, but you can give a try to https://github.com/OpenTabletDriver/OpenTabletDriver/
I too have an Xp-pen tablet that broke with a kernel update. Luckily OpenTabletDriver works just as good as it used to work with the older kernel.
@davidrevoy Out of curiosity, have you tried the recent userspace driver provided by XP-Pen? I avoided it before because they had no tilt implementation on the Linux side, but I recently started using it and it seems to be working for me. I am on Kernel 6.5.9 and the XP-Pen app allows me to remap my stylus buttons.
@doctormo Thanks! Yes, it goes a bit beyond my current skill, but I started to have a look at how the digimend kernel module was doing things.
Making a small dedicated module that ensure the side buttons of stylus doesn't enter into any eraser mode sounds like a good idea if the situation become stagnant. I more and more understand how this modules can ammend existing code, and how they are not that hard to apply via DKMS.
But I lack of the main skill: editing the code. 🙃😆
@kkarhan Hi, thanks. It was done by developers and poeple expert in this area. They relayed my email to the mailing-list. I can't do more because I own only a single email adress at @protonmail , but it is not an email provider admited by the kernel mailing list (src: the doc of the kernel) as protonmail can't do plain text with proper line breaks and the encryption makes friction on the mailing-list. Something I wish I knew when I moved to Proton 5 years ago... So, I can't interact.
Not that I'd consider #ProtonMail at all but it's just a big red flag to me even if I were to use them, because if a provider is #paywalling #IMAP & #SMTP they should be better than any generic "#Freemailer" that doesn't.
Because that makes it useless for a lot of my tech stack: What's the point of an eMail provider if I can't use it with a #Zulip server?
@kkarhan @protonmail Yes, source: https://docs.kernel.org/process/email-clients.html , the last item on bottom of the page.
"Unless a way to disable this "feature" is introduced, Proton Mail is unsuited to kernel development."
@davidrevoy @kkarhan This is really an issue with WKD not having a mechanism by which the key server can indicate whether they want encrypted email by default or not. However, we can block kernel.org specifically to fix this, if they reach out to us.
@ploum Ben j'ai investigué tout tout tout avant le kernel. En fait, j'ai repris toute la stack, de libinput avec libwacom dedans, au module Digimend qui plug des truc pour tablets jusqu'au Kernel. J'ai choper des bons cernes et une nuit blanche dans le processus; mais chez moi, ce genre d'annomalie est litteralement le truc qui m'empêche de dormir. Je pense qu'on est beaucoup comme ça chez les geek libristes.
@davidrevoy : je me disais aussi. Ton post rend le tout fort simple mais ça sent les journées moisies et improductives à fouiller les mailing-lists, les repo git.
Mais, au final, t’auras fait la première page de HN et tu recevras ptêtre un bisou de Linus Torvalds pour raconter à tes petits enfants.
Yep, c’est ça le libre ! 😄
Courage et bon repos (en espérant que ça soit bientôt résolu)
(d’ailleurs t’as vu l’heure ?)
@ploum Oh, je savais pas que c'était sur HN, merci!
(et oui oui, j'ai fait le tour des issues de plein de projets, des mailing lists le tout en maudissant les moteurs de recherches 'modernes' ou je trouve plus rien.)
(oops pour l'heure, en plus il faut que je finisse mon sac: demain voyage jusque Saint-Brieuc pour l'expo malgrès vents et marés!)
@ElectroFetish I agree. I'm tempted to change my machine from Fedora KDE to Debian KDE to increase my peace of mind.
Then dnf will not try to upgrade a new kernel version. If I recall backing out the latest kernel was a pain. If I recall I updated my grub configuration to NOT use the latest as the default boot option, but explicitly set it to the last working one.
@jakob Hi, yes, it is probably related. I met this type of button on the Lenovo Yoga 370 (my full review and workaround: https://www.davidrevoy.com/article976/lenovo-yoga-370-on-gnu-linux-technical-companion-article ) It's still possible to inject something via xsetwacom. The syntax is a bit weird:
xsetwacom --set "$YogaEraser" Button 1 "key +ctrl button 1 key -ctrl" # color picker
(for a Ctrl color picker modifier) and an eraser icon still appears on Krita, but it pick colors. On the XpPen, this workaround even doesn't work.
@davidrevoy Yeah sadly the configuration options of most other tablet drivers on Linux are "meh" compared to the Wacom driver (and even that isn't perfect).
I would really like seeing the Wacom driver to be changed into something more generic so that xsetwacom (and GUI tools for it) work for all the other brands as well...
@davidrevoy looking at the Git history, this might be the culprit: https://github.com/torvalds/linux/commit/276e14e6c3993317257e1787e93b7166fbc30905
@standingpad Thank you, that's also where my conclusion (the link in the last paragraph) is redirected.
Unfortunately, letting the kernel dev knowing about this is really hard (no 'issues' on Github, and the doc for reporting is .... well https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html ). Doing a blog post was my best option.
@davidrevoy @standingpad So normally you would report this to your distribution (Fedora) since this is a distro kernel -- upstream maintainers don't really know what patches are in your fedora kernel and can't take responsibility for it.
That said, it looks like the linked commit is a fix that probably isn't in your newer kernel, so there's some hope an even newer Fedora kernel will "magically" have the fix in a little while.
Ping @efi ; do you think it is still safe to send the issue to the kernel mailing list? I don't want to do any "faux pas" 🙂
Thanks for the recommandation. I think the info is in the right pipes now.