4 ms·

Software all the way up the input stack seems to be a bit confused about a few things, or there is a lack of understanding that: - graphics tablet digitisers g

by qwery 3y ago

Software all the way up the input stack seems to be a bit confused about a few things, or there is a lack of understanding that: - graphics tablet digitisers generally are not and don't include touch digitisers - tablets are not touch screens - a stylus (tip) isn't a button - a stylus can have buttons By convention, stylus tip interactions are "tools", which seems to be what Linux' BTN_TOOL_* codes are meant to mean. A button on a stylus should never be (directly) translated to a tool -- like how the ~5th button on a mouse is `BTN_EXTRA`, not `BTN_MOUSE`. In this particular case it looks like the thinking is: the device has 2 event codes (which we know as the stylus tip and the barrel button) and it's a stylus^wdigitiser, so map device[0] to `BTN_DIGI` and device[1] to `BTN_DIGI + 1`. editendum: the thing about the BTN_EXTRA doesn't really map... The "digitiser" event codes are being treated in the same way as mouse event codes (device[i] => event[CLASS + i]). The issue is really that the barrel buttons have no (dedicated) event codes.

excircul 3y ago
The XP-Pen hardware reports HID "Eraser" usage (some digitizers with accompanying HID "Invert" usage, others without) for the top button. Linux' generic driver does here nothing more than forwarding the corresponding events from hardware to the userspace. The missing Invert usage caused Linux to report Eraser as regular tip touch to the userspace, which was not intended but caused by an oversight in the kernel code. This, together with a bunch of hacks (Digimend and X11 tweaks), allowed OP to map that button to a right click. Now, with the kernel logic fixed, these hacks do not work anymore. This is a case of xkcd://1172. The userspace solution is to remap BTN_TOOL_RUBBER to a right click for the weird stylus instead.
- qwery 3y ago
  Yes, barrel switches should ideally be reported as "Barrel Switch" and "Secondary Barrel Switch". I have a Huion tablet[-1] that reports the second barrel switch as Eraser. The secondary barrel switch was not in HID originally[0], and I guess some devices were designed to follow an earlier spec -- that, or avoiding Wacom patents. [-1] I don't remember if it's also a uclogic controller? [0] https://www.usb.org/sites/default/files/hutrr46e.txt https://www.usb.org/sites/default/files/hutrr46e.txt

by qwery 3y ago

excircul 3y ago

The XP-Pen hardware reports HID "Eraser" usage (some digitizers with accompanying HID "Invert" usage, others without) for the top button. Linux' generic driver does here nothing more than forwarding the corresponding events from hardware to the userspace. The missing Invert usage caused Linux to report Eraser as regular tip touch to the userspace, which was not intended but caused by an oversight in the kernel code. This, together with a bunch of hacks (Digimend and X11 tweaks), allowed OP to map that button to a right click. Now, with the kernel logic fixed, these hacks do not work anymore. This is a case of xkcd://1172. The userspace solution is to remap BTN_TOOL_RUBBER to a right click for the weird stylus instead.

qwery 3y ago
Yes, barrel switches should ideally be reported as "Barrel Switch" and "Secondary Barrel Switch". I have a Huion tablet[-1] that reports the second barrel switch as Eraser. The secondary barrel switch was not in HID originally[0], and I guess some devices were designed to follow an earlier spec -- that, or avoiding Wacom patents. [-1] I don't remember if it's also a uclogic controller? [0] https://www.usb.org/sites/default/files/hutrr46e.txt https://www.usb.org/sites/default/files/hutrr46e.txt