On Fri, May 13, 2022 at 08:43:33PM +0200, Anton Lindqvist wrote: > On Fri, May 13, 2022 at 05:46:35PM +0100, Stuart Henderson wrote: > > 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. > > Great, the diff will be in snaps soon.
I just committed the fix.
