Re: Requesting your attention and expertise regarding a Tablet/Kernel issue

[David Revoy]

Hi Illia, Jiri, Bagas, 

Thanks to Jiri for forwarding my request for help to this mailing list.

I apologise in advance to Bagas and you all for not being able to properly configure my email client to follow the correct etiquette (Protonmail, unsuitable for kernel development, but we've made some progress with them on Mastodon on the encryption issue [1]).

Thanks to Illia for the detailed explanation. Thanks also for fixing it, and for explaining how the fix broke my workflow, and for your kind words about the situation. I appreciate it.

However, after reading your reply, I still have my doubts about the preference to put an eraser on the top button of the pen by default. But after a few days and re-reading your first sentence "The XP-Pen hardware reports the Eraser usage for the upper stylus button.", I *think* I understood it: this is an internal signal that is sent by the device itself, and is therefore a specification that has to be followed, right? In this case, it makes sense for a generic driver to follow such a signal if it is sent by the hardware.

Having said that, behaving like this still makes no sense in one case: I'm thinking of my other display tablet, the XPPEN 16 Artist Pro (Gen2). In this case, the stylus has the top button as an eraser, and an eraser tip as well, as you can see in this photo [2]. Was it also a decision by XPPEN to include this signal in the hardware, knowing that they already had an eraser tip? In this case, please let me know, as it sounds like a hardware problem at the design stage and I have probably a way of passing on the information to their technical team.

> You can still remap the eraser button to a right click using xsetwacom:
> xsetwacom set "UGTABLET 24 inch PenDisplay eraser" "Button" "1" "3"

Unfortunately, it doesn't work. 

Firstly, such tablets are often connected to a computer that already has a display. So each device (pen/eraser) needs to be mapped to the correct display and set to the correct 'Area' for calibration. A better syntax in my case to test your workaround is written like this:

tableteraser="UGTABLET 24 inch PenDisplay eraser"
xsetwacom set "$tableteraser" MapToOutput "DisplayPort-2"
xsetwacom set "$tableteraser" Area 100 120 32794 32797
xsetwacom set "$tableteraser" "Button" "1" "3"

Secondly, forwarding the eraser button 1 to button 3 (a right click) in xsetwacom doesn't work. 

Pressing the button switches the device to an eraser and no right click happens. You'll need to hold down the button and click with the tip of the pen to create a right-click event. 

In a digital painting session in Krita, the software will switch your device to an eraser tool preset while you hold down the button, and the feedback on the canvas will be the eraser cursor. You'll then have to click "with the eraser" to get the right-click that triggers the pop-up palette [3].

I'd also like to mention that if you haven't correctly mapped and calibrated your eraser device with xsetwacom, as I did in the code snippet above, the cursor will by default jump to a different location when you hold down the eraser button. It can be on a different display.

Finally, in the case of the XPPEN 16 Artist Pro (Gen2) with a real eraser device (Photo, [2]), the setting 'xsetwacom set "$tableteraser" "Button" "1" "3"' will affect both erasers. Flipping the stylus on the eraser side and entering in 'hover' mode will return a correct eraser, but as soon as you start erasing with the tip, a right click will also be entered.

> You can also do this with "xinput set-button-map", which works for libinput as well.

$ xinput list
⎡ Virtual core pointer    
⎜   ↳ UGTABLET 24 inch PenDisplay Mouse         id=8    [slave  pointer  (2)]
⎜   ↳ UGTABLET 24 inch PenDisplay stylus        id=10   [slave  pointer  (2)]
⎜   ↳ UGTABLET 24 inch PenDisplay eraser        id=17   [slave  pointer  (2)]
[...]
$ xinput get-button-map 17
1 2 3 4 5 6 7 8
$ xinput set-button-map 17 3 3 3 3 3 3 3 3
$ xinput get-button-map 17
3 3 3 3 3 3 3 3

Even after that, it doesn't work. My original article [4] mentions in the last paragraph that I have tested almost all methods, and this was one of them. Even a udev rule doesn't fix it. For reference, xinput produces the same behaviour as xsetwacom: you have to hold the button (it triggers an eraser device switch) then click with the tip to get a right-click...

> We have tested this with several XP-Pen devices, including Artist 24.

Sorry if my tests show something different. Maybe there is something wrong with my GNU/Linux operating system (Fedora 38 KDE spin). Let me know if you have any idea why I get these results and guide me with what distro I should switch to get a similar obsevation than you do (and also to report the issue to the Fedora team).

---

All in all (and in the case that my observations and tests are correct), I still stand by the points that I made in my blog post:

- I don't have any way to customise the hardcoded eraser buttons in userspace and **it is a problem**: for devices without a touchscreen or mouse, not having access to a right-click by default on the device is a handicap. Many actions on the D.E. and applications use the right click. The preference to replace it with an 'eraser switch' action by default is IMHO highly debatable here.
- In the case of a pen that already has an eraser tip on the other side of the device [2], it makes no sense to exchange the right-click top button for another way to erase. Also in userspace, there seems to be no way to distinguish between the two buttons (the eraser tip and the eraser button). All actions from xsetwacom, xinput/libinput target the two eraser devices, and they target them unsuccessfully too.

[1]: https://mastodon.social/@protonmail/111346195283677411
[2]: https://www.davidrevoy.com/data/images/blog/2023/2023-11-01_linux-kernel-broke-my-stylus_xp-pen-artist-pro-16-gen2_net.jpg
[3]: https://docs.krita.org/en/reference_manual/popup-palette.html
[4]: https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help


------- Original Message -------
On Friday, November 3rd, 2023 at 21:05, Illia Ostapyshyn <ostapyshyn@xxxxxxxxxxxxxxxxxxx> wrote:


> Hello David, Hello Jiri,
> 
> The XP-Pen hardware reports the Eraser usage for the upper stylus button.
> Generally, styli report Invert usages when erasing, as described in [1].
> XP-Pen digitizers, however, tend to omit them.
> 
> The generic driver maps the Eraser usage to BTN_TOUCH and the Invert
> usage to BTN_TOOL_RUBBER. Pens conforming to [1] send the Invert usage
> first (switching the tool to BTN_TOOL_RUBBER) followed by Eraser, which
> appears in userspace as a BTN_TOUCH event with the rubber tool set.
> 
> Due to an oversight, devices not reporting Invert had the BTN_TOOL_RUBBER
> event masked. This has caused the kernel to send only BTN_TOUCH events
> without the tool switch when erasing.
> 
> The situation got worse with refactoring done in 87562fcd1342. An eraser
> without Invert caused the hidinput_hid_event state machine to get stuck
> with BTN_TOOL_RUBBER internally (due to it being masked). For the
> userspace, this looked as if the pen was never hovering again, rendering
> it unusable until the next reset. 276e14e6c3 fixes this by adding
> support for digitizers that do not report Invert usages when erasing.
> 
> ---
> 
> David, we are sorry that our patch broke your workflow. However,
> forwarding hardware events as-is to the userspace has always been the
> intended behavior, with a kernel bug preventing it so far. You can still
> remap the eraser button to a right click using xsetwacom:
> 
> xsetwacom set "UGTABLET 24 inch PenDisplay eraser" "Button" "1" "3"
> 
> Replace the device name with the corresponding eraser device from
> "xsetwacom list devices". You can also do this with "xinput set-button-map",
> which works for libinput as well. We have tested this with several
> XP-Pen devices, including Artist 24.
> 
> [1] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states