On Thu, 3 Dec 2020 22:20:17 -0800 Randy Dunlap <rdunlap@xxxxxxxxxxxxx> wrote: > Do basic editing & correction to hiddev.rst: > - use HID instead of hid consistently One case inline, where I think the usage of hid-core might have been deliberate. > - add hyphenation of multi-word adjectives > - drop a duplicate word > - unhyphenate "a priori" > > > Signed-off-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > Cc: Jiri Kosina <jikos@xxxxxxxxxx> > Cc: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> > Cc: linux-input@xxxxxxxxxxxxxxx > Cc: Jonathan Corbet <corbet@xxxxxxx> > Cc: linux-doc@xxxxxxxxxxxxxxx > --- > Documentation/hid/hiddev.rst | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > --- linux-next-20201201.orig/Documentation/hid/hiddev.rst > +++ linux-next-20201201/Documentation/hid/hiddev.rst > @@ -27,7 +27,7 @@ the following:: > --> hiddev.c ----> POWER / MONITOR CONTROL > > In addition, other subsystems (apart from USB) can potentially feed > -events into the input subsystem, but these have no effect on the hid > +events into the input subsystem, but these have no effect on the HID > device interface. > > Using the HID Device Interface > @@ -72,8 +72,8 @@ The hiddev API uses a read() interface, > > HID devices exchange data with the host computer using data > bundles called "reports". Each report is divided into "fields", > -each of which can have one or more "usages". In the hid-core, > -each one of these usages has a single signed 32 bit value. > +each of which can have one or more "usages". In the HID core, Hmm. hid-core is (I think) kind of referring to the code in hid-core.c Whereas a Human Interface Device core (HID core) sounds like something different. Not my doc though! > +each one of these usages has a single signed 32-bit value. > > read(): > ------- > @@ -113,7 +113,7 @@ HIDIOCAPPLICATION > - (none) > > This ioctl call returns the HID application usage associated with the > -hid device. The third argument to ioctl() specifies which application > +HID device. The third argument to ioctl() specifies which application > index to get. This is useful when the device has more than one > application collection. If the index is invalid (greater or equal to > the number of application collections this device has) the ioctl > @@ -181,7 +181,7 @@ looked up by type (input, output or feat > must be filled in by the user. The ID can be absolute -- the actual > report id as reported by the device -- or relative -- > HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT | > -report_id) for the next report after report_id. Without a-priori > +report_id) for the next report after report_id. Without a priori > information about report ids, the right way to use this ioctl is to > use the relative IDs above to enumerate the valid IDs. The ioctl > returns non-zero when there is no more next ID. The real report ID is > @@ -200,7 +200,7 @@ HIDIOCGUCODE > - struct hiddev_usage_ref (read/write) > > Returns the usage_code in a hiddev_usage_ref structure, given that > -given its report type, report id, field index, and index within the > +its report type, report id, field index, and index within the > field have already been filled into the structure. > > HIDIOCGUSAGE
