udev-hid-bpf To Help Enable HID-BPF Use Rather Than Kernel Drivers To Fix HID Hardware

[phoronix]

Phoronix: udev-hid-bpf To Help Enable HID-BPF Use Rather Than Kernel Drivers To Fix HID Hardware

Right now for buggy HID hardware or other input devices not exactly aligning to specs or having known hardware workarounds required, a new Linux kernel driver tends to be needed or at least quirks to be added to existing kernel driver code. There's no shortage of wonky HID hardware/drivers out there to deal with such odd cases. Due to the lengthy kernel cycles and other factors involved, leveraging (e)BPF has long been talked about as one of the areas where it may make sense for being able to more quickly send out hardware support fixes in the form of eBPF problems. The Rust-written udev-hid-bpf project is ready to help in that enabling effort...

https://www.phoronix.com/news/udev-hid-bpf

[johncall]

Great article! I think there may be a typo in the first paragraph "eBPF problems." should have been "eBPF programs."

[Michael]

Great article! I think there may be a typo in the first paragraph "eBPF problems." should have been "eBPF programs."

Yep thanks, fixed.

[dumb ways to code]

This is huge, lowering the bar for the devs for removing hardware papercuts is something that could make a real difference for the regular Joe who just needs the USB thingy to work with his old LTS distro.

Could this be used to replace xpad?

[swastika]

This is huge, lowering the bar for the devs for removing hardware papercuts is something that could make a real difference for the regular Joe who just needs the USB thingy to work with his old LTS distro.

Could this be used to replace xpad?

In theory, likely yes.

[WiR3D]

If this works and other distros climb on board this could easily become a must have.

I think the trick is when do you upstream to the kernel? Or will the kernel just offload quirks to this into the future? Which means simpler hid implementions in the kernel itself.