@davidrevoy nooooooooo that's awful 😭 Hope you can figure it out!
@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.
@davidrevoy I believe most of this stylus support was written by @jose_exposito. Maybe he can help fix this?
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?
https://gitlab.com/cki-project/kernel-ark/-/commit/6360b396e81b5295aa9ee3d4f9af13b9bbbbac65
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.
@davidrevoy Ask the linux devs. @torvalds is on here at least. As well as @linux and @vegard
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 when is your book of illustrated bug reports coming out?
:)
@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.
@davidrevoy I do recommend you to open up an #issue with the #LKML if this issue is also reproducible on other distros with the same or newer #kernel.
Your post does show that you did your due diligence and found the culprit that caused that problem...
https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html
@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.
@davidrevoy so let me get this straight: @protonmail fucks with customers' eMails?
That's a huge no-go IMHO because that's just inexcuseable!
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 Seriously, WTF @protonmail ?
#YouHadOneJob as #eMail #Provider and that is to get shit reliably sent and recieved.
If that's too hard then how should anyone trust them re: #security and #privacy?
Spoiler: Noine should!
https://www.youtube.com/watch?v=QCx_G_R0UmQ
@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.
@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...
@jakob Same, a universal "tablet GUI" cross distro and cross D.E. would be great...
@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.
@vegard @standingpad Thank you for the information.
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" 🙂
@davidrevoy @vegard @standingpad maybe not, send it directly to the maintainer as a regular mail
@efi @vegard @standingpad Email sent to four maintainer and reviewer involved, and Jiri Kosina just replied adding CC to 9 other people involved and mailing-list. 🎉
Thanks for the recommandation. I think the info is in the right pipes now.
@davidrevoy @torvalds @linux @vegard
Or find the maintainer of the driver and report to them
@Hobs Hi, that's what I'll try. But it is a bit more complicate to report a bug to the kernel than just opening a thread on the Github "issues". If you look at it, you'll not even see such a section on Github: https://github.com/torvalds/linux
Here is how you have to do it: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html , and even the TL:DR; would require a TL:DR; written by someone not confusing, imo. Good luck.