[available] ; Availability of some sensors can be defined in hw-settings configuration ; files. By enabling ssu-sysinfo usage, sensorfwd configuration can be ; written so that it just refers to hw-settings config. If ssu-sysinfo ; is not used, these will default to "True". ; ; In case of virtual sensors can be implemented on top of multiple real ; sensors, multiple '|' separated features can be given and the sensor ; is enabled if at least one of those is set in hw-settings. accelerometersensor=Feature_AccelerationSensor alssensor=Feature_LightSensor compasssensor=Feature_CompassSensor gyroscopesensor=Feature_GyroSensor orientationsensor=Feature_GyroSensor|Feature_AccelerationSensor proximitysensor=Feature_ProximitySensor ; In theory having Feature_CoverSensor == have lidsensor. However ; in practice only mce is expected to track lidsensor and atm it ; does it via suspend proofed evdev inputs rather than sensorfwd. ; So, even if the lidsensor adaptors provided by sensorfwd would ; work, they might interfere with the only user of the sensor. ; lidsensor=Feature_CoverSensor lidsensor=False ; Some sensors that are in theory supported by sensorfwd do not have ; a suitable hybris adaptors, and thus it makes no sense to list them ; as being available regardless of the hw / android hal status. tapsensor=False temperaturesensor=False ; Sensors that have not been available in any officially supported ; devices -> hide by default. humiditysensor=False stepcountersensor=False ; To minimize chances of regression, sensors that have been available at ; least in one officially supported device -> do not hide by default. ; (sensor loading should fail, so false positive should cause only ; cosmetic issues on 1st use after bootup) magnetometersensor=True pressuresensor=True rotationsensor=True ; To avoid revisiting config files for all old ports in the future, the ; defaults for added sensors should be set "False" by default here, and ; to "True" in device specific override config as appropriate.