Skip to main content

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.
@cherryband Ha, true. Exact; a long press on it is also used to wakeup the device or pair it in Bluetooth (or another protocol) as far as I remember?
yes there's single, double, and long press. pressing it for 5 seconds or something brings it into bluetooth pairing mode. it also has a magnetic sensor which turns it off when attached to a surface tablet.
This entry was edited (10 months ago)
oh nooooo! (Un) fortunately I'm still on Mint's kernel series, but I hope someone will fix this...
I assume you already told the linux devs?
@efi No, I can't. They removed the issues on https://github.com/torvalds/linux and I couldn't understand where to locate a replacement in this https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html , I need help even to report the issue.
in this page https://www.kernel.org/doc/html/latest/process/maintainers.html#maintainers you can scroll down (^F usb hid) and see that the maintainer of the hid drivers is mentioned in the commit you linked, so you'd want to email linux-usb@vger.kernel.org with CC jikos@kernel.org and just tell them about the problem, link them to the article and ask them to forward it if someone else should know
@efi Thank you for the assistance. I'll do. ๐Ÿ‘
make sure to mention you are not making a proper bug report because you are not a kernel developer so they forward it to whoever can actually make the report
@efi this sucks so bad, I'm so sorry. In the commit you found, there are the email addresses of the people involved on the change, might be worth it checking in with them? I hope you find a solution.

@grilix Thank you Gonzalo, it was done, I was well adviced. ๐Ÿ˜‰

You'll find my email who now reached the mailing list: https://lore.kernel.org/linux-input/nycvar.YFH.7.76.2311012033290.29220@cbobk.fhfr.pm/

@efi

@grilix I think next time you should https://jort.link/ it so the site doesn't get ddos'd

@efi Oh thank you. Very interesting tool and content. I learned something with it, I had no idea Mastodon did that.

I also just learned my blog post is in homepage of Hacker News , and the link is part of the comments: https://news.ycombinator.com/item?id=38102023

Poor mailing-list server. :blobwhistle:

@grilix

looks like it's making ripples like a good ol' kernel bug should lmao
Did you include the cartoon with your bug report? If yes I bet it gets fixed sooner.
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.

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!

This is just beautiful ๐Ÿ˜€

Never had such a beautiful illustration of Linux breaking stuff.

๐Ÿ‘† Who would be best to talk about this, @cas ?

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

This entry was edited (10 months ago)

@Conan_Kudo indeed, I added support for a bunch of XP-Pen tablets, but none of them was an Artist.

I believe the commit you mentioned is causing the issue. Since you already submitted it upstream, the author will probably look into it and fix it.

If you are willing to test a with me a kernel driver I can add support for your tablet on the UCLogic driver and get it to work with no/minimum configuration. Feel free to ping me and I'll help you.

@jose_exposito Hey Jose, thank you for your work on the built-in drivers :blobcatheart: I'm familiar with your work thanks to the news on Phoronix ( https://www.phoronix.com/news/Linux-5.20-XP-PEN-Deco-L or https://www.phoronix.com/news/XP-PEN-Deco-01-V2-Linux-6.2 ) that I read carefully, especially when it is about tablets ๐Ÿ™‚

Sure, I can collaborate and give you as many feedback as necessary and tests. Thank you! You know my email now (you are in CC on mail thread "Requesting your attention and expertise regarding a Tablet/Kernel issue")

@Conan_Kudo

@Conan_Kudo It looks like Benjamin is going to handle it. Which is great, because I can only work on this during the weekend and he'll be able to provide a fix way faster ๐Ÿ˜€

@jose_exposito Thanks, I just read the mailing-list. I'll go back in the backlog of it to provide all information asked. I'm not sure if Eric answer contains everything.

@Conan_Kudo

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.

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.

@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๐Ÿ˜R; would require a TL๐Ÿ˜R; written by someone not confusing, imo. Good luck.

You have the contact info for the main dev right there in the link in your blog post. E-mail him https://github.com/torvalds/linux/blob/master/drivers/hid/hid-input.c
That's the best way to illustrate a bug.

didn't updated yet my kernel.. take care the old one that is working is not removed by an "autoclean" or something like this :ablobcatknitsweats:

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)

I use Krita/Inkscape on my SP6 running Linux and know this type of pain very well.

@tanavit Yes.

Good idea for the evtests, I added a new screenshot in the footer of the article with evtest events for the two tablets.

nooooooooo that's awful ๐Ÿ˜ญ Hope you can figure it out!
i was gonna ask if you could git-bisect to see exactly what code changed this, but it seems like you dug deep enough to figure out whats going on. so are you looking for a workaround, a code patch to revert to the old behaviour, or do you just want this fixed upstream?

