On 2022/05/11 07:54, Anton Lindqvist wrote:
> 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?
Running it now and I haven't seen any yet, including after pressing the
strange keys and using the trackpad, so I think it works :) Thanks.
> 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);
>
