Input Wacom libary for Wayland compositors?

[shmerl]

Currently xf86-wacom-input is designed for X.org. In order for Wayland compositors to implement similar functionality, they'd need to either each provide a solution, or there could be some common library that handles it for Wayland use cases, that all compositors could rely on.

Is there any plan to implement one based on xf86-input-wacom?

[whot]

libinput is that solution. You can already use the xf86-input-libinput driver for tablets if you want though this xorg driver isn't as powerful as the wacom driver. it will work with tablets though, you may just be missing some option or another. We don't push for the xf86-input-libinput driver as wacom replacement because there are some application out there that rely on some peculiarities of the wacom driver.

For the pure wayland case, libinput is the replacement though.

[shmerl]

Missing options means it isn't a good replacement then, right?

We don't push for the xf86-input-libinput driver as wacom replacement because there are some application out there that rely on some peculiarities of the wacom driver.

So it means that libinput needs additional development to address that, in order for Wayland use case to be functionally complete? Or how exactly do you see approaching this?

I.e. how are those applications that rely on such peculiarities are supposed to work in Wayland sessions (assuming they'd rather not use XWayland)? Or you mean they should be treated as legacy and use XWayland, and newer applications should avoid those peculiarities?

If you recommend opening a bug for libinput about it, I can do it.

[whot]

Missing options means it isn't a good replacement then, right?

it's not as black and white, very much depends on your use-case.

Those applications that will start using Wayland are expected to update to remove the dependency on those peculiarities. For example, as an application under X you have to just know which axis is which axis. Axis 4 is either tilt-x, z-rotation or strip-x depending on the device. libinput provides these axes as named axes.

The strip is exported as basically a bitshift value (i.e. the axis value is (1 << x) instead of just x). This should've never happened but for backwards compatibility we never fixed it. libinput does fix it in that the strip is now exported as normal numeric value within a decent range.

These are the sort of peculiarities that I'm talking about and there are more. libinput does not aim to be a full 1:1 replacement, it aims to provide functionally equivalent tablet support. Much in the same way as a car isn't a 1:1 replacement for a horse carriage, though both are modes of transport.

You're welcome to open bugs for libinput for missing features but it won't just be a straightforward implementation of every xf86-input-wacom option.

[shmerl]

Got it. So if libinput should cover needed use cases functionally, I think it's good enough. Thanks!

[whot]

yep. of course where there's a bug etc. we'll fix it. and note that libinput hides more from the user than the wacom driver. we rely on e.g. device-specific quirks so that many configuration options aren't necessary to begin with. which means that some things aren't visible there but libinput handles them anyway.

oh, and libinput uses libwacom internally to know enough about the various tablet tools.

https://wayland.freedesktop.org/libinput/doc/latest/tablet-support.html is the starting point for documentation regarding libinput's tablet support.