https://bugs.kde.org/show_bug.cgi?id=521611
--- Comment #11 from HPetrus <[email protected]> --- (In reply to trevorbeckerson from comment #10) > > Since libinput now supports this, is this a kwin thing, or something else? > > What needs to be recoded or patched in order to get this fixed? > > It's a kwin thing. They need to add the ability for the tablet configuration > to recognize the grouping of signals that your stylus sends when you click > that button (proximity-out + invert + proximity-in, possibly more), group it > together into a single command ('ms_eraser' or whatever), and replace it > with whatever you specify. I honestly have no much work this requires, or > how much of it is libinput and how much is kwin. I'm going to look at the > code and see if I can figure something out, but I have minimal programming > knowledge. > > > This makes > > a lot of styluses unusable or - more annoyingly - semi-usable, which is a > > massive distraction to the creative workflow. This is NOT a feature > > request, or a nice-to-have. This is ESSENTIAL. So, anything I can do on my > > end to help it along, I'm in. > > As a temporary alternative, you might want to check out OpenTabletDriver, > https://opentabletdriver.net/ > They don't list your tablet on the site, but their Discord has > configurations for lots of devices that the devs and the users have added > support for. You might have good results, it's worked nicely for me. Thanks, @trevorbeckerson. opentabletdriver is good to keep in mind as a stop-gap. I'm going to ask: how can we get this bug report in front of the eyes of kwin maintainers? I think Mr. Goins needs as much help as he can get on libinput tablet stuff. He's not only got tons on his plate to get his head around, but he's also trying to understand the needs of art professionals at the same time. Nonetheless, everyone involved needs to understand how much seamless integration for drawing devices matters to an artist using Linux and Plasma 6.x. It's come a huge way in a short while, but still needs a lot of attention and for sure more devs - volunteers or otherwise - to get it where it needs to be. For us at the studio, it's what's been keeping us from going 100% over to Wayland. The rest of the issues are solvable with kwin scripts and user-level patch jobs. libinput/kwin/kcm on the other hand is a very user-unfriendly ball of thread when it comes to what the user can configure and script. This, compared to xorg.conf, combined with various xorg commands, there is nothing that is open to the user in order to get closer to bare metal on libinput control. After having checked libinput docs, let me tell you it's not very useful. For anyone hoping to contribute, this is a giant wall and feels kinda gate-keepy, if I'm being honest. Knowing that, I can see how Joshua Goins can be burnt out. I feel worn just thinking about what he has to deal with on his own. Still, one way or another, drawing tablets need to mature quickly. At this point, all I can do is report bugs and offer data and testing. -- You are receiving this mail because: You are watching all bug changes.
