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.
