udev-hid-bpf To Help Enable HID-BPF Use Rather Than Kernel Drivers To Fix HID Hardware
([Hardware] 6 Hours Ago
udev-hid-bpf)
- Reference: 0001459091
- News link: https://www.phoronix.com/news/udev-hid-bpf
- Source link:
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 programs. The Rust-written udev-hid-bpf project is ready to help in that enabling effort.
Red Hat input expert Peter Hutterer blogged last week on the udev-hid-bpf project he's been working on along with Red Hat's Benjamin Tissoires. The udev-hid-bpf provides the tooling to fix HID devices using eBPF. The udev-hid-bpf project itself is written in the Rust programming language but the eBPF programs continue to be written in C.
[1]HID-BPF has been quite an interesting approach to deal with quirky/buggy HID hardware and with udev-hid-bpf it helps in getting that effort to pan out. Peter explained in [2]the blog post announcing the udev-hid-bpf work:
"If we want to fix our devices we usually need to do one of two things: fix the report descriptor to enable/disable/change some of the values the device pretends to support. For example, we can say we support 5 buttons instead of the supposed 8. Or we need to fix the report by e.g. inverting the y value for the device. This can be done in a custom kernel driver but a HID BPF program is quite a lot more convenient.
...
udev-hid-bpf is a tool to make the development and testing of HID BPF programs simple, and collect HID BPF programs. You basically run meson compile and meson install and voila, whatever BPF program applies to your devices will be auto-loaded next time you plug those in. If you just want to test a single bpf.o file you can udev-hid-bpf install /path/to/foo.bpf.o and it will install the required udev rule for it to get loaded whenever the device is plugged in. If you don't know how to compile, you can grab a tarball from our CI and test the pre-compiled bpf.o. Hooray, even simpler."
The udev-hid-bpf documentation is on [3]FreeDesktop.org for those wanting to learn more.
[1] https://www.phoronix.com/search/HID-BPF
[2] http://who-t.blogspot.com/2024/04/udev-hid-bpf-quickstart-tooling-to-fix.html
[3] https://libevdev.pages.freedesktop.org/udev-hid-bpf/index.html
Red Hat input expert Peter Hutterer blogged last week on the udev-hid-bpf project he's been working on along with Red Hat's Benjamin Tissoires. The udev-hid-bpf provides the tooling to fix HID devices using eBPF. The udev-hid-bpf project itself is written in the Rust programming language but the eBPF programs continue to be written in C.
[1]HID-BPF has been quite an interesting approach to deal with quirky/buggy HID hardware and with udev-hid-bpf it helps in getting that effort to pan out. Peter explained in [2]the blog post announcing the udev-hid-bpf work:
"If we want to fix our devices we usually need to do one of two things: fix the report descriptor to enable/disable/change some of the values the device pretends to support. For example, we can say we support 5 buttons instead of the supposed 8. Or we need to fix the report by e.g. inverting the y value for the device. This can be done in a custom kernel driver but a HID BPF program is quite a lot more convenient.
...
udev-hid-bpf is a tool to make the development and testing of HID BPF programs simple, and collect HID BPF programs. You basically run meson compile and meson install and voila, whatever BPF program applies to your devices will be auto-loaded next time you plug those in. If you just want to test a single bpf.o file you can udev-hid-bpf install /path/to/foo.bpf.o and it will install the required udev rule for it to get loaded whenever the device is plugged in. If you don't know how to compile, you can grab a tarball from our CI and test the pre-compiled bpf.o. Hooray, even simpler."
The udev-hid-bpf documentation is on [3]FreeDesktop.org for those wanting to learn more.
[1] https://www.phoronix.com/search/HID-BPF
[2] http://who-t.blogspot.com/2024/04/udev-hid-bpf-quickstart-tooling-to-fix.html
[3] https://libevdev.pages.freedesktop.org/udev-hid-bpf/index.html
johncall