Thank you very much for your corrections. I've applied almost everything (see below), but I have two questions below. Marco >> +This chapter is meant to give a broad overview >> +of what HID report descriptors are, and of how a casual (non kernel) > > (non-kernel) Ok, thank you! > >> +programmer can deal with an HID device that > > a HID device that -> with HID devices as suggested by Peter >> +may a wheel; movement sensitivity differs between different > > may have a wheel; > Ok >> +The format of HID report descriptors is described by two documents, >> +available from the `USB Implementers Forum <https://www.usb.org/>`_ >> +at `this <https://www.usb.org/hid>`_ addresses: > > these Not sure about this. "this" here was meant to be https://www.usb.org/hid , while the two documents are listed below. Would The format of HID report descriptors is described by two documents, available from the `USB Implementers Forum <https://www.usb.org/>`_ `HID web page <https://www.usb.org/hid>`_: be ok? >> +In practice you should not do parse HID report descriptors by hand; > > s/do // Ok > and drop the line's trailing space. (Do that on any lines that have a > trailing space.) > I forgot to run checkpatch, my bad. Will do for v3. >> + It is being actively developed by the Linux HID subsystem mantainers. > > maintainers. Ok >> + >> + # 0x81, 0x02, // Input (Data,Var,Abs) 24 >> + it's actual Data (not constant padding), they represent > > its > ? > "its" is possessive. "it's" means "it is". > -> these bits are actual data ok? >> + a single variable (Var) and the value are Absolute (not relative); > > value is > or values are > values are thank you! >> + This time the data is Relative (Rel), i.e. it represent > > represents > >> +An HID devices can have Input Reports, like > > A HID device > -> HID devices that are not .... as suggested by Peter Ok? >> +Note that, however, that you can have different Report IDs > > Note, however, that > Thank you! >> + >> +There can be a number of reasons for why a device does not behave > > s/for // > Ok, thank you >> +* the HID report descriptor may need some "quirks" (see later on); > > on). Ok >> + >> +As a consequence, a suitable ``/dev/input/event*`` will not created > > not be created > Ok >> +for each Application Collection, and/or the events >> +there will match what you would expect. > > will not > ? > will not >> + >> + >> +Quirks >> +------ >> + >> +There are some known peculiarities of HID devices that the kernel >> +knows how to fix - these are called the HID quirks and a list of those >> +are available in `include/linux/hid.h`. > > is available > Ok >> + >> +Should this be the case, >> +it should be enough to add the required quirk, > > quirk > (no comma) > Ok >> +should go into hid-quirks.c and **submitted upstream**. > > **be submitted upstream**. > Ok >> +See, again, Documentation/process/submitting-patches.rst >> +for guidelines on how to do submit a patch. > > how to submit a patch. > Ok >> +for your code, see e.g. `samples/hid_mouse.bpf.c`:: > > samples/hid/hid_mouse.bpf.c > Right. >> +Check Documentation/hid/hidreport-parsing.rst >> +if you need an help navigating the HID manuals and > > any > Ok >> +and that particular HID device will will start > > will start > Ok >> + >> +.. [#hidraw] reading hidraw: see Documentation/hid/hidraw.rst and > > read > Ok >> +We have an ``Usage Page``, thus we need to refer to HUT Sec. 3, > > have a > Ok >> +is given in the HID spec Sec. 6.2.2.8 "Local Items", so that we have an ``Usage``. > > have a Ok
