^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Care and feeding of your Human Interface Devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) In addition to the normal input type HID devices, USB also uses the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) human interface device protocols for things that are not really human
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) interfaces, but have similar sorts of communication needs. The two big
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) examples for this are power devices (especially uninterruptable power
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) supplies) and monitor control on higher end monitors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) To support these disparate requirements, the Linux USB system provides
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) HID events to two separate interfaces:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) * the input subsystem, which converts HID events into normal input
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) device interfaces (such as keyboard, mouse and joystick) and a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) normalised event interface - see Documentation/input/input.rst
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) * the hiddev interface, which provides fairly raw HID events
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) The data flow for a HID event produced by a device is something like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) the following::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) usb.c ---> hid-core.c ----> hid-input.c ----> [keyboard/mouse/joystick/event]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) --> hiddev.c ----> POWER / MONITOR CONTROL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) In addition, other subsystems (apart from USB) can potentially feed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) events into the input subsystem, but these have no effect on the hid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) device interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) Using the HID Device Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) The hiddev interface is a char interface using the normal USB major,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) with the minor numbers starting at 96 and finishing at 111. Therefore,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) you need the following commands::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) mknod /dev/usb/hiddev0 c 180 96
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) mknod /dev/usb/hiddev1 c 180 97
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) mknod /dev/usb/hiddev2 c 180 98
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) mknod /dev/usb/hiddev3 c 180 99
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) mknod /dev/usb/hiddev4 c 180 100
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) mknod /dev/usb/hiddev5 c 180 101
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) mknod /dev/usb/hiddev6 c 180 102
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) mknod /dev/usb/hiddev7 c 180 103
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) mknod /dev/usb/hiddev8 c 180 104
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) mknod /dev/usb/hiddev9 c 180 105
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) mknod /dev/usb/hiddev10 c 180 106
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) mknod /dev/usb/hiddev11 c 180 107
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) mknod /dev/usb/hiddev12 c 180 108
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) mknod /dev/usb/hiddev13 c 180 109
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) mknod /dev/usb/hiddev14 c 180 110
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) mknod /dev/usb/hiddev15 c 180 111
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) So you point your hiddev compliant user-space program at the correct
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) interface for your device, and it all just works.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) Assuming that you have a hiddev compliant user-space program, of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) course. If you need to write one, read on.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) The HIDDEV API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) This description should be read in conjunction with the HID
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) specification, freely available from https://www.usb.org, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) conveniently linked of http://www.linux-usb.org.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) The hiddev API uses a read() interface, and a set of ioctl() calls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) HID devices exchange data with the host computer using data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) bundles called "reports". Each report is divided into "fields",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) each of which can have one or more "usages". In the hid-core,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) each one of these usages has a single signed 32 bit value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) read():
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) -------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) This is the event interface. When the HID device's state changes,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) it performs an interrupt transfer containing a report which contains
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) the changed value. The hid-core.c module parses the report, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) returns to hiddev.c the individual usages that have changed within
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) the report. In its basic mode, the hiddev will make these individual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) usage changes available to the reader using a struct hiddev_event::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) struct hiddev_event {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) unsigned hid;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) signed int value;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) containing the HID usage identifier for the status that changed, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) the value that it was changed to. Note that the structure is defined
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) within <linux/hiddev.h>, along with some other useful #defines and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) structures. The HID usage identifier is a composite of the HID usage
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) page shifted to the 16 high order bits ORed with the usage code. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) behavior of the read() function can be modified using the HIDIOCSFLAG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) ioctl() described below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) ioctl():
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) --------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) This is the control interface. There are a number of controls:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) HIDIOCGVERSION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) - int (read)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) Gets the version code out of the hiddev driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) HIDIOCAPPLICATION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) - (none)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) This ioctl call returns the HID application usage associated with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) hid device. The third argument to ioctl() specifies which application
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) index to get. This is useful when the device has more than one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) application collection. If the index is invalid (greater or equal to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) the number of application collections this device has) the ioctl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) returns -1. You can find out beforehand how many application
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) collections the device has from the num_applications field from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) hiddev_devinfo structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) HIDIOCGCOLLECTIONINFO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) - struct hiddev_collection_info (read/write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) This returns a superset of the information above, providing not only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) application collections, but all the collections the device has. It
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) also returns the level the collection lives in the hierarchy.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) The user passes in a hiddev_collection_info struct with the index
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) field set to the index that should be returned. The ioctl fills in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) the other fields. If the index is larger than the last collection
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) index, the ioctl returns -1 and sets errno to -EINVAL.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) HIDIOCGDEVINFO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) - struct hiddev_devinfo (read)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) Gets a hiddev_devinfo structure which describes the device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) HIDIOCGSTRING
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) - struct hiddev_string_descriptor (read/write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Gets a string descriptor from the device. The caller must fill in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) "index" field to indicate which descriptor should be returned.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) HIDIOCINITREPORT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) - (none)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) Instructs the kernel to retrieve all input and feature report values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) from the device. At this point, all the usage structures will contain
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) current values for the device, and will maintain it as the device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) changes. Note that the use of this ioctl is unnecessary in general,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) since later kernels automatically initialize the reports from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) device at attach time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) HIDIOCGNAME
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) - string (variable length)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) Gets the device name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) HIDIOCGREPORT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) - struct hiddev_report_info (write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) Instructs the kernel to get a feature or input report from the device,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) in order to selectively update the usage structures (in contrast to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) INITREPORT).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) HIDIOCSREPORT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) - struct hiddev_report_info (write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) Instructs the kernel to send a report to the device. This report can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) be filled in by the user through HIDIOCSUSAGE calls (below) to fill in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) individual usage values in the report before sending the report in full
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) to the device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) HIDIOCGREPORTINFO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) - struct hiddev_report_info (read/write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) Fills in a hiddev_report_info structure for the user. The report is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) looked up by type (input, output or feature) and id, so these fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) must be filled in by the user. The ID can be absolute -- the actual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) report id as reported by the device -- or relative --
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) HID_REPORT_ID_FIRST for the first report, and (HID_REPORT_ID_NEXT |
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) report_id) for the next report after report_id. Without a-priori
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) information about report ids, the right way to use this ioctl is to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) use the relative IDs above to enumerate the valid IDs. The ioctl
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) returns non-zero when there is no more next ID. The real report ID is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) filled into the returned hiddev_report_info structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) HIDIOCGFIELDINFO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) - struct hiddev_field_info (read/write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) Returns the field information associated with a report in a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) hiddev_field_info structure. The user must fill in report_id and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) report_type in this structure, as above. The field_index should also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) be filled in, which should be a number from 0 and maxfield-1, as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) returned from a previous HIDIOCGREPORTINFO call.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) HIDIOCGUCODE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) - struct hiddev_usage_ref (read/write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) Returns the usage_code in a hiddev_usage_ref structure, given that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) given its report type, report id, field index, and index within the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) field have already been filled into the structure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) HIDIOCGUSAGE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) - struct hiddev_usage_ref (read/write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) Returns the value of a usage in a hiddev_usage_ref structure. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) usage to be retrieved can be specified as above, or the user can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) choose to fill in the report_type field and specify the report_id as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) HID_REPORT_ID_UNKNOWN. In this case, the hiddev_usage_ref will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) filled in with the report and field information associated with this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) usage if it is found.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) HIDIOCSUSAGE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) - struct hiddev_usage_ref (write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) Sets the value of a usage in an output report. The user fills in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) the hiddev_usage_ref structure as above, but additionally fills in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) the value field.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) HIDIOGCOLLECTIONINDEX
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) - struct hiddev_usage_ref (write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) Returns the collection index associated with this usage. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) indicates where in the collection hierarchy this usage sits.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) HIDIOCGFLAG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) - int (read)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) HIDIOCSFLAG
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) - int (write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) These operations respectively inspect and replace the mode flags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) that influence the read() call above. The flags are as follows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) HIDDEV_FLAG_UREF
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) - read() calls will now return
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) struct hiddev_usage_ref instead of struct hiddev_event.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) This is a larger structure, but in situations where the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) device has more than one usage in its reports with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) same usage code, this mode serves to resolve such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) ambiguity.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) HIDDEV_FLAG_REPORT
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) - This flag can only be used in conjunction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) with HIDDEV_FLAG_UREF. With this flag set, when the device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) sends a report, a struct hiddev_usage_ref will be returned
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) to read() filled in with the report_type and report_id, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) with field_index set to FIELD_INDEX_NONE. This serves as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) additional notification when the device has sent a report.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags