drivers/hid/bpf/progs/Logitech__SpaceNavigator.bpf.c
Source file repositories/reference/linux-study-clean/drivers/hid/bpf/progs/Logitech__SpaceNavigator.bpf.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/hid/bpf/progs/Logitech__SpaceNavigator.bpf.c- Extension
.c- Size
- 2583 bytes
- Lines
- 87
- Domain
- Driver Families
- Bucket
- drivers/hid
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
vmlinux.hhid_bpf.hhid_bpf_helpers.hbpf/bpf_tracing.h
Detected Declarations
function axesfunction probe
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0-only
/* Copyright (c) 2025 Curran Muhlberger
*/
#include "vmlinux.h"
#include "hid_bpf.h"
#include "hid_bpf_helpers.h"
#include <bpf/bpf_tracing.h>
#define VID_LOGITECH 0x046D
#define PID_SPACENAVIGATOR 0xC626
HID_BPF_CONFIG(
HID_DEVICE(BUS_USB, HID_GROUP_ANY, VID_LOGITECH, PID_SPACENAVIGATOR)
);
/*
* The 3Dconnexion SpaceNavigator 3D Mouse is a multi-axis controller with 6
* axes (grouped as X,Y,Z and Rx,Ry,Rz). Axis data is absolute, but the report
* descriptor erroneously declares it to be relative. We fix the report
* descriptor to mark both axis collections as absolute.
*
* The kernel attempted to fix this in commit 24985cf68612 (HID: support
* Logitech/3DConnexion SpaceTraveler and SpaceNavigator), but the descriptor
* data offsets are incorrect for at least some SpaceNavigator units.
*/
SEC(HID_BPF_RDESC_FIXUP)
int BPF_PROG(hid_fix_rdesc, struct hid_bpf_ctx *hctx)
{
__u8 *data = hid_bpf_get_data(hctx, 0 /* offset */, 4096 /* size */);
if (!data)
return 0; /* EPERM check */
/* Offset of Input item in X,Y,Z and Rx,Ry,Rz collections for all known
* firmware variants.
* - 2009 model: X,Y,Z @ 32-33, Rx,Ry,Rz @ 49-50 (fixup originally
* applied in kernel)
* - 2016 model (size==228): X,Y,Z @ 36-37, Rx,Ry,Rz @ 53-54
*
* The descriptor size of the 2009 model is not known, and there is evidence
* for at least two other variants (with sizes 202 & 217) besides the 2016
* model, so we try all known offsets regardless of descriptor size.
*/
const u8 offsets[] = {32, 36, 49, 53};
for (size_t idx = 0; idx < ARRAY_SIZE(offsets); idx++) {
u8 offset = offsets[idx];
/* if Input (Data,Var,Rel) , make it Input (Data,Var,Abs) */
if (data[offset] == 0x81 && data[offset + 1] == 0x06)
data[offset + 1] = 0x02;
}
return 0;
}
HID_BPF_OPS(logitech_spacenavigator) = {
.hid_rdesc_fixup = (void *)hid_fix_rdesc,
};
SEC("syscall")
int probe(struct hid_bpf_probe_args *ctx)
{
/* Ensure report descriptor size matches one of the known variants. */
if (ctx->rdesc_size != 202 &&
ctx->rdesc_size != 217 &&
ctx->rdesc_size != 228) {
ctx->retval = -EINVAL;
return 0;
}
/* Check whether the kernel has already applied the fix. */
if ((ctx->rdesc[32] == 0x81 && ctx->rdesc[33] == 0x02 &&
ctx->rdesc[49] == 0x81 && ctx->rdesc[50] == 0x02) ||
(ctx->rdesc[36] == 0x81 && ctx->rdesc[37] == 0x02 &&
ctx->rdesc[53] == 0x81 && ctx->rdesc[54] == 0x02))
ctx->retval = -EINVAL;
else
ctx->retval = 0;
return 0;
}
char _license[] SEC("license") = "GPL";
Annotation
- Immediate include surface: `vmlinux.h`, `hid_bpf.h`, `hid_bpf_helpers.h`, `bpf/bpf_tracing.h`.
- Detected declarations: `function axes`, `function probe`.
- Atlas domain: Driver Families / drivers/hid.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.