On Fri, May 28, 2021 at 09:52:57PM -0500, joshua stein wrote: > On Wed, 26 May 2021 at 08:13:52 +0200, Anton Lindqvist wrote: > > On Tue, May 25, 2021 at 08:31:14AM +0200, Anton Lindqvist wrote: > > > On Mon, May 24, 2021 at 09:17:26AM -0500, joshua stein wrote: > > > > This is useful for parsing the report descriptor with a different > > > > tool to find issues with our HID parser. > > > > > > > > I've found https://eleccelerator.com/usbdescreqparser/ to be > > > > helpful. > > > > > > > > > > > > diff --git usr.bin/usbhidctl/usbhid.c usr.bin/usbhidctl/usbhid.c > > > > index 921f211a280..bd0b5da0222 100644 > > > > --- usr.bin/usbhidctl/usbhid.c > > > > +++ usr.bin/usbhidctl/usbhid.c > > > > @@ -106,6 +106,11 @@ static struct { > > > > #define REPORT_MAXVAL 2 > > > > }; > > > > > > > > +struct report_desc { > > > > + uint32_t size; > > > > + uint8_t data[1]; > > > > +}; > > > > > > This structure is defined in lib/libusbhid/usbvar.h which is not > > > installed. Maybe it should and avoid this repetition and potential ABI > > > breaks (quite unlikely but still)? > > > > Another approach which keeps the structure opaque is the extend the > > usbhid(3) API with something like: > > > > void > > hid_get_report_desc_data(report_desc_t d, uint8_t **data, uint32_t > > *size) > > { > > *data = d->data; > > *size = d->size; > > } > > Here's a version of that:
ok anton@
