Lines Matching +full:write +full:- +full:to +full:- +full:read
8 In addition to the normal input type HID devices, USB also uses the
14 To support these disparate requirements, the Linux USB system provides
15 HID events to two separate interfaces:
18 normalised event interface - see Documentation/input/input.rst
24 usb.c ---> hid-core.c ----> hid-input.c ----> [keyboard/mouse/joystick/event]
27 --> hiddev.c ----> POWER / MONITOR CONTROL
57 So you point your hiddev compliant user-space program at the correct
60 Assuming that you have a hiddev compliant user-space program, of
61 course. If you need to write one, read on.
67 This description should be read in conjunction with the HID
69 conveniently linked of http://www.linux-usb.org.
71 The hiddev API uses a read() interface, and a set of ioctl() calls.
75 each of which can have one or more "usages". In the hid-core,
76 each one of these usages has a single signed 32-bit value.
78 read():
79 -------
83 the changed value. The hid-core.c module parses the report, and
84 returns to hiddev.c the individual usages that have changed within
86 usage changes available to the reader using a struct hiddev_event::
94 the value that it was changed to. Note that the structure is defined
97 page shifted to the 16 high order bits ORed with the usage code. The
98 behavior of the read() function can be modified using the HIDIOCSFLAG
103 --------
108 - int (read)
113 - (none)
116 HID device. The third argument to ioctl() specifies which application
117 index to get. This is useful when the device has more than one
118 application collection. If the index is invalid (greater or equal to
120 returns -1. You can find out beforehand how many application
125 - struct hiddev_collection_info (read/write)
131 field set to the index that should be returned. The ioctl fills in
133 index, the ioctl returns -1 and sets errno to -EINVAL.
136 - struct hiddev_devinfo (read)
141 - struct hiddev_string_descriptor (read/write)
144 "index" field to indicate which descriptor should be returned.
147 - (none)
149 Instructs the kernel to retrieve all input and feature report values
157 - string (variable length)
162 - struct hiddev_report_info (write)
164 Instructs the kernel to get a feature or input report from the device,
165 in order to selectively update the usage structures (in contrast to
169 - struct hiddev_report_info (write)
171 Instructs the kernel to send a report to the device. This report can
172 be filled in by the user through HIDIOCSUSAGE calls (below) to fill in
174 to the device.
177 - struct hiddev_report_info (read/write)
181 must be filled in by the user. The ID can be absolute -- the actual
182 report id as reported by the device -- or relative --
185 information about report ids, the right way to use this ioctl is to
186 use the relative IDs above to enumerate the valid IDs. The ioctl
187 returns non-zero when there is no more next ID. The real report ID is
191 - struct hiddev_field_info (read/write)
196 be filled in, which should be a number from 0 and maxfield-1, as
200 - struct hiddev_usage_ref (read/write)
207 - struct hiddev_usage_ref (read/write)
210 usage to be retrieved can be specified as above, or the user can
211 choose to fill in the report_type field and specify the report_id as
217 - struct hiddev_usage_ref (write)
224 - struct hiddev_usage_ref (write)
230 - int (read)
232 - int (write)
235 that influence the read() call above. The flags are as follows:
238 - read() calls will now return
242 same usage code, this mode serves to resolve such
246 - This flag can only be used in conjunction
249 to read() filled in with the report_type and report_id, but
250 with field_index set to FIELD_INDEX_NONE. This serves as