On Wed, 1 Nov 2023, David Revoy wrote:
> Hi Jason Gerecke, José Expósito, Jiri Kosina and Illia Ostapyshyn,
>
> I am emailing to draw your attention and expertise to a problem I had
> earlier this week with my Xp-Pen Artist 24 Pro display tablet under
> Fedora Linux 38 KDE after a kernel update.
>
> The second button on my stylus changed from a right-click (which I could
> customise with xsetwacom or any GUI like kcm-tablet) to a button that
> feels 'hardcoded' and now switches the whole device to an eraser mode.
> This makes my main tool unusable.
>
> I don't have the skills to write a proper kernel bug report, workaround
> or even identify the exact source of the issue. I have written a blog
> post about this with more details here:
> https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
> , contacting you was something suggested by the comments.
>
> Thank you very much if you can help me.
CCing a couple more people involved both in 276e14e6c3 and 87562fcd1342,
and mailinglists.
This is almost certainly the behavior introduced by 276e14e6c3, where
previously the button was mapped to BTN_TOUCH, but now it's mapped to
BTN_TOOL_RUBBER, causing user-visible change in behavior.
--
Jiri Kosina
SUSE Labs
On Wed, Nov 01, 2023 at 08:37:40PM +0100, Jiri Kosina wrote:
> On Wed, 1 Nov 2023, David Revoy wrote:
>
> > Hi Jason Gerecke, José Expósito, Jiri Kosina and Illia Ostapyshyn,
> >
> > I am emailing to draw your attention and expertise to a problem I had
> > earlier this week with my Xp-Pen Artist 24 Pro display tablet under
> > Fedora Linux 38 KDE after a kernel update.
> >
> > The second button on my stylus changed from a right-click (which I could
> > customise with xsetwacom or any GUI like kcm-tablet) to a button that
> > feels 'hardcoded' and now switches the whole device to an eraser mode.
> > This makes my main tool unusable.
> >
> > I don't have the skills to write a proper kernel bug report, workaround
> > or even identify the exact source of the issue. I have written a blog
> > post about this with more details here:
> > https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
> > , contacting you was something suggested by the comments.
> >
> > Thank you very much if you can help me.
>
> CCing a couple more people involved both in 276e14e6c3 and 87562fcd1342,
> and mailinglists.
>
> This is almost certainly the behavior introduced by 276e14e6c3, where
> previously the button was mapped to BTN_TOUCH, but now it's mapped to
> BTN_TOOL_RUBBER, causing user-visible change in behavior.
>
Thanks for the report.
David, can you resend the regression report as plain text email (preferably
with 276e14e6c3 people and [email protected] Cc'ed)? You may need to
see kernel documentation [1] for how to configure your email client to send
plain text emails. Also, include in your report details from your blog post.
Thanks.
[1]: https://docs.kernel.org/process/email-clients.html
--
An old man doll... just what I always wanted! - Clara
On 02.11.23 01:44, Bagas Sanjaya wrote:
> On Wed, Nov 01, 2023 at 08:37:40PM +0100, Jiri Kosina wrote:
>> On Wed, 1 Nov 2023, David Revoy wrote:
>>
>>> Hi Jason Gerecke, José Expósito, Jiri Kosina and Illia Ostapyshyn,
>>>
>>> I am emailing to draw your attention and expertise to a problem I had
>>> earlier this week with my Xp-Pen Artist 24 Pro display tablet under
>>> Fedora Linux 38 KDE after a kernel update.
>>>
> […]
>>> Thank you very much if you can help me.
> […]
> Thanks for the report.
>
> David, can you resend the regression report as plain text email (preferably
> with 276e14e6c3 people and [email protected] Cc'ed)? You may need to
> see kernel documentation [1] for how to configure your email client to send
> plain text emails. Also, include in your report details from your blog post.
Bagas, I know you mean well, but I think you are making things
unnecessarily complicated for both David and the developers here. Sure,
the mail Jiri quoted did not make it to lore, but whatever, for him it
was apparently good enough; and I suspect this "quote forwarding to
others" is good enough for the people he brought into the loop as well.
Yes, there are developers that don't want to go to a website for
details, but if that's the case it's likely better to ask for details in
this thread instead of opening a second one. And regression tracking can
work without a separate mail as well.
Ciao, Thorsten
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]
On 01.11.23 20:37, Jiri Kosina wrote:
> On Wed, 1 Nov 2023, David Revoy wrote:
>
>> Hi Jason Gerecke, José Expósito, Jiri Kosina and Illia Ostapyshyn,
>>
>> I am emailing to draw your attention and expertise to a problem I had
>> earlier this week with my Xp-Pen Artist 24 Pro display tablet under
>> Fedora Linux 38 KDE after a kernel update.
>>
>> The second button on my stylus changed from a right-click (which I could
>> customise with xsetwacom or any GUI like kcm-tablet) to a button that
>> feels 'hardcoded' and now switches the whole device to an eraser mode.
>> This makes my main tool unusable.
>>
>> I don't have the skills to write a proper kernel bug report, workaround
>> or even identify the exact source of the issue. I have written a blog
>> post about this with more details here:
>> https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
>> , contacting you was something suggested by the comments.
>>
>> Thank you very much if you can help me.
Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:
#regzbot ^introduced 276e14e6c3
https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
#regzbot title HID: input: stylus of Xp-Pen Artist 24 Pro display tablet
changed behavior
#regzbot ignore-activity
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
On 02/11/2023 13:31, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 02.11.23 01:44, Bagas Sanjaya wrote:
>> On Wed, Nov 01, 2023 at 08:37:40PM +0100, Jiri Kosina wrote:
>>> On Wed, 1 Nov 2023, David Revoy wrote:
>>>
>>>> Hi Jason Gerecke, José Expósito, Jiri Kosina and Illia Ostapyshyn,
>>>>
>>>> I am emailing to draw your attention and expertise to a problem I had
>>>> earlier this week with my Xp-Pen Artist 24 Pro display tablet under
>>>> Fedora Linux 38 KDE after a kernel update.
>>>>
>> […]
>
>>>> Thank you very much if you can help me.
>> […]
>> Thanks for the report.
>>
>> David, can you resend the regression report as plain text email (preferably
>> with 276e14e6c3 people and [email protected] Cc'ed)? You may need to
>> see kernel documentation [1] for how to configure your email client to send
>> plain text emails. Also, include in your report details from your blog post.
>
> Bagas, I know you mean well, but I think you are making things
> unnecessarily complicated for both David and the developers here. Sure,
> the mail Jiri quoted did not make it to lore, but whatever, for him it
> was apparently good enough; and I suspect this "quote forwarding to
> others" is good enough for the people he brought into the loop as well.
> Yes, there are developers that don't want to go to a website for
> details, but if that's the case it's likely better to ask for details in
> this thread instead of opening a second one. And regression tracking can
> work without a separate mail as well.
>
OK, thanks!
--
An old man doll... just what I always wanted! - Clara
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
On Fri, Nov 03, 2023 at 09:05:25PM +0100, Illia Ostapyshyn 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
Thanks for the explanation!
--
An old man doll... just what I always wanted! - Clara
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 <[email protected]> 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
[Dropped most of the CCs]
On Mon, Nov 06, 2023 at 01:17:55PM +0000, David Revoy wrote:
> 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]).
>
> [1]: https://mastodon.social/@protonmail/111346195283677411
Ohh sick, I'm glad you had more luck with them than I (or others) did!
I'll happily remove that from the docs if it gets removed.
Thanks,
Conor.
Hi David,
On Mon, Nov 6, 2023 at 2:18 PM David Revoy <[email protected]> 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-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.
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.
>
> [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 <[email protected]> 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
On 11/6/23 17:59, Benjamin Tissoires wrote:
> 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-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.
>
> And if there is a design flaw that can be fixed, we might even be able
> to use hid-bpf to change it :)
My wild guess is that XP-Pen 16 Artist Pro reports an Eraser usage
without Invert for the upper button and Eraser with Invert for the
eraser tip. A device-specific driver could work with that, but there
seems to be no way to incorporate two different erasers (thus, allowing
userspace to map them to different actions arbitrarily) in the generic
driver currently.
> 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.
> 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.
The issue preventing David from mapping HID_DG_ERASER to BTN_STYLUS2 is
that the hidinput_hid_event is not compatible with hidinput_setkeycode.
If usage->code is no longer BTN_TOUCH after remapping, it won't be
released when Eraser reports 0. A simple fix is:
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1589,7 +1589,7 @@ void hidinput_hid_event(struct hid_device *hid,
struct hid_field *field, struct
/* value is off, tool is not rubber, ignore */
return;
else if (*quirks & HID_QUIRK_NOINVERT &&
- !test_bit(BTN_TOUCH, input->key)) {
+ !test_bit(usage->code, input->key)) {
/*
* There is no invert to release the tool, let hid_input
* send BTN_TOUCH with scancode and release the tool after.
This change alone fixes David's problem and the right-click mapping in
hwdb works again. However, the tool switches to rubber for the remapped
eraser (here BTN_STYLUS2) events, both for devices with and without
Invert. This does no harm but is not useful either. A cleaner solution
for devices without Invert would be to omit the whole tool switching
logic in this case:
@@ -1577,6 +1577,9 @@ void hidinput_hid_event(struct hid_device *hid,
struct hid_field *field, struct
switch (usage->hid) {
case HID_DG_ERASER:
+ if (*quirks & HID_QUIRK_NOINVERT && usage->code != BTN_TOUCH)
+ break;
+
report->tool_active |= !!value;
Remapping Invert does not work anyway as the Invert tool is hardcoded in
hidinput_hid_event. Even worse, I guess (not tested) trying to do so
would mask BTN_TOOL_RUBBER from dev->keybit and could cause weird
behavior similar to one between 87562fcd1342 and 276e14e6c3. This
raises the question: should users be able to remap Invert after all?
On Mon, Nov 6, 2023 at 9:06 PM Illia Ostapyshyn
<[email protected]> wrote:
>
> On 11/6/23 17:59, Benjamin Tissoires wrote:
>
> > 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-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.
> >
> > And if there is a design flaw that can be fixed, we might even be able
> > to use hid-bpf to change it :)
>
> My wild guess is that XP-Pen 16 Artist Pro reports an Eraser usage
> without Invert for the upper button and Eraser with Invert for the
> eraser tip. A device-specific driver could work with that, but there
> seems to be no way to incorporate two different erasers (thus, allowing
> userspace to map them to different actions arbitrarily) in the generic
> driver currently.
That's exactly why I want to see the exact event flow. We can not do
"wild guesses" unfortunately (not meaning any offenses).
And I am very suspicious about the fact that the stylus reports 2
identical erasers. Because in the past David seemed to be able to have
2 distincts behaviors for the 2 "buttons" (physical button and eraser
tail).
>
>
> > 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.
>
> > 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.
>
> The issue preventing David from mapping HID_DG_ERASER to BTN_STYLUS2 is
> that the hidinput_hid_event is not compatible with hidinput_setkeycode.
> If usage->code is no longer BTN_TOUCH after remapping, it won't be
> released when Eraser reports 0. A simple fix is:
I must confess, being the one who refactored everything, I still don't
believe this is as simple as it may seem. I paged out all of the
special cases, and now, without seeing the event flow I just can not
understand why this would fix the situation.
And BTW, if you have a tool affected by 276e14e6c3, I'd be curious to
get a hid-recorder sample for it so I can get regression tests for it.
>
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1589,7 +1589,7 @@ void hidinput_hid_event(struct hid_device *hid,
> struct hid_field *field, struct
> /* value is off, tool is not rubber, ignore */
> return;
> else if (*quirks & HID_QUIRK_NOINVERT &&
> - !test_bit(BTN_TOUCH, input->key)) {
> + !test_bit(usage->code, input->key)) {
I don't want to be rude, but this feels very much like black magic,
especially because there is a comment just below and it is not
updated. So either the explanation was wrong, or it's not explaining
the situation (I also understand that this is not a formal submission,
so maybe that's the reason why the comment is not updated).
> /*
> * There is no invert to release the tool, let hid_input
> * send BTN_TOUCH with scancode and release the tool after.
>
> This change alone fixes David's problem and the right-click mapping in
> hwdb works again. However, the tool switches to rubber for the remapped
> eraser (here BTN_STYLUS2) events, both for devices with and without
> Invert. This does no harm but is not useful either. A cleaner solution
> for devices without Invert would be to omit the whole tool switching
> logic in this case:
>
> @@ -1577,6 +1577,9 @@ void hidinput_hid_event(struct hid_device *hid,
> struct hid_field *field, struct
>
> switch (usage->hid) {
> case HID_DG_ERASER:
> + if (*quirks & HID_QUIRK_NOINVERT && usage->code != BTN_TOUCH)
> + break;
> +
> report->tool_active |= !!value;
>
> Remapping Invert does not work anyway as the Invert tool is hardcoded in
> hidinput_hid_event. Even worse, I guess (not tested) trying to do so
> would mask BTN_TOOL_RUBBER from dev->keybit and could cause weird
> behavior similar to one between 87562fcd1342 and 276e14e6c3. This
> raises the question: should users be able to remap Invert after all?
>
The kernel is supposed to transfer what the device is. So if it says
this is an eraser, we should not try to change it. Users can then
tweak their own device if they wish through hid-bpf or through
libinput quirks, but when you install a fresh kernel without tweaks,
we should be as accurate as possible.
My main concern is that now we have a device which exports 2 different
interactions as being the same. So either the firmware is wrong, and
we need to quirk it, or the kernel is wrong and merges both, and this
needs fixes as well.
Once every interaction on the device gets its own behavior, userspace
can do whatever they want. It's not the kernel's concern anymore.
BTW, David, were you able to do a revert of 276e14e6c3?
Cheers,
Benjamin
[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]
On 02.11.23 08:44, Linux regression tracking #adding (Thorsten Leemhuis)
wrote:
> On 01.11.23 20:37, Jiri Kosina wrote:
>> On Wed, 1 Nov 2023, David Revoy wrote:
>>
>>> I am emailing to draw your attention and expertise to a problem I had
>>> earlier this week with my Xp-Pen Artist 24 Pro display tablet under
>>> Fedora Linux 38 KDE after a kernel update.
>>>
>>> The second button on my stylus changed from a right-click (which I could
>>> customise with xsetwacom or any GUI like kcm-tablet) to a button that
>>> feels 'hardcoded' and now switches the whole device to an eraser mode.
>>> This makes my main tool unusable.
> [...]
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced 276e14e6c3
> https://www.davidrevoy.com/article995/how-a-kernel-update-broke-my-stylus-need-help
This thread got long, but from briefly skimming it, it seems like the
regressions was dealt with somehow and everybody is happy. Please holler
if I got it wrong, as I hereby remove this from the tracking:
#regzbot resolve: solution found
#regzbot ignore-activity
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.
