^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) HID Sensors Framework
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) HID sensor framework provides necessary interfaces to implement sensor drivers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) which are connected to a sensor hub. The sensor hub is a HID device and it provides
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) a report descriptor conforming to HID 1.12 sensor usage tables.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Description from the HID 1.12 "HID Sensor Usages" specification:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) "Standardization of HID usages for sensors would allow (but not require) sensor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) hardware vendors to provide a consistent Plug And Play interface at the USB boundary,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) thereby enabling some operating systems to incorporate common device drivers that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) could be reused between vendors, alleviating any need for the vendors to provide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) the drivers themselves."
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) This specification describes many usage IDs, which describe the type of sensor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) and also the individual data fields. Each sensor can have variable number of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) data fields. The length and order is specified in the report descriptor. For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) example a part of report descriptor can look like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) INPUT(1)[INPUT]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) ..
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Field(2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) Physical(0020.0073)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Usage(1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) 0020.045f
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) Logical Minimum(-32767)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) Logical Maximum(32767)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) Report Size(8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Report Count(1)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) Report Offset(16)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) Flags(Variable Absolute)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) ..
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) ..
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) The report is indicating "sensor page (0x20)" contains an accelerometer-3D (0x73).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) This accelerometer-3D has some fields. Here for example field 2 is motion intensity
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) (0x045f) with a logical minimum value of -32767 and logical maximum of 32767. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) order of fields and length of each field is important as the input event raw
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) data will use this format.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) Implementation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) This specification defines many different types of sensors with different sets of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) data fields. It is difficult to have a common input event to user space applications,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) for different sensors. For example an accelerometer can send X,Y and Z data, whereas
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) an ambient light sensor can send illumination data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) So the implementation has two parts:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) - Core hid driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) - Individual sensor processing part (sensor drivers)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) Core driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) -----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) The core driver registers (hid-sensor-hub) registers as a HID driver. It parses
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) report descriptors and identifies all the sensors present. It adds an MFD device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) with name HID-SENSOR-xxxx (where xxxx is usage id from the specification).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) For example:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) HID-SENSOR-200073 is registered for an Accelerometer 3D driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) So if any driver with this name is inserted, then the probe routine for that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) function will be called. So an accelerometer processing driver can register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) with this name and will be probed if there is an accelerometer-3D detected.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) The core driver provides a set of APIs which can be used by the processing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) drivers to register and get events for that usage id. Also it provides parsing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) functions, which get and set each input/feature/output report.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) Individual sensor processing part (sensor drivers)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) --------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) The processing driver will use an interface provided by the core driver to parse
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) the report and get the indexes of the fields and also can get events. This driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) can use IIO interface to use the standard ABI defined for a type of sensor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) Core driver Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) Callback structure::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) Each processing driver can use this structure to set some callbacks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) int (*suspend)(..): Callback when HID suspend is received
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) int (*resume)(..): Callback when HID resume is received
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) int (*capture_sample)(..): Capture a sample for one of its data fields
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) int (*send_event)(..): One complete event is received which can have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) multiple data fields.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) Registration functions::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) int sensor_hub_register_callback(struct hid_sensor_hub_device *hsdev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) u32 usage_id,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) struct hid_sensor_hub_callbacks *usage_callback):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) Registers callbacks for an usage id. The callback functions are not allowed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) to sleep::
^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) int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) u32 usage_id):
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) Removes callbacks for an usage id.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) Parsing function::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) u8 type,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) u32 usage_id, u32 attr_usage_id,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) struct hid_sensor_hub_attribute_info *info);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) A processing driver can look for some field of interest and check if it exists
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) in a report descriptor. If it exists it will store necessary information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) so that fields can be set or get individually.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) These indexes avoid searching every time and getting field index to get or set.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) Set Feature report::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) u32 field_index, s32 value);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) This interface is used to set a value for a field in feature report. For example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) if there is a field report_interval, which is parsed by a call to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) sensor_hub_input_get_attribute_info before, then it can directly set that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) individual field::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) u32 field_index, s32 *value);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) This interface is used to get a value for a field in input report. For example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) if there is a field report_interval, which is parsed by a call to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) sensor_hub_input_get_attribute_info before, then it can directly get that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) individual field value::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) u32 usage_id,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) u32 attr_usage_id, u32 report_id);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) This is used to get a particular field value through input reports. For example
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) accelerometer wants to poll X axis value, then it can call this function with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) the usage id of X axis. HID sensors can provide events, so this is not necessary
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) to poll for any field. If there is some new sample, the core driver will call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) registered callback function to process the sample.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) HID Custom and generic Sensors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) ------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) HID Sensor specification defines two special sensor usage types. Since they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) don't represent a standard sensor, it is not possible to define using Linux IIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) type interfaces.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) The purpose of these sensors is to extend the functionality or provide a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) way to obfuscate the data being communicated by a sensor. Without knowing the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) mapping between the data and its encapsulated form, it is difficult for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) an application/driver to determine what data is being communicated by the sensor.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) This allows some differentiating use cases, where vendor can provide applications.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) Some common use cases are debug other sensors or to provide some events like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) keyboard attached/detached or lid open/close.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) To allow application to utilize these sensors, here they are exported uses sysfs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) attribute groups, attributes and misc device interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) An example of this representation on sysfs::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) /sys/devices/pci0000:00/INT33C2:00/i2c-0/i2c-INT33D1:00/0018:8086:09FA.0001/HID-SENSOR-2000e1.6.auto$ tree -R
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) .
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) │ ├── enable_sensor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) │ │ ├── feature-0-200316
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) │ │ │ ├── feature-0-200316-maximum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) │ │ │ ├── feature-0-200316-minimum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) │ │ │ ├── feature-0-200316-name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) │ │ │ ├── feature-0-200316-size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) │ │ │ ├── feature-0-200316-unit-expo
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) │ │ │ ├── feature-0-200316-units
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) │ │ │ ├── feature-0-200316-value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) │ │ ├── feature-1-200201
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) │ │ │ ├── feature-1-200201-maximum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) │ │ │ ├── feature-1-200201-minimum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) │ │ │ ├── feature-1-200201-name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) │ │ │ ├── feature-1-200201-size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) │ │ │ ├── feature-1-200201-unit-expo
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) │ │ │ ├── feature-1-200201-units
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) │ │ │ ├── feature-1-200201-value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) │ │ ├── input-0-200201
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) │ │ │ ├── input-0-200201-maximum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) │ │ │ ├── input-0-200201-minimum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) │ │ │ ├── input-0-200201-name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) │ │ │ ├── input-0-200201-size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) │ │ │ ├── input-0-200201-unit-expo
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) │ │ │ ├── input-0-200201-units
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) │ │ │ ├── input-0-200201-value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) │ │ ├── input-1-200202
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) │ │ │ ├── input-1-200202-maximum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) │ │ │ ├── input-1-200202-minimum
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) │ │ │ ├── input-1-200202-name
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) │ │ │ ├── input-1-200202-size
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) │ │ │ ├── input-1-200202-unit-expo
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) │ │ │ ├── input-1-200202-units
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) │ │ │ ├── input-1-200202-value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) Here there is a custom sensors with four fields, two feature and two inputs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Each field is represented by a set of attributes. All fields except the "value"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) are read only. The value field is a RW field.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) Example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) /sys/bus/platform/devices/HID-SENSOR-2000e1.6.auto/feature-0-200316$ grep -r . *
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) feature-0-200316-maximum:6
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) feature-0-200316-minimum:0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) feature-0-200316-name:property-reporting-state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) feature-0-200316-size:1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) feature-0-200316-unit-expo:0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) feature-0-200316-units:25
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) feature-0-200316-value:1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) How to enable such sensor?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) ^^^^^^^^^^^^^^^^^^^^^^^^^^
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) By default sensor can be power gated. To enable sysfs attribute "enable" can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) used::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) $ echo 1 > enable_sensor
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) Once enabled and powered on, sensor can report value using HID reports.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) These reports are pushed using misc device interface in a FIFO order::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) /dev$ tree | grep HID-SENSOR-2000e1.6.auto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) │ │ │ ├── 10:53 -> ../HID-SENSOR-2000e1.6.auto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) │ ├── HID-SENSOR-2000e1.6.auto
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) Each reports can be of variable length preceded by a header. This header
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) consist of a 32 bit usage id, 64 bit time stamp and 32 bit length field of raw
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) data.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags