On Tue, May 10, 2022 at 02:51:07PM +0100, Stuart Henderson wrote: > On 2022/05/10 08:12, Anton Lindqvist wrote: > > On Mon, May 09, 2022 at 05:44:29PM +0100, Stuart Henderson wrote: > > > I have a USB combi keyboard/trackpad thing which is triggering "bad > > > repid 33" frequently while attached (between a couple of times a minute, > > > and once every few minutes). It does work but it's annoying. > > > > > > Presumably this is because it has non-contiguous report IDs? > > > Anyone have an idea how to handle it? > > > > Could you send me the raw report descriptors: > > > > $ (set -e; i=0; while :; do doas usbhidctl -f /dev/uhid$i -R > > >/tmp/uhid$i.raw; i=$((i + 1)); done) > >
My guess here is that uhidev_maxrepid() does not observe all hid items as it passes hid_none as the kind to hid_start_parse(). The userspace equivalent of hid_start_parse() accepts a kind bitmask allowing hid_get_item() to return items of varying kinds. For the kernel, we could treat hid_none as a sentinel representing all possible hid kinds. Does the following diff get rid of the bad repid output? diff --git sys/dev/hid/hid.c sys/dev/hid/hid.c index 1c4d5fa45e0..dd03d6d8943 100644 --- sys/dev/hid/hid.c +++ sys/dev/hid/hid.c @@ -229,7 +229,7 @@ hid_get_item(struct hid_data *s, struct hid_item *h) * Only copy HID item, increment position and return * if correct kind! */ - if (s->kind == c->kind) { + if (s->kind == hid_none || s->kind == c->kind) { *h = *c; DPRINTF("%u,%u,%u\n", h->loc.pos, h->loc.size, h->loc.count);