Lines Matching refs:the
5 In addition to the normal input type HID devices, USB also uses the
11 To support these disparate requirements, the Linux USB system provides
13 * the input subsystem, which converts HID events into normal input
16 * the hiddev interface, which provides fairly raw HID events
19 the following :
27 events into the input subsystem, but these have no effect on the hid
32 The hiddev interface is a char interface using the normal USB major,
33 with the minor numbers starting at 96 and finishing at 111. Therefore,
34 you need the following commands:
52 So you point your hiddev compliant user-space program at the correct
60 This description should be read in conjunction with the HID
66 HID devices exchange data with the host computer using data
68 each of which can have one or more "usages". In the hid-core,
72 This is the event interface. When the HID device's state changes,
74 the changed value. The hid-core.c module parses the report, and
75 returns to hiddev.c the individual usages that have changed within
76 the report. In its basic mode, the hiddev will make these individual
77 usage changes available to the reader using a struct hiddev_event:
84 containing the HID usage identifier for the status that changed, and
85 the value that it was changed to. Note that the structure is defined
87 structures. The HID usage identifier is a composite of the HID usage
88 page shifted to the 16 high order bits ORed with the usage code. The
89 behavior of the read() function can be modified using the HIDIOCSFLAG
94 This is the control interface. There are a number of controls:
97 Gets the version code out of the hiddev driver.
100 This ioctl call returns the HID application usage associated with the
102 index to get. This is useful when the device has more than one
103 application collection. If the index is invalid (greater or equal to
104 the number of application collections this device has) the ioctl
106 collections the device has from the num_applications field from the
110 This returns a superset of the information above, providing not only
111 application collections, but all the collections the device has. It
112 also returns the level the collection lives in the hierarchy.
113 The user passes in a hiddev_collection_info struct with the index
114 field set to the index that should be returned. The ioctl fills in
115 the other fields. If the index is larger than the last collection
116 index, the ioctl returns -1 and sets errno to -EINVAL.
119 Gets a hiddev_devinfo structure which describes the device.
122 Gets a string descriptor from the device. The caller must fill in the
126 Instructs the kernel to retrieve all input and feature report values
127 from the device. At this point, all the usage structures will contain
128 current values for the device, and will maintain it as the device
129 changes. Note that the use of this ioctl is unnecessary in general,
130 since later kernels automatically initialize the reports from the
134 Gets the device name
137 Instructs the kernel to get a feature or input report from the device,
138 in order to selectively update the usage structures (in contrast to
142 Instructs the kernel to send a report to the device. This report can
143 be filled in by the user through HIDIOCSUSAGE calls (below) to fill in
144 individual usage values in the report before sending the report in full
145 to the device.
148 Fills in a hiddev_report_info structure for the user. The report is
150 must be filled in by the user. The ID can be absolute -- the actual
151 report id as reported by the device -- or relative --
152 HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT |
153 report_id) for the next report after report_id. Without a-priori
154 information about report ids, the right way to use this ioctl is to
155 use the relative IDs above to enumerate the valid IDs. The ioctl
157 filled into the returned hiddev_report_info structure.
160 Returns the field information associated with a report in a
167 Returns the usage_code in a hiddev_usage_ref structure, given that
168 given its report type, report id, field index, and index within the
169 field have already been filled into the structure.
172 Returns the value of a usage in a hiddev_usage_ref structure. The
173 usage to be retrieved can be specified as above, or the user can
174 choose to fill in the report_type field and specify the report_id as
175 HID_REPORT_ID_UNKNOWN. In this case, the hiddev_usage_ref will be
176 filled in with the report and field information associated with this
180 Sets the value of a usage in an output report. The user fills in
181 the hiddev_usage_ref structure as above, but additionally fills in
182 the value field.
185 Returns the collection index associated with this usage. This
186 indicates where in the collection hierarchy this usage sits.
190 These operations respectively inspect and replace the mode flags
191 that influence the read() call above. The flags are as follows:
195 This is a larger structure, but in situations where the
196 device has more than one usage in its reports with the
201 with HIDDEV_FLAG_UREF. With this flag set, when the device
203 to read() filled in with the report_type and report_id, but
205 additional notification when the device has sent a report.