How to add full support for Xencelabs Display Pro 16

[hpetrus]

I'm trying to add support for my Xencelabs Pro 16 display tablet, so that I can have full control over both styli and their buttons, as well as control over the tablet from the KCM, instead of the proprietary config GUI. I've read as much of the wiki as I could to try and figure out how stylus buttons are defined and identified, but I can't really find anything specific the stylus buttons - only tablet buttons.

An example problem I'm facing is there are three buttons on the thicker stylus, but only two of them are recognized as middle mouse click and right mouse click. The middle button turns the stylus tip to an eraser and that's not what I'd like. Currently, the tablet detection software can't recognize the tablet, but the tablet 'works' out of the box with default settings, but no user configurability.

Could I get some guidance here, please? Forgive me if the answer is obvious, but I can't see it, so far. I must be missing something. I there's some instruction on how to make a robust descriptor for both tablet and stylus, I'll happily read it and follow along. I just can't find anything on stylus buttons in the current docs on adding support for new tablets.

[whot]

The buttons are supposed to send BTN_STYLUS, BTN_STYLUS2 and where a fourth button is present: BTN_STYLUS3. They don't need to be configured in libwacom because any tablet sending any other button is a bug that should be fixed in the kernel.

That one button mapping to the eraser is a MS tablet pen requirement which is why virtually all pens now do this. It's hard to detect in userspace because you need heuristics, the best approach for hacking this to a normal button is using udev-hid-bpf, if you dig around there you should find the .bpf.c for the XP Pen 24 (iirc) that disables the eraser button.

[hpetrus]

Thanks for getting back to me on this, whot.

I found the 0010-XPPen__Artist24.bpf.c you spoke of that seems to remedy the eraser switch bug. There's some good docs that go with it on their code repository, so I'll dive into that and experiment with it.

But, isn't there and xorg/udev rule solution to this? The proprietary drivers have no issue changing the behaviour of any stylus button, which is why I ask.

[whot]

in xorg you can use the ButtonMapping option to change "physical" buttons to logical buttons. in Wayland that's typically implemented in the compositor, e.g. GNOME can map those buttons to actions like display toggle too.

the proprietary drivers have no issue changing the behaviour of any stylus button, which is why I ask.

the proprietary drivers sit roughly at the same level as a udev-hid-bpf BPF where it's simply easier to detect. Plus they don't have to care about breaking other devices as much as we do in libinput :)

[hpetrus]

Thanks for the clarification, @whot !

For an artist, Wayland is both exciting and extremely inconvenient, at this time. We live on display tablets when making the movies and shows everyone enjoys - and a lot of us use Linux for many reasons - both obvious and not so obvious. Finding workarounds is hard because the docs and wikis aren't very intuitive to navigate/explore or complete, it seems. I look forward to when we can all work on tablets as easily as can be, on any Linux DE. Until then, I'll have to bug people like you to gain access to solutions and knowledge I otherwise wouldn't have.

I'll likely be asking more questions in the future.

[whot]

We live on display tablets when making the movies and shows everyone enjoys - and a lot of us use Linux for many reasons - both obvious and not so obvious. Finding workarounds is hard because the docs and wikis aren't very intuitive to navigate/explore or complete, it seems. I look forward to when we can all work on tablets as easily as can be, on any Linux DE. Until then, I'll have to bug people like you to gain access to solutions and knowledge I otherwise wouldn't have.

FTR: I'm not a tablet user, I check that it works and doesn't crash but that's about it. Which means most of the time I'm at loss for what is really needed and the various things artists have to do to get tablets working the way they want. @Deevad was a huge help here simply because of a few blog posts that illustrated the configuration needs which then allowed us to implement those features.

So I personally would be more than happy with a wiki/page/repository that describes real use-cases and struggles so we can use them as reference when we implement new features or decide how features need to look like. This doesn't mean everything will get implemented (or in reasonable time :) but it's better than us guessing.

[Deevad]

The middle button turns the stylus tip to an eraser and that's not what I'd like. (from @hpetrus first message)

Yes, as far as I know, it's now a default of the kernel to force on all unknown graphic tablet this "eraser mode" by design, it's know since november 2023, and the more hardware I test, the more I see it's a general issue, and not one related to a single device. Thank you for confirming Xencelabs are also impacted...

Right now, the only workaround possible is tedious. Both for me and the dev, and very costly in work hours per model, imo. It require to report the tablet, one model at a time on udev-hid-bpf, then the final user will have to install udev-hid-bpf to benefit of the new rules created once the developers will create the rules.

Eg. of thread:

• XpPen Deco 01 V3
• XpPen Artist Pro 19 (Gen2)
• Huion Kamvas 19 Pro

Then, once patched and the device works correctly at a hardware level, the user needs to create a .tablet file in https://github.com/linuxwacom/libwacom/tree/master/data in order to get the tablet's feature listed in Wayland GNOME tablet's settings or Wayland KDE tablet settings.

With GNOME also requiring also a pretty complex SVG files in https://github.com/linuxwacom/libwacom/tree/master/data/layouts

As far as I know, the end user can tweak this data files directly on their own install without needing to push them to libwacom repository first and wait for a release or recompile it manually.

I try to centralize on my blog as many information I can, on my hardware tag and on my current recommendation on what Linux distro to install for graphic creation.

I hope it helps, and feel free @whot to correct me if I said wong or outdated things. I'm really willing to know this topic well and help other graphic designers, comic artists, 3D artists and digital painters around.

[whot]

Yes, as far as I know, it's now a default of the kernel to force on all unknown graphic tablet this "eraser mode" by design, it's know since november 202

The "eraser button" behaviour has been around for over a decade (my post from 2014) and it's actually part of the MS specs, see the 'Special Notes for Eraser Button Implementations' section. And because MS did it first everyone is now copying it. Counting by model numbers, the eraser-at-the-tip tablets are now in a tiny minority. Your XP Pen 16 was a special case because it had the tip and the eraser button which is a definitive bug.

But for the actual eraser button all we can do is weep and fix the devices one-by-one (though if we remove the eraser button we also need libinput#999 to optionally get it back) which I haven't even started yet.

As far as I know, the end user can tweak this data files directly on their own install without needing to push them to libwacom repository first and wait for a release or recompile it manually.

That is correct, libwacom will read the files on-load and check /etc/libwacom and (newest releases) $XDG_CONFIG_HOME/libwacom for .tablet files and the {/etc|$XDG_CONFIG_HOME}/libwacom/layout subdirectory for SVG files.

With at least new versions of GNOME (47, I think) you don't have to have the libwacom files anymore for the device to show up but it now defaults to the (numerically superior) built-in tablets for unknown tablets. So for anything XP Pen you still need the .tablet files. Not sure how KDE handles this but probably the same.

I try to centralize on my blog as many information I can,

I'm thinking: it'd be nice to have the "what is needed to get a tablet to work" in either libinput or udev-hid-bpf's official documentation so we can point to it. If you want to start with that, I'll happily get out of your way and cheer you on from the sidelines :)