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

[ostapyshyn@sra.uni-hannover.de]

On 11/8/23 21:34, Benjamin Tissoires wrote:

> Again, you convinced me that this commit was wrong. If people needs to
> also use an ioctl to "fix" it, then there is something wrong.

I don't think we're on the same page here.  Nobody needs to use an ioctl
to fix 276e14e6c3.  Rather, the _exact opposite_: the bug reporter used
an ioctl to remap Eraser to BTN_STYLUS2.  It stopped working after
276e14e6c3 and broke his workflow.  He reported it as a regression,
starting this whole thread.

> Sorry but I tend to disagree. Relying on the ioctl EVIOCSKEYCODE for
> tuning the behavior of a state machine is just plain wrong. When
> people do that, they are doing it at the wrong level and introducing
> further bugs.
>
> The whole pen and touch HID protocols rely on a state machine. You
> just can not change the meaning of it because your hardware maker
> produced a faulty hardware.
>
> [...]
>
> In the same way, if you remap Tip Switch to KEY-A, you won't get
> clicks from your pen. Assuming you can do that with any event on any
> HID device is just plain wrong.
> That ioctl is OK-ish for "remapping" simple things like keys. In our
> case, the whole firmware follows a state machine, so we can not change
> it. It has to be remapped in a later layer, in libinput, your
> compositor, or in your end user application.

I don't disagree.  Forbidding EVIOCSKEYCODE ioctls for pen and touch HID
is a legitimate way to resolve this (an appealing one too -- accounting
for it in hidinput_hid_event might be a hellish task).

Should we forbid remapping Eraser too?  If your answer is yes, then we
can finish this conversation here and leave the code as it is now,
because __the regression__ is a user not being able to use an ioctl to
remap Eraser after 276e14e6c3.  Otherwise, if we do make an exemption for
David's Eraser, the fix is as simple as replacing BTN_TOUCH with
usage->code on line 1594 of hid-input.c.

> How many of such devices do we have? Are they all UGTablet like the
> XP-PEN? Are they behaving properly on Windows without a proprietary
> driver?
>
> [...]
>
> I might buy the "invertless" devices are a thing if I can get more
> data about it. So far there are only 2 of them, and they add extra
> complexity in the code when we can just patch the devices to do the
> right thing.

There might or might not be more devices like this in the wild.  It looks
like BarrelSwitch2 was added only 2013 [1], which is why so many styli
use Eraser for the second button.  Setting two bits for a single button
just to adhere to Microsoft's *recommendation* is nice for compatibility,
but I can imagine vendors taking a shortcut and omitting Invert
altogether.  The HID specification alone just lists the usages and says
nothing about how they relate to each other.

XP-Pen Artist 24 does work on Windows with the generic driver.  The
Eraser engages as soon as the button is pressed, without touching the
screen.

> New hardware isn't supposed to be supported on an old kernel and is
> not considered as a regression. However, David mentioned that the
> device was "working" on 6.5.0 but broke in 6.5.8 with the patch
> mentioned above. This is a regression that needs to be tackled.
> Especially because it was introduced in 6.6 but backported into 6.5.

To make sure we're talking about the same thing:

1. "Broke" in this context means that the ioctl remapping from Eraser to
   right-click stopped working.

2. XPPen 16 Pro Gen2 is a whole different topic, untouched by 276e14e6c3.

[1] https://www.usb.org/sites/default/files/hutrr46e.txt