@Conan_Kudo@davidrevoy 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.
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")
@davidrevoy@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.
@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.
@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 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. 🙃😆
@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?
It has the same "stench" and "notoriety" to the point that I'd call the same 3-letter-agencies "criminally incompetent" if they didn't already place multiple people inside if not set it up as replacement for #MINERVA... https://www.youtube.com/watch?v=IeXaYR4ed9c
@protonmail@davidrevoy How can the end-user know that they're getting what you claimed and has been verified?
Spoiler: They can't!
So again that's some marketing speak.
I'd rather have you be honest like https://cock.li instead of insulting my intellect.
Needless to say.that fucking around with the contents of any eMail is a big No-Go as it bricks my workflows as well AND you - as any other eMail provider - have no business doing so!!!
@protonmail@davidrevoy if you actually cared about #privacy and #anonymity you'd not only fix your #OnionService AND allow anonymous payment (i.e. #Monero :monero:) but also help users to setup proper #E2EE like PGP/MIME and instead of fucking around with their eMail contents in transit, offer something that would actually make sense like the option to block unencrypted eMail going out and/or in.
But that would require effort beyond #FUD and False Promises in #Marketing: https://www.youtube.com/watch?v=WVDQEoe6ZWY
@kkarhan@davidrevoy Hi Kevin! As explained previously, this case shows that we do provide privacy by default - even in cases when we receive a legal request we cannot contest, we are not able to share the encrypted content on our service with the authorities. All we have is the extremely limited metadata that we need for the services to function properly. If anonymity is part of your threat model, here are some tips: https://proton.me/blog/how-to-send-an-anonymous-email and https://proton.me/blog/use-protonmail-anonymously.
@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.
To me this is entirely undesireable behaviour for any eMail-Provider but then again so is the entire proposition of not using real #E2EE and instead letting some 3rd party appliance/service handle it - regardless if #SEPsesam or @Tutanota or #ProtonMail or whatever.
@kkarhan@fell@davidrevoy@monsieuricon We did not intend to say that think we say it’s their problem, it’s simply an unfortunate ambiguity in the WKD spec that doesn’t specify how the domain wants the keys to be used.
@protonmail@davidrevoy@kkarhan Having a WKD doesn't imply we want to receive PGP encrypted mail -- its primary purpose is to make it easy to retrieve keys for signature verification on git commits and packaged releases. If you can turn this off for kernel.org addresses, then please do so.
@davidrevoy 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.
@davidrevoy Since you're a Fedora user, the most proper way to do this is to report a bug to the Fedora bug tracker. The Fedora kernel maintainers will then work with the upstream kernel to get this solved. This way you don't need to worry about Protonmail problems and you will follow the correct procedure.
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.
@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)
@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!)
If you're already aware of the following, apologies, very likely you are. It might help someone else in a similar situation anyway.
Fedora by default keeps a couple of kernels in your system other than the last one installed, and you can reboot the system with the previous one to keep working normally as you did before the update, while the issue is sorted out -- and as someone pointed out, it might be fixed already in a newer kernel not yet arrived to your system.
Just reboot and choose the previous kernel, in short.
I feel your pain, one of these kernel updates once killed the touchpad on my ThinkPad, and even though a report was filed, it took months to fix. I kept booting with an older kernel until very quickly security wise this turned into a bad idea, and then was forced to always carry a mouse with the newer kernels.
@davidrevoy@ElectroFetish Kernel breaking changes are always a pain. You should be able to lock out future kernel updates. I just edited my /etc/dnf/dnf.conf adding a line like:
exclude=kernel*
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.
@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 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...
@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.
@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 :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)
@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
@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.
@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 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
@davidrevoy 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
@davidrevoy@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.
Add comment