On Thu, Jun 22, 2023 at 10:37:29PM +0200, Marco Morandini wrote: > > > > > shameless plug! :) I wrote this post a few years ago, feel free to > > incorporate bits from there into here > > https://who-t.blogspot.com/2018/12/understanding-hid-report-descriptors.html > > > Damn! This is much better than all the tutorials > I found while trying to orient > myself, and I managed to miss it :( > > Would it be ok to link to it from the doc? missed this one sorry - yes, feel free to link to it, extract parts of it without attribution, etc. [...] > > Also: you now already have 2 tools to look at hid and then you use two > > more later (hidrrd and hid-tools). I'd say it's best to just stick to > > one tool to reduce the mental load of having to map different tool > > outputs to what is the same base data. > > I'm not sure about this: I think that hidraw needs to be introduced somewhere, > if for nothing because it's what gets consumed by hid-record . > Furthermore, looking at samples/hidraw/hid-example.c one can learn something, if not a lot. > For the time being I'm leaving the paragraph, moving most of it into a footnote; > of course we can drop it if you have a strong opinion about this. I don't :) The main question is (and I can't answer this for you) is how much of an in-depth introduction you want to provide and at what point prospective readers will have to go to search for more information. At some point there has to be a cut-off but you get to decide where that one is. > >> +in the mouse example, and outputs. > >> +"Output" means that the information is fed > >> +from the device to the human; for examples, > >> +a joystick with force feedback will have > >> +some output. > >> + > >> + > >> +Report IDs and Evdev events > >> +=========================== > >> + > >> +A single device can logically group > >> +data into different, independent sets. > >> +It is *as if* the HID presents > >> +itself as different devices, each exchanging > >> +its own data. The HID report descriptor is unique, > >> +but the different reports are identified by means > >> +of different ``Report ID`` fields. Whenever a ``Report ID`` > >> +is needed it is transmitted as the first byte of any report. > > > > This is a bit ambiguous since it's the collections and applications that > > split the device into different sets, the reports are just different > > ways of reporting data that belongs to one (or more? not 100% sure) of > > those sets then. > > > > And the example below works because you have different collections on > > your device here but that's largely orthogonal to the use of reports. > > I think this came from my misunderstanding of the role of Report IDs > and Application Collections (not that I'm sure to have undertsood everything). > The paragraph has been rewritte, please double check. > I'm glossing on the fact that the same Collection can have different Report IDs > inside (btw: is this correct? And if yes, is this something that is done, in practice?). afaik it is permitted but I'm not sure how common it is. But it's not hard to imagine that a device out there that sends button events through one report and motion through another. Cheers, Peter
