[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201205171708.55251bb7@archlinux>
Date: Sat, 5 Dec 2020 17:17:08 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: linux-kernel@...r.kernel.org, Jiri Kosina <jikos@...nel.org>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
linux-input@...r.kernel.org,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
linux-iio@...r.kernel.org, Jonathan Corbet <corbet@....net>,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 3/8] Documentation: HID: hiddev editing & corrections
On Thu, 3 Dec 2020 22:20:17 -0800
Randy Dunlap <rdunlap@...radead.org> 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@...radead.org>
> Cc: Jiri Kosina <jikos@...nel.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@...hat.com>
> Cc: linux-input@...r.kernel.org
> Cc: Jonathan Corbet <corbet@....net>
> Cc: linux-doc@...r.kernel.org
> ---
> 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
Powered by blists - more mailing lists