OSDN Git Service
libsensors: Re-fix "non-streaming" state, provide for rate clamping
This has been fixed, rebroken and re-fixed several times now. Here's
the deal as I understand it: HID sensors are inherently
"non-streaming" in the Android sense. They are never guaranteed to
report events at a fixed rate (the IIO sampling_frequency property is
a command to the sensor hub which is doing filtering; some hubs send
fixed rate events, some don't). The Android API documentation
specifies that this should be signaled by setting the minDelay of the
sensor_t to zero.
But if you do this, then the framework and apps don't know what values
are valid and will attempt to set improbabable values (e.g. 1000Hz).
Sadly the IIO driver will eject those settings instead of clamping
them to a valid range, and the result is that the sensors retain their
default values (e.g. 5Hz for compass in the linked Jira) and look very
slow.
So implement rate clamping in SensorIIODev: subclasses can set their
own minimum delay values to which the HAL will clamp before being sent
the the hardware. These are populated currently with values specific
to (and empirically determined from) the Intel sensor hub on the
Harris Beach Ultrabook. Future work will need to make this settable
via configuration.
Issue: AXIA-3287
Change-Id: I63b3d531ec3fadba4dbee17cff68681c9ad1b510
Signed-off-by: Andy Ross <andy.ross@windriver.com>
Reviewed-on: https://otc-android.intel.com/gerrit/22148
Reviewed-by: Radivoje Jovanovic <radivoje.jovanovic@intel.com>
Reviewed-by: Daniel Leung <daniel.leung@intel.com>
Reviewed-by: Russell Webb <russell.webb@intel.com>
Tested-by: jenkins autobuilder