Lines Matching full:hid
4 HID-BPF
7 HID is a standard protocol for input devices but some devices may require
10 existing HID interfaces.
17 When (and why) to use HID-BPF
20 There are several use cases when using HID-BPF is better
30 With HID-BPF, we can apply this filtering in the kernel directly so userspace
38 HID-BPF allows the userspace program to load the program itself, ensuring we
44 In the HID tree, half of the drivers only fix one key or one byte
61 channels of communication that our HID and input stack do not support.
70 The kernel has a relatively static mapping of HID items to evdev bits.
92 With eBPF, we can intercept any HID command emitted to the device and
113 High-level view of HID-BPF
116 The main idea behind HID-BPF is that it works at an array of bytes level.
117 Thus, all of the parsing of the HID report and the HID report descriptor
124 A corollary of this is that HID-BPF doesn't know about the other subsystems
128 When a BPF program needs to emit input events, it needs to talk with the HID
129 protocol, and rely on the HID kernel processing to translate the HID data into
132 In-tree HID-BPF programs and ``udev-hid-bpf``
136 ``drivers/hid/bpf/progs`` directory. This allows to add selftests to them in
137 ``tools/testing/selftests/hid``.
141 `udev-hid-bpf <https://libevdev.pages.freedesktop.org/udev-hid-bpf/index.html>`_.
144 ``drivers/hid/bpf/progs`` into its own ``src/bpf/stable`` directory. This allows
146 those HID-BPF fixes. ``udev-hid-bpf`` also has capabilities of handling multiple
152 HID-BPF is built "on top" of BPF, meaning that we use bpf struct_ops method to
155 HID-BPF has the following attachment types available:
167 This time, we can do any operations allowed by HID-BPF, and talking to the device is
182 Available ``struct_ops`` for HID-BPF:
195 Available API that can be used in all HID-BPF struct_ops programs:
198 .. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
201 Available API that can be used in syscall HID-BPF programs or in sleepable HID-BPF struct_ops progr…
204 .. kernel-doc:: drivers/hid/bpf/hid_bpf_dispatch.c
207 General overview of a HID-BPF program
245 Effect of a HID-BPF program
248 For all HID-BPF attachment types except for :c:func:`hid_rdesc_fixup`, several eBPF
249 programs can be attached to the same device. If a HID-BPF struct_ops has a
271 HID stack will work on the modified data, with the ``size`` field of the last hid_bpf_ctx
275 processed by the HID stack. Clients (hidraw, input, LEDs) will **not** see this event.
282 in the sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``).
306 the HID device and does a reprobe.
311 There is no ``detach`` facility in HID-BPF. Detaching a program happens when
312 all the user space file descriptors pointing at a HID-BPF struct_ops link are closed.
322 But given that we need to attach a struct_ops to a dedicated HID device, the caller
325 ``hid_id`` is the unique system ID of the HID device (the last 4 numbers in the
326 sysfs path: ``/sys/bus/hid/devices/xxxx:yyyy:zzzz:0000``)
330 We can not rely on hidraw to bind a BPF program to a HID device. hidraw is an
331 artefact of the processing of the HID device, and is not stable. Some drivers
335 On the other hand, the ``hid_id`` is stable for the entire life of the HID device,
340 This is available at ``/sys/bus/hid/devices/BUS:VID:PID.000N/report_descriptor`` as a
346 An (almost) complete example of a BPF enhanced HID device
376 /* HID programs need to be GPL */
379 /* HID-BPF kfunc API definitions */
423 static int attach_filter(struct hid *hid_skel, int hid_id)
434 fprintf(stderr, "can not attach HID-BPF program: %m\n");
446 detach the program from the HID device.
460 /* some more HID-BPF kfunc API definitions */
473 unsigned int hid;
482 ctx = hid_bpf_allocate_context(args->hid);
499 static int set_haptic(struct hid *hid_skel, int hid_id, __u8 haptic_value)
504 .hid = hid_id,