Wacom tablet issue's on Wayland

I’ve a Wacom Intuos 5 Touch - PTH650 and had no troubles in X11, but in wayland there are several:

  1. Doesn’t work with auto hide panels from plasma or menus when software is full screen and they hide.
  2. Can’t resize windows with super and right click
  3. Can’t move windows with super and left click
  4. Can’t move files on dolphin with click and drag
  5. Can’t move browser tabs with click and drag either
  6. When configure manually pen buttons, won’t work correctly with apps like blender, inkscape, gimp, krita, etc…so I use defaults, but they change in each software
  7. When switching between pen, touchpad or mouse, the cursor changes to the last position of that device instead or starting where it was (hope i made myself clear with this issue )
  8. The tablet settings i asume the 5th button is the one of the ring, but there’s no config for the ring
  9. When moving mouse to the left monitor back and forth, the mouse stumbles with an apparently invisible wall so the space to go from one monitor to the other is pretty reduced (it works fine on X11)

So far those are the main problems, hope this can be solved soon byt the amazing kde team :slight_smile:

Operating System: Garuda Linux
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.11.6-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700 CPU @ 3.60GHz
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: H110M-S2PH

I’ll try tackling some of these:

What have you tried configuring them to? Mouse buttons, keyboard buttons, etc?

This is intentional behavior.

This is unfortunately intentional, there is no way to configure rings in our Wayland session yet.

This is intentional behavior, I forgot what it’s called - something like sticky edges?

1-5 are bugs, and should be reported to bugs.kde.org.

1 Like

Awesome! thanks for the help @redstrate :slight_smile: just some follow up:

Yes…in fact it is when i configure the mouse clicks when they work badly on each software…so left them on default, and for now it’s usable, but would like to be able to change the order…not thaaat important but useful i think.
And the tablet key config works with keyboard shortcuts, but the order is wrong…don’t know which one is the button 1 cause the hotkey i’ve put on 2 is the first button on my tablet :confused:

Not sure why…it’s awful! :frowning: but can there be an option to enable/disable that behaviour? please? :pray:

But maybe in the future? i mean, i can live without that…but would be nice to be able to use it again to change brush radius and other uses :slight_smile:

Ohh…maybe another switch? although…it’s not that important…i just see that need to move faster my mouse to avoid it i think :stuck_out_tongue:

Ok…doing that…thanks a lot my friend :slight_smile:

So, I’m relatively new to KDE, or at least this incarnation of it. And it’s driving me nuts. I’m used to MacOS, but well - that’s gone a bit “hrm” and is actively forcing me away from using a piece of software I need to use. It’s not like I’m some sort of newb, either, I’ve been using *nix since 1987, and various linux distros on and off since 1998, although mostly over the command line. So here I am. I am also someone who uses a wacom tablet on a daily basis, so I thought I might add some additional context. Hope you don’t mind. Using KDE Neon, fully updated.

Firstly, and something you haven’t mentioned, there doesn’t seem to be any way to deal with a wacom puck or mouse, only the pen. I have all 3, and use them differently - the mouse acts as a mouse, a relative device, the puck is usually absolute, and the pen is always absolute. The puck and mouse are treated as the pen. That’s just plain broken. They are separate devices, the wacom API allows you to identify them by serial number, they should be individually configurable. Indeed, the driver sees them as different, because the tablet tester sees the pen but not the mouse or puck.

Secondly, the separate pointing devices pick up from their last position thing. As you say…

Exactly. It’s horrible to use, and it’s made way worse by the fact the mouse is not treated as a relative device. If by error I leave the mouse or the puck on the tablet surface, it breaks every other pointing device.

From my perspective, I’d say that all relative devices attached to the computer - mouse, trackball, touchpad, etc should be able to be configured (and should be configured by default) as being one unified relative pointing device, with a single location which is the last location touched by any pointing device. Then individual devices capable of acting as absolute devices should be able to be configured as such. I have used systems with separate devices, including tablets allowing simultaneous puck and pen, for example. I’ve never seen anyone do anything other than turn that functionality off.

I digress.

There’s also the fact that using the mouse sorta sometimes kinda works, sometimes it will allow me to click things, sometimes it requires me to double click, sometimes that seems to put the whole thing into some utterly broken state where I need to move to another pointing device and click with that. I haven’t been able to 100% replicate how to get into this state, but it happens a lot. Indeed, it just happened so badly as to utterly break my browser and require a logout to fix it.

My tablet (intuos 3) has 8 buttons; they are picked up as indicated by the “test tablet” functionality, but the 2 touch zones aren’t. I guess that works (or fails to) the same as your rings.

Interesting, I know the functionality is a tad buggy and I’m going to look into it soon. Note that in 6.3, you don’t have to bind them to mouse buttons explicitly but can change the order of the pen buttons instead.

