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);