@opal Thanks, yes, that's where I am. Thank you for reading and understanding.

I would like both I think:
- A short term 'workaround' in priority if someone knows a tool able to bypass this type of BTN_TOOL_RUBBER events in the userspace and give back a Mouse right click instead would be great.
- I also would like if the issue can be fixed at origin; or assistance in how I could get a better support of the tablet without having to relly on the generic driver. But that's more long term, imo.

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")

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.

@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" ๐Ÿ™‚

@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.

Use email, that's how the kernel is developed and how bugs are reported, send it to the author of that commit and the mailing list listed in the MAINTAINERS file for the subsystem.

No need to file some ticket in some random web form with some odd account, email. It's simple, and easy (note, turn off HTML mode for it please.)

Good luck!

@gregkh Thank you about the formating tip (in plain text mode) I'll do my best!

@standingpad

Mind capturing libinput events? Does it correspond to 0x141?

@elly Mind capturing, mind capturing :blobaww: I have to try! ๐Ÿคฃ

(About the name/id of the events; I added a new screenshot at the end of the article; with evtest of the two tablet while pressing the button.)

@elly
oh god, this sounds like a nightmare. I'm also very reliant on that button on my Wacom tablet being a right click.

@kapellosaur :blobcatheart: Thank you for understanding. I hope it will be fixed!

(If it does, I'll draw a Tux repairing the stylus โ˜บ๏ธ )

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?

@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.

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...
This entry was edited (10 months ago)

@zaki Hi, Zakaria; oh, there are more than one but they are rarely functional or working.

Have you tested it on Linux? with what tablet model?

@jakob

Of course, I already made a tutorial about it in my channel (in Arabic)
โ€‹https://youtu.be/Yfmutvs3yxI?si=BO-qBCtxUKSWHF08

It's really great, my table is Gaomon M10K pro, BTW it's working without kernel injection, just in the user layer

This entry was edited (10 months ago)

Very interesting! Thanks for the link and for testing.

I have also a variant of this tablet (the 2018, not the pro model) https://www.davidrevoy.com/article870/review-gaomon-m10k-2018-graphic-tablet-on-linux-for-digital-painting

I'll test ๐Ÿ‘ Got Huion, Xp-Pens, and more at home to see how it works. :blobaww:

(edit: perfect, you detail all the steps, that's great!)

This entry was edited (10 months ago)

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.

@ElectroFetish I agree. I'm tempted to change my machine from Fedora KDE to Debian KDE to increase my peace of mind.
@tanavit Yes, https://www.davidrevoy.com/article976/lenovo-yoga-370-on-gnu-linux-technical-companion-article , but the workaround isn't working (the xsetwacom --set "$YogaEraser" Button 1 "key +ctrl button 1 key -ctrl" # color picker , egg to get a Ctrl click on the first button on my Yoga tablet).
@tanavit I tried it, in short it "works" because evtest reports the keypress after the tweak (in the middle of BTN_TOOL_RUBBER events) but in practice it doesn't work: probably the O.S. and Krita give priority to the Rubber/Eraser switch of device and ignore the key all together. It was weird, because I really thought this method would save me.

when is your book of illustrated bug reports coming out?

๐Ÿ˜€

@lufthans ๐Ÿคฃ ๐Ÿคฃ ๐Ÿคฃ

: mais comment tโ€™es arrivรฉ ร  la conclusion que cโ€™รฉtait le kernel?

Jโ€™aurais investiguรฉ tout tout tout avant le kernel!

@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.

: 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โ€ฏ?)

This entry was edited (10 months ago)

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!)

This entry was edited (10 months ago)
@ploum accroche toi bien a tes stylos, ca a l'air de souffler pas mal!

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.

#xkcd #xkcd1172

This entry was edited (10 months ago)

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

@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.

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?

This entry was edited (10 months ago)

@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."

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

@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.
I'm sorry you didn't have a great experience -- fwiw, I'm working on making it easy to report bugs via bugzilla.kernel.org and actually have that be effective.

@monsieuricon thank you, and no problem. I understand a mailing list system to report require disciplin, spec and formating for all these team to collaborate. I less understood why Protonmail couldn't provide this tool. I thought they were more FOSS friendly...

Thank you for the link, and the tracker! I'll have a look.

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.

@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. ๐Ÿ™ƒ๐Ÿ˜†

this pic goes hard feel free to screenshot
@monsieuricon Right ๐Ÿ‘ Thank you for the guidance. Very appreciated,, I'll do.
And also say hi to @mairin who has deep knowledge of Fedora, graphic tablets and who to talk to when problems arise ;)
This entry was edited (10 months ago)
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.
that little penguin there need to calm down...
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.
โ‡ง