On Thu, 2022-02-24 at 12:31 +0100, Greg KH wrote: > On Thu, Feb 24, 2022 at 12:08:22PM +0100, Benjamin Tissoires wrote: > > Hi there, > > > > This series introduces support of eBPF for HID devices. > > > > I have several use cases where eBPF could be interesting for those > > input devices: > > > > - simple fixup of report descriptor: > > > > In the HID tree, we have half of the drivers that are "simple" and > > that just fix one key or one byte in the report descriptor. > > Currently, for users of such devices, the process of fixing them > > is long and painful. > > With eBPF, we could externalize those fixups in one external repo, > > ship various CoRe bpf programs and have those programs loaded at > > boot > > time without having to install a new kernel (and wait 6 months for > > the > > fix to land in the distro kernel) > > Why would a distro update such an external repo faster than they > update > the kernel? Many sane distros update their kernel faster than other > packages already, how about fixing your distro? :) > > I'm all for the idea of using ebpf for HID devices, but now we have > to > keep track of multiple packages to be in sync here. Is this making > things harder overall? I don't quite understand how taking eBPF quirks for HID devices out of the kernel tree is different from taking suspend quirks out of the kernel tree: https://www.spinics.net/lists/linux-usb/msg204506.html
