Add Lenovo Precision Pen 2

[RayJW]

Something changed in GNOME 47 and the non-eraser button on my stylus has become basically useless as it now simply acts as a left-click instead of correctly mapping to secondary actions in apps like Xournal++ or Rnote. I saw this, and I think one of the defaults that changed may have affected that behaviour.

I know that this is only vaguely related to libwacom, so this is just background info. Now the real question. I saw that there is now support for non-wacom styli. How can I help to get my stylus supported, so I can properly adjust the button mappings. At the moment, sudo libwacom-show-stylus simply prints the serial number and Unknown stylus id 0x866b. New entry needed.

I searched the wiki and all the other repos, but there doesn't seem to be any info about this for the time being, and the error only reads Suggested line for .tablet file: Styli= which doesn't help.

• Device name: Lenovo Precision Pen 2 (2023)

• Device model identifier: ZG38C04471 ?

• libwacom version: 2.13.0-1

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

[whot]

if the button mapping doesn't work, please file a bug with gnome-control-center, thanks. this is not something libwacom can control.

All the styli are in libwacom.stylus though now that we have multiple vendors we should probably split them by vendor (i.e. wacom.stylus etc.). In your case adding lenovo.stylus and filling it with the same bits as the existing styli should work, we do read all .stylus files.

[RayJW]

if the button mapping doesn't work, please file a bug with gnome-control-center, thanks. this is not something libwacom can control.

Hmm, okay, I'm sorry then. I stumbled upon this issue when looking at gnome-control-center which is why I ended up back here since I thought this was the same underlying problem. Thank you for your patience ^^

All the styli are in libwacom.stylus though now that we have multiple vendors we should probably split them by vendor (i.e. wacom.stylus etc.). In your case adding lenovo.stylus and filling it with the same bits as the existing styli should work, we do read all .stylus files.

Should I keep this issue open and close it once this is changed? I'll gladly help with getting this done! Would you like me to try to open a PR for that, or is it too “early” in the restructuring?

[whot]

so basically: libwacom says "stylus has N buttons" and then GNOME (or $other) is responsible for actually mapping those buttons to something. It's libwacom's bug when the information is wrong but here it sounds like it's the actual mapping that doesn't work?

What does libwacom-list-local-devices say for example? Most tablets should default to the generic pen anyway and arguably even adding your stylus isn't truly necessary for it to work.

Having said that, I've merged #780 now, if you can send a PR for lenovo.stylus that'd be great!

[RayJW]

What does libwacom-list-local-devices say for example? Most tablets should default to the generic pen anyway and arguably even adding your stylus isn't truly necessary for it to work.

devices:
- name: 'Wacom HID 52C2'
  bus: 'i2c'
  vid: '0x056a'
  pid: '0x52c2'
  nodes: 
  - /dev/input/event11: 'Wacom HID 52C2 Pen'
  styli:
   - id: 0x1
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x11
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x19
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x21
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x31
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x39
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x49
     name: 'Bamboo Ink'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x71
     name: 'Bamboo Ink'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x221
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x231
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x271
     name: 'Bamboo Ink'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x421
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x431
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x621
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x631
     name: 'Dell Active Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x8051
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'tilt', 'pressure']
     buttons: 0
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x805b
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'tilt', 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x806b
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'tilt', 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x807b
     name: 'Bamboo Ink Plus'
     type: 'mobile'
     axes: ['x', 'y' , 'tilt', 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x826b
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'tilt', 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'
   - id: 0x846b
     name: 'AES Pen'
     type: 'mobile'
     axes: ['x', 'y' , 'tilt', 'pressure']
     buttons: 1
     is_eraser: 'true'
     eraser_type: 'button'

This is the output for sudo libwacom-list-local-devices but only because I have the tablet file that I submitted a PR for in /etc/libwacom until a new version is released.

And for sudo libwacom-show-stylus the output looks like this:

Using "Wacom HID 52C2 Pen": /dev/input/event11
Using stylus file(s): /usr/share/libwacom/libwacom.stylus
Tool id 0x866b serial 0x80208cd7 in-proximity: False 
^CTerminating
Unknown stylus id 0x866b. New entry needed
Suggested line for .tablet file:
Styli=

[RayJW]

I got the pen working. Before I open a PR I have a few questions since I couldn't find any documentation about the stylus properties. I added the following to lenovo.stylus and copied the file to /etc/libwacom/libwacom.stylus to test the changes. The pen is now correctly recognized and shows up as the Lenovo Precision Pen 2 (2023) in the GNOME settings.

[0x866b]
# Lenovo ; VID_NONE     | 0x866b | BAT_CHRG
Name=Lenovo Precision Pen 2 (2023)
Group=isdv4-aes
Buttons=1
EraserType=Button
Axes=Tilt;Pressure
Type=Mobile

1. Is it correct that I added the comment like this under the ID, or should I use a more generic ID instead of creating a new entry? Some configurations in wacom.stylus have multiple pens listed under the same ID (see [0x19] with some Lenovo pen listed that has the ID 0x60A8).
2. What is the VID? Some entries had VID_LENOVO, but I have no idea if it falls into that category.
3. I just added BAT_CHRG because I assumed that it means the pen has an embedded rechargeable battery instead of BAT_SWAP with swappable triple A's like some others do. Also, there are more properties like BAT_HID are any of these required?
4. Did I understand correctly that there is no group distinction between AES 1.0 and AES 2.0 for the time being? Because this pen supports both compared to its predecessor.
5. Since one of the buttons is just the eraser and can't be remapped, I put Buttons=1 instead of 2, I think that should be right according to comments I found in other PRs?
6. I couldn't find any definitions for the different types, all the "separated" laptop styli I could find had Mobile, so I just put that as well.

If everything is correct according to you, I will open a PR, and then I can also close the gnome-control-center issue. Also, thank you specifically @whot for all the patience! :) I know I created quite the workload with multiple issues and PRs the last few days. I think once this is done, all my devices work perfectly, and I'll go back to where I came from ;D