This sounds more like an issue of how your tablet shows up in the KCM, which is then possibly a libwacom issue.

Nope, sorry. There’s no immediate plans I know of to unify all of the cursor positions.

Definitely in the future, along with the rest of the inputs tablets have.

I just found the option, it’s under “Screen Edges” and called “corner barrier”.

The mouse being detected as a pen is weird, that isn’t our issue if that’s the case. In the future, you will be able to use a stylus as a relative mouse device which kinda fixes this issue.

I have no idea what a “wacom puck” is though (and searching it doesn’t reveal much), what is that?

[quote=“redstrate, post:6, topic:25508”]
The mouse being detected as a pen is weird, that isn’t our issue if that’s the case.[/quote]
Having looked at the source, it very much is a KDE issue. If you look at tabletsmodel.h, you’ll notice that there are 2 hardcoded input devices for a tablet - one for the tablet buttons, and one for a “pen”, but which ends up getting input events for all other input devices on the tablet. That’s pretty shonky; not all tablets have a set of buttons, and it is very common to have more than one input device.

If I’m understanding linuxwacom correctly, to do this right, we should find the tablet identifier, and query linuxwacom. This will give us details of its capabilities; in the case of my 6x8 intuos3 these are defined in wacom-intuos3-6x8.tablet Looking at this we see that we have 2 strips (these are the touch strips), 2 sets of buttons (left and right) with 4 buttons each and it handles a stylus. The types of stylus it recognises are given in the “Styli” entry, which is a list containing either direct stylus type identifiers (see the intuos 2 entry for the 9x12 tablet, for example) in hex form, or a set of names, all of which are further lookups in the table defined in wacom.stylus. For a hex code we look up by the key, and for a string we look up by group. So, again, for my 6x8 it can handle anything from groups intuos3 and intuos3-pucks, which comes down to a list of 10 types of stylus and puck.

I had links in the above, but new user, not allowed. You can find them, I’m sure.

There’s some convoluted math we can do on the device keys to get reasonable defaults for absolute / relative, this is defined in the Wacom docs.

So, rather than have a pair of devices, I would do this as a hash table of devices, keyed on a hash of the device’s serial number. Not sure how the strips and buttons report, but I’m guessing they have serials as well. When a new device comes into proximity, if it’s not already set up, we can generate some useful defaults based on its type, and then allow the user to customise on a per-input-device basis.

Yeah, I know a bit about these things. I’ve been in and out of the Wacom docs more times than I care to mention when I was decoding the original intuos ADB wire protocol.

So, Wacom tablets have a number of different possible input types. The classic ones being “pen” and “mouse”, but there’s a huge number of different ones available. Like I said, there’s 10 different types for my entry-level intuos 3. The “puck” is also known as a “digitizer” or “lens cursor”, the intuos 3 one has a type of 0x093

Then your contributions to making the tablet KCM work better for Wacom devices would be much appreciated, otherwise you’ll have to wait for me or another contributor to figure it out :slight_smile:

Whilst that is, indeed, true, it would require quite a few things.

  • It would require me to have significant free time to devote to this. I don’t have that.
  • It would require me to spend a lot of time messing about learning how both KDE and wayland works under their skirts, in order to fix one problem. Again, not time I have available.
  • It would probably require me to be polite and respectful to other developers. Based on 40 years of professional curmudgeonliness, that’s probably not going to happen. Indeed, having looked at some of the wayland code to try and work out where the event chain goes, I suspect my comments would get me excommunicated within the hour*.
  • It would require me to code in C++, which does not help with the item directly above. Could be worse, of course, it could be PHP or Python, but C++, and especially other people’s C++, makes me cross.
  • It would also require me to be invested enough into the platform to actually do all the above. I’m not.

Apple, in a zealous fit of making things “secure” and “private”, have in the process made a piece of software I need into something unusable. However, that software is, itself, open source, which means I can spend a relatively small amount of time making it work again, and get the job done that I need to do, rather than a difficult migration to an OS I simply don’t like using, and messing about with it at a low level.

I wish you well with trying to get this working, and will of course be more than happy to help if I can - I’m sure you can get to me via email if you try - but much more than commenting on design and maybe some testing is well outside what I’m able to offer at the moment. Sorry.

* For example, it appears that the issue of the system pointer being different from the one controlled by a tablet is a thing that is up at the wayland level. That’s plain stupid, and it’s stupid at a foundational level. Whatever you stack on top of it will be remain fundamentally stupid by association. And that’s me being excessively polite :slight_smile: Linus ain’t got nothing on me.

Finally did it: 497256 – Wacom's tablet issues on KDE Plasma Wayland (pen and touchpads)