Documentation/hid/hid-bpf.rst

38 HID-BPF allows the userspace program to load the program itself, ensuring we
48 We can reduce this burden by providing an eBPF program instead. Once such a
49 program  has been verified by the user, we can embed the source code into the
50 kernel tree and ship the eBPF program and load it directly instead of loading
80 events into wheel events. Also, the userspace program can set/unset the haptic
96 kernel/bpf program because we can intercept any incoming command.
119 program.
128 When a BPF program needs to emit input events, it needs to talk with the HID
162 A ``hid_device_event`` is calling a BPF program when an event is received from
171 BPF program of this type. This is called on ``probe`` from the driver and allows to
172 change the report descriptor from the BPF program. Once a ``hid_rdesc_fixup``
173 program has been loaded, it is not possible to overwrite it unless the program which
174 inserted it allows us by pinning the program and closing all of its fds pointing to it.
207 General overview of a HID-BPF program
214 it, a bpf program needs to first call :c:func:`hid_bpf_get_data`.
245 Effect of a HID-BPF program
253 Unless ``BPF_F_BEFORE`` is added to the flags while attaching the program, the new
254 program is appended at the end of the list.
255 ``BPF_F_BEFORE`` will insert the new program at the beginning of the list which is
267 If a program changes the data associated with the context, the next one will see
274 A BPF program returning a negative error discards the event, i.e. this event will not be
284 To retrieve a context associated with the device, the program must call
294 The ``hid_rdesc_fixup`` program works in a similar manner to ``.report_fixup``
301 The eBPF program can modify the data buffer at-will and the kernel uses the
304 Whenever a struct_ops containing a ``SEC("struct_ops/hid_rdesc_fixup")`` program
305 is attached (if no program was attached before), the kernel immediately disconnects
311 There is no ``detach`` facility in HID-BPF. Detaching a program happens when
318 Attaching a bpf program to a device
323 must set ``hid_id`` in the struct_ops map before loading the program in the kernel.
330 We can not rely on hidraw to bind a BPF program to a HID device. hidraw is an
344 component that loads the eBPF program.
370 For that, we can create a basic skeleton for our BPF program::
434   		fprintf(stderr, "can not attach HID-BPF program: %m\n");
441 Our userspace program can now listen to notifications on the ring buffer, and
444 When the userspace program doesn't need to listen to events anymore, it can just
446 detach the program from the HID device.
448 Of course, in other use cases, the userspace program can also pin the fd to the
454 To be able to change the haptic feedback from the tablet, the userspace program
457 Instead of using hidraw for that, we can create a ``SEC("syscall")`` program
497 And then userspace needs to call that program directly::
520 Now our userspace program is aware of the haptic state and can control it. The
521 program could make this state further available to other userspace programs