Incorrect amount of stylus buttons reported, eraser missing

[in-a-dil-emma]

• Device name: ISDv4 51B2

• Device model identifier: ?

• libwacom version: 2.16.1

• [x] I understand that libwacom does not affect whether the device works (see Troubleshooting)

Bug description

On Windows 11, with Lenovo drivers installed, the Lenovo Stylus (Lenovo 4X80H34887 Active Capacitive Pen Pro for TP S1/S3/S5 YOGA) is correctly recognized as having two stylus buttons and an eraser on the back.

On Linux the second stylus-button is "hard coded" to MMB (and only shows one remap-able button in KDEs graphics tablet KCM) and the eraser side gets interpreted as a touch input.

The integrated stylus also has two buttons, the second one is hard coded to be MMB aswell.

This behavior is consistent with Windows 11 before Lenovo drivers were installed.

Thinkpad x390 (20NQS1X200) running NixOS (25.11pre893393.91c9a64ce2a8) with kernel 6.17.7-cachyos. KDE Plasma 6.5.2 Wayland

I suspect that the tablet definition needs to be updated here

[in-a-dil-emma]

Correction: On Windows, the eraser feature is also recognized as touch input. I believe this is a hardware limitation then.

[whot]

Can you do a libinput record of the pen, pressing the buttons in sequence. That'll tell us what comes out of the kernel and then we can adjust everything else as needed. THanks.

[in-a-dil-emma]

Sorry for the late response. I also had to gzip the recording because it failed to upload (for some reason).

recording.yml.gz

Command used: run0 comma libinput record -o recording.yml /dev/input/event5

[whot]

Thanks, so what I can see here is at 3.32s BTN_STYLUS and then again at 6.35s. I don't see BTN_STYLUS2 so the pen doesn't send those events (assuming you pressed it). At 5.50s I see BTN_TOOL_RUBBBER (i.e. the eraser) which is consistent with eraser button behavior.

So basically: if the pen has 3 buttons, one of those is an eraser and the other two send the same event. This may be fixable in udev-hid-bpf if there is some other hint in the hid data to help us disentangle this. Worth filing a report there with hid-recorder output attached.

From the libwacom's perspective: the hw id is is 0x21 (decimal 33) and we have an entry for that along with many others - that entry seems shared with some HP and Huawei pens. We could update it and hope the other pens are the same - look for the [0x56:0x21] entry in wacom.stylus. Happy to take a patch for that but I'd prefer it if the issue was fixed first in the kernel (or udev-hid-bpf) so we actually get the right data.

[in-a-dil-emma]

Thanks, so what I can see here is at 3.32s BTN_STYLUS and then again at 6.35s. I don't see BTN_STYLUS2 so the pen doesn't send those events (assuming you pressed it). At 5.50s I see BTN_TOOL_RUBBBER (i.e. the eraser) which is consistent with eraser button behavior.

BTN_STYLUS is the one farther from the tip, BTN_TOOL_RUBBER is the one closer to the tip. I pressed both :)

The "eraser function" (which is flipping the stylus and using the back side) did not show up in the log because it was recognised as a touch event. Do you want me to record touchscreen events aswell? (I'd have to figure out the command to record more than one input source..)

[whot]

oh, it's a BTN_TOUCH on another device, is it?

libinput record --all can record all devices (or you specify the events nodes on the commandline).

[in-a-dil-emma]

oh, it's a BTN_TOUCH on another device, is it?

I think so?

run0 comma libinput record -o recording.yml /dev/input/event{2,6}

recording.yml.gz

I hovered the stylus, pressed the tip on the screen, went back to hovering and then pressed the side buttons. The first touch input is the stylus eraser, the other one is my finger.

(Note: There may be a stylus button press before I started hovering the stylus, that was me waking it up.)

For good measure I also recorded the inputs with the small stylus that was included with my Thinkpad.

recording_builtin.yml.gz

Note that this one does not have an eraser functionality, so the only touch input is my finger.

[whot]

Ok, I think we're talking past each other a bit. From what I can tell here:

• event2: is a normal touch device, BTN_TOUCH signals "finger down" which is all expected
• event6: is a normal pen device, BTN_TOUCH signals pressure > kernel-hardcoded threshold (30, iirc). BTN_TOOL_PEN and BTN_TOOL_RUBBER signal the tool in proximity at a time, with the eraser button expected to switch between the two. I can see BTN_STYLUS in there so that looks like everything is working.

What I'm missing here is the data for The "eraser function" (which is flipping the stylus and using the back side) did not show up in the log because it was recognised as a touch event.. Did you include this? Because this bit is what we're currently interested in, the pen itself seems to work correctly (within the confines of what it is).

[in-a-dil-emma]

What I'm missing here is the data for The "eraser function" (which is flipping the stylus and using the back side) did not show up in the log because it was recognised as a touch event.. Did you include this? Because this bit is what we're currently interested in, the pen itself seems to work correctly (within the confines of what it is).

That's what I've been talking about before, I think we just have to dismiss the eraser function because it doesn't get distinguished from "just another finger touch" under Windows either (comes back to the hardware limitation I was theorizing about before)

The former out of the two recordings (I sent yesterday) did include me attempting to use that functionality.

At this point I'd be contempt with having two stylus buttons being configurable in KDE's Graphics Tablet KCM :) (In other words: Both buttons being remap-able)

---

Looking into this a bit more I found this bug report and this PR for libinput

Hm. So if I understood the thread on KDE's bugtracker right (and if I dare make an assumption) this is just another case where the OEM software works around hardware quirks?

This is very confusing..

Thank you for your time though.

[whot]

Actually, this libinput pr is the one that matters and as of 1.29 you can remap eraser buttons, you'll just need to have the respective hooks in the desktop environment (GNOME doesn't have them yet, I don't know about KDE).

this is just another case where the OEM software works around hardware quirks?

The hardware quirk is mandated by microsoft so there's only so much they can do if they want the coveted "windows compatible" sticker :)

Anyway, long story short: we can remap eraser buttons now, it just requires the hooks to actually set that configuration.

Agree on the button-on-other-tip, we'll have to leave that for another day. Those buttons are actually relatively common (usually BLE-conneted) but they're usually referred to as just another button and I think a lot of them default to double-click? Anyway - nothing we can fix here, we don't have the infastructure in place here and worse - if we start handling those buttons we're likely to break existing mostly-working setups.

[in-a-dil-emma]

The hardware quirk is mandated by microsoft so there's only so much they can do if they want the coveted "windows compatible" sticker :)

Oh I see :)

This "bug" report on the KDE bugtracker may be worth keeping an eye out.

I suggest closing this issue as "wontfix"

[whot]

for the archives, mutter merge request for eraser button configuration