On Wed, Nov 8, 2023 at 10:34 AM Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote: > > On Wed, Nov 8, 2023 at 10:23 AM José Expósito <jose.exposito89@xxxxxxxxx> wrote: > > > > Hi Benjamin, > > > > On Wed, Nov 08, 2023 at 10:04:30AM +0100, Benjamin Tissoires wrote: > [...] > > > > > > > > > > > So, the behavior probably breaks the specs, but sincerely I'm happy to > > > > have the "eraser" button independent of the "rubber eraser", which > > > > makes the stylus a somewhat 4-buttons stylus (tip, button1, button2, > > > > rubber), and I would like to keep this. > > > > > > Yes, and I'd like to keep it that way, even if 6.6 and 6.5.8 > > > apparently broke it. > > > > > > So, to me: > > > - 276e14e6c3993317257e1787e93b7166fbc30905 is wrong: this is a > > > firmware bug (reporting invert through eraser) and should not be > > > tackled at the generic level, thus it should be reverted > > > - both of these tablets are forwarding the useful information, but not > > > correctly, which confuses the kernel > > > - I should now be able to write regression tests > > > - I should be able to provide HID-BPF fixes for those tablets so that > > > we can keep them working with or without > > > 276e14e6c3993317257e1787e93b7166fbc30905 > > > reverted (hopefully) > > > - problem is I still don't have the mechanics to integrate the HID-BPF > > > fixes directly in the kernel tree, so maybe I'll have to write a > > > driver for XP-Pen while these internals are set (it shouldn't > > > interfere with the HID-BPF out of the tree). > > > > I already added support for a few XP-Pen devices on the UCLogic driver > > and I was planning to start working on this one during the weekend in > > my DIGImend fork (to simplify testing). > > > > Let me know if you prefer to add it yourself or if you want me to ping > > you in the DIGImend discussion. > > > > So far, I really have to work on this now. It's a good use case for > HID-BPF and it's a regression that I'd like to be fixed ASAP. > I'd appreciate any reviews :) Alright, I made quite some progress so far: - regressions tests have been written (branch wip/xp-pen of my fork on freedesktop[0]) that branch can not go in directly as it just adds the tests, and thus is failing - I made the fixes through HID-BPF[1] Anyone using those 2 tablets and using Fedora should be able to just grab the artifact at [2], uncompress it and run `sudo ./install.sh --verbose`. This will install the bpf programs in /lib/firmware/hid/bpf/ and will automatically load them when the device is connected. For those not using Fedora, the binary might work (or not, not sure), but you can always decompress it, and check if running `udev-hid-bpf_0.1.0/bin/udev-hid-bpf --version` returns the correct version or just fails. If you get "udev-hid-bpf 0.1.0", then running `sudo ./install.sh --verbose` should work, as long as the kernel has CONFIG_HID_BPF set to 'Y'. > > Also, good to know that I can probably piggyback on hid-uclogic for > fixing those 2 devices in the kernel. > Next step will be to fix them using a kernel driver, but it seems that the uclogic driver is doing more than just report descriptor fixups, so maybe I'll have to use a different driver. But the point is, in theory, if you are affected by those bugs, using the udev-hid-bpf should fix the issue, and this should also be resilient to further kernel updates. I'd appreciate testing when I got the full kernel series up and ready, of course. Cheers, Benjamin [0] https://gitlab.freedesktop.org/bentiss/hid/-/tree/wip/xp-pen?ref_type=heads [1] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/merge_requests/27 [2] https://gitlab.freedesktop.org/bentiss/udev-hid-bpf/-/jobs/51350589/artifacts/raw/udev-hid-bpf_0.1.0.tar.xz
