[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.
