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

[David Revoy]

Hi Benjamin,

Thanks for all the information.

> Could you please use sudo hid-recorder from hid-tools[1] on any kernel
> version and send us the logs here?
> I'll be able to replay the events locally, and understand why the
> kernel doesn't work properly.
> [1] https://gitlab.freedesktop.org/libevdev/hid-tools

Yes, I can. I've done it for the two tablets and you can find the file output hosted here:
https://www.peppercarrot.com/extras/?dir=mailing-list/hid-records

I followed the diagnostic method (for gestures) and file naming suggested in the short videos on this page:
https://digimend.github.io/support/howto/trbl/diagnostics/

I hope that it will be useful, even after the detailed feedback from Eric Gouyer (folays@xxxxxxxxx) on the ML (thank you).

> Generally speaking, relying on X to fix your hardware is going to be a
> dead end. When you switch to wayland, you'll lose all of your fixes,
> which isn't great.

You are right. I hope that the Wayland session will offer possible command line tools to customise devices. But that's another topic. :)


On Monday, November 6th, 2023 at 17:59, Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote:


> Hi David,
> 
> On Mon, Nov 6, 2023 at 2:18 PM David Revoy davidrevoy@xxxxxxxxxxxxxx wrote:
> 
> > 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).
> 
> 
> Hopefully you'll be able to figure out a way to have your emails
> posted to the lkml soon. It's very valuable to have them in
> lore.kernel.org to get the thread context.
> 
> > 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.
> 
> 
> Yes, you are correct. The device talks a given protocol (HID) and is
> supposed to use the specification from Microsoft[0] on how to behave
> properly. As such, it has to convey the "eraser" state by adding
> dedicated information in the event stream.
> 
> In your case, I think we (the kernel and your stylus) simply talk past
> each other and we lose information.
> 
> > 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.
> 
> 
> If the pen has 2 buttons, and an eraser side, it would be a serious
> design flow for XPPEN to report both as eraser.
> 
> Could you please use sudo hid-recorder from hid-tools1 on any kernel
> version and send us the logs here?
> I'll be able to replay the events locally, and understand why the
> kernel doesn't work properly.
> 
> And if there is a design flaw that can be fixed, we might even be able
> to use hid-bpf to change it :)
> 
> > > 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...
> 
> 
> Generally speaking, relying on X to fix your hardware is going to be a
> dead end. When you switch to wayland, you'll lose all of your fixes,
> which isn't great.
> 
> > > 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 observation 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.
> 
> 
> AFAIU, the kernel now "merges" both buttons, which is a problem. It
> seems to be a serious regression. This case is also worrying because I
> added regression tests on hid, but I don't have access to all of the
> various tablets, so I implemented them from the Microsoft
> specification[0]. We need a special case for you 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.
> 
> 
> Again, we can't do more than what the device reports. Well, we can
> always quirk it in some cases, but ideally we don't have to do
> anything. MS spec [0], only shows a single button pen with an eraser
> tail or a pen with 2 buttons, one of them being the eraser one. I'm
> not sure if they decided to prevent dual button pens with eraser tail,
> but Wacom definitely has some, and they work.
> 
> Without the actual data from your pen, I can not tell much, because I
> don't follow which path we are taking on the kernel side. Please
> report with your hid-recorder logs, so I can understand why this is
> happening and how we can fix it.
> 
> > ------- 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.
> 
> 
> AFAICT 276e14e6c3 already had the hid tests integrated at
> tools/testing/selftests/hid/tests/test_tablet.py
> 
> It would have been great to add the cases you are mentioning here,
> because there is a strong chance I'll break things once again when we
> try to fix that regression.
> 
> > > ---
> > > 
> > > 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
> 
> 
> Cheers,
> Benjamin
> 
> [0] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-pen-states
> 1 https://gitlab.freedesktop.org/libevdev/hid-tools