Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

[Posted April 22, 2024 by corbet]

Peter Hutterer announces udev-hid-bpf, a tool to facilitate the loading of BPF programs that make human-input devices work correctly.

eBPF was originally written for network packet filters but as of kernel v6.3 and thanks to Benjamin, we have BPF in the HID subsystem. HID actually lends itself really well to BPF because, well, we have a byte array and to fix our devices we need to do complicated things like "toggle that bit to zero" or "swap those two values".

See this article for more information on the BPF-HID mechanism.

(Log in to post comments)

Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

Posted Apr 22, 2024 16:13 UTC (Mon) by flussence (subscriber, #85566) [Link]

Thank you!

There's one extra feature I'd like: the ability to munge `libinput record` output through a BPF program so I can diff it against the result on demand instead of needing the hardware. The problem I want to fix happens about as predictably as one of those "Annoyatron" prank devices.

Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

Posted Apr 23, 2024 0:11 UTC (Tue) by whot (subscriber, #50317) [Link]

> the ability to munge `libinput record` output through a BPF program

libinput record's output already includes the HID report descriptor so that's part 1 done? :)

Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

Posted Apr 22, 2024 17:10 UTC (Mon) by Heretic_Blacksheep (subscriber, #169992) [Link]

I think it's interesting because USB in general acts enough like a packet network that it can be treated like one by reading its data in real time with packet sniffers + the appropriate driver much like you can with any traditional NIC. This is what makes eBPF useful in this particular context. But eBPF's equally useful in other areas where packet based communication is the norm.

Also... the problem with HID is the original 1.0 spec was finalized in 1996, while the most current release, v. 1.11, dates from 2001! That's from an era when USB was still limited to a total of 12 Mbits/s. It also specifically allows vendor extensions to the standard, which a lot of people seem to be unaware. Even if you ignore all the comically broken products over the years (there are indeed many), it's impossible to strictly adhere to a 20+ year old arthritic standard while still adding features that weren't possible 20-30 years ago without resorting to vendor extensions and external control software to manage those protocols the USB HID spec doesn't define. It's not fair to call a peripheral 'broken' when it includes features not available in a strict interpretation of the spec nor were even foreseeable in 2001. These days we have bling-y user configured LED controllers (arguably useless except for marketing, meh turn it off and go), macro record and playback via internal and external methods, visual feedback and status output displays, keyboards with their own embedded GP computer & user programmable firmware (like the Keychron V series I'm typing this on), built-in USB hubs, not to mention the separate can-of-worms that are wireless keyboards. Some of those features were barely envisioned in 2001, and the rest not at all. Linux distro development models are particularly unsuitable for pushing out device stacks in any reasonable time frame to the end users who have no wish to be device driver development guinea pigs. The eBPF solution is probably the only workaround for a notoriously slow driver trickle-down that's acceptable in the long run.

One off topic plug for OpenBSD here... at least you're usually only 6 months away from a driver update if you track the stable releases, assuming it's a device under active development. They've been particularly good at tracking AMDGPU stack updates. LTS Linux distros releases can be considerably longer waits, with inconsistent device support results. I don't use OpenBSD regularly, but I have to give them credit for an open source project, they're pretty good with device drivers... just less so with ACPI tables.

Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

Posted Apr 22, 2024 17:52 UTC (Mon) by WolfWings (subscriber, #56790) [Link]

...I have to counterpoint here, have you actually read the full list of supported options in the "archaic" HID 1.11 spec? The thing has enough specifics to detail that a mouth-capture sensor has inputs for the upper and lower lip, and if it can track your eyelashes separately or not.

The entire reason the "BootHID" stuff exists is because the full spec is enormously rich and complex.

You're also confusing configuration protocols with interface aspects. HID starts and stops with "We want to get inputs into the computer to use elsewhere." not "We need to configure these external devices and/or upload arbitrary code to them." which is wildly outside the scope of HID in the first place. In some cases a lot of devices just expose things as a filesystem over USB Mass Storage, which is honestly one of the better approaches IMHO.

But yeah in general just because a standard (or anything else) hasn't been "updated" recently doesn't mean it's not just... complete, finished, enclosed it's scope fully in a way nobody's found a need to expand on yet.

Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

Posted Apr 22, 2024 18:32 UTC (Mon) by flussence (subscriber, #85566) [Link]

Agreed; the specs around USB are ancient and ugly, but spare a thought for people like the primary author of the comedi drivers, who's trying to make hardware like this work without *any* of the details nailed down. Or the V4L stack.

(and for others that think USB HID's bad, give the DDC spec a peruse some time... we narrowly avoided the timeline where most common input devices talk I2C!)

Hutterer: udev-hid-bpf: quickstart tooling to fix your HID devices with eBPF

Posted Apr 22, 2024 23:58 UTC (Mon) by Heretic_Blacksheep (subscriber, #169992) [Link]

I didn't intend to imply it wasn't robust for what it was designed to do. I'm not in the camp of "old is bad" nor, necessarily that an old specification is automatically obsolete. My admittedly hyperbolic point was probably less than clear, that it's impossible to be complete forever more and anticipate all possible kinds of human interfaces for an indefinite future. Therefore where the spec is silent or doesn't quite cover a desired feature, it's not 'broken' to do your own thing, especially if the drivers (in general, not calling out any OS in this case) themselves are incomplete. After all, there's the caveat in the spec about extensions explicitly being allowed which would imply generic class drivers would be insufficient for any device with those vendor extensions. In any case, the eBPF solution could potentially get those devices as well as genuinely broken ones according to the spec, into general support much quicker than the trickle down effect we currently have. I also wonder if a similar workaround could fix problems with out-of-spec USB mass storage class devices with minimal loss of performance.

Your counter point is well taken, however.