[whot]

ftr, after some digging: a864679083c035eb08a75cf084a6564d589c0b1c explains the various comments here. In hindsight there's an argument for splitting those styli out into vendor-specific sets, maybe that becomes another item on the evergrowing todo list... Now I'm wondering whether it's necessary to even add this as lenovo.stylus, you might as well add it to the existing list.

Let's cc @jigpu for extra eyes since they added that original set of aes pens.

Is it correct that I added the comment like this under the ID, or should I use a more generic ID instead of creating a new entry? Some configurations in wacom.stylus have multiple pens listed under the same ID (see [0x19] with some Lenovo pen listed that has the ID 0x60A8).

I think it's fine.

What is the VID? Some entries had VID_LENOVO, but I have no idea if it falls into that category.

shrug - I'd say stick with lenovo since it's sold by lenovo.

I just added BAT_CHRG because I assumed that it means the pen has an embedded rechargeable battery instead of BAT_SWAP with swappable triple A's like some others do. Also, there are more properties like BAT_HID are any of these required?

tbh I'm not sure how much those comments were write-only comments :) BAT_HID you should be able to figure out running hid-recorder - if you get regular battery updates from the pen then it's BAT_HID. Also not that important IMO.

Did I understand correctly that there is no group distinction between AES 1.0 and AES 2.0 for the time being? Because this pen supports both compared to its predecessor.

correct, we only have no distinction here. Hasn't been worth the effort since the vast majority of (non-debug-utility) libwacom users go from "I got this pen, what is it?" rather than "i have this tablet, what's supported".

Since one of the buttons is just the eraser and can't be remapped, I put Buttons=1 instead of 2, I think that should be right according to comments I found in other PRs?

that is correct, yes.

I couldn't find any definitions for the different types, all the "separated" laptop styli I could find had Mobile, so I just put that as well.

The type maps to enum WacomStylusType which indeed has no comments but its elements map to the various styli type available from Wacom. Mobile is correct for yours though.

I know I created quite the workload with multiple issues and PRs the last few days.

no, thank you for fixing all this. I like the bug reports where I only have point to things and pretend to be wise :)

[RayJW]

Perfect, thank you for all the feedback!

tbh I'm not sure how much those comments were write-only comments :) BAT_HID you should be able to figure out running hid-recorder - if you get regular battery updates from the pen then it's BAT_HID. Also not that important IMO.

For the battery, hid-recorder reports Battery Strength: 255, but I haven't seen it change yet. I'll try to keep monitoring it.

I'll wait until it's clear where to best put the info, and then I can open a PR with the current values :)

[RayJW]

After 3 days of occasional usage, the pen still shows Battery Strength: 255. I guess it makes sense to leave it at BAT_CHRG, since it seems fair to assume that this value is not reliable. GNOME shows the tablet as 100% at all times anyway.

If I may ask, though, sometimes I get seemingly random notifications on my desktop that the tablet power is low (I think only with the values 12% and 6% charge). I always assumed it's just a bug since there is no tablet. Could it be that the pen does not have a real battery value but sends a notification at certain charges, is that something that has been observed before? That is the only way I could possibly explain these notifications. Perhaps libwacom always reads the pen at full charge except when the pen "notifies" the display about a low charge.

[chrostino]

Is it possible to use this to remap the eraser button to something else?

[RayJW]

Is it possible to use this to remap the eraser button to something else?

I don't think remapping the eraser button is possible at all, at least on most pens. I believe this is a hardware firmware thing.

[chrostino]

damn, thanks anyway

[whot]

Is it possible to use this to remap the eraser button to something else?

A decade or more ago, MS stipulated that the eraser button needs to emulate (in firmware) the tool going out of proximity and coming back into proximity with the eraser end. That means detecting an eraser button in userspace requires heuristics and they're difficult to implement (with the way libinput is currently designed) and prone to failure.

Note that you can insert a bpf to handle this at the HID level which is a bit easier and more reliable. We're doing this in udev-hid-bpf for the XP Pen Artist24 because that one pretends to have an eraser button and and eraser tip. Long term we're planning to have a set of bpf there in userhacks/ that do that for various tablets but we haven't gotten round to that bit yet. Feel free to get started though :)

[whot]

Perhaps libwacom always reads the pen at full charge except when the pen "notifies" the display about a low charge.

libwacom is just a C API around the .tablet file, it has no knowledge of the device even existing. What's likely happening is that the HID report somewhere includes a battery report that is sent at some point, it's picked up and exported by the kernel as such and the rest of the stack picks it up accordingly. I've paged out those parts though so I don't recall which part you'll need to start with first, sorry.

If you run hid-recorder against the various hid reports from the device you'll probably see that event.