Add support for per-axis accel scaling as required for older
accelerometers:
"
It used to be hard to have the same range out of the plane of the silicon
than within it, so was common to have sensors with different ranges and
hence scales in z direction from x and y.
"
Fetch the scale for each axis from sysfs for polling accelerometers.
Use AccelScale, which supports per-axis accelerometer scaling everywhere
we would have had a single scale value.
This adds per-axis support from the ring-buffer for accelerometers
with triggers.
Don't overwrite an already set type for light and ambient to support
multi channel sensors.
This reverts commit 5ef75b57a988a8a6acc2611cde760f28fc7b48d6.
The levels are sensor dependend and are also affected by how the sensor
is built into the device (e.g. the distance to the cover glass).
Android even does this in sensor specific code. Android x86 works
around this by using setprop:
https://groups.google.com/forum/#!topic/android-x86/RFXYW5MNCuk
Linux kernel IIO drivers provide mount matrix via standardized sysfs
interface. The IIO mount matrix could specified by "directory" and by
"type", this patch adds support for the "by type" option which is used
by drivers that use individual matrices for each of the sensors. Tested
on Nexus 7 and Acer A500 tablet devices using MPU6050 and KXTF9 IIO drivers
respectively, now monitor-sensor reports display's orientation correctly
on these devices.
Linux kernel IIO drivers provide mount matrix via standardized sysfs
interface. The IIO mount matrix could specified by "directory" and by
"type", this patch adds support for the "directory" type which may be
used by drivers that use the same shared matrix for all of the sensors
or if driver provides only one accelerometer sensor at all.
That would be used in the tsl2772 and lm3533 kernel drivers, as well as
devices with multiple channels, such as combined proximity and light
sensors, which use "illuminance0" as the channel name instead of
"illuminance".
Closes: #290
Properties with the IIO_SHARED_BY_ALL mask don't have the sensor type prefix
before the filename, causing some devices to not have a scale set from sysfs.
Fix this by searching through sysfs for both properties name: scale and
in_accel_scale.
Tested on: Cyan (Acer Chromebook R11, with 2 accelerometers)
Affects: All chromebooks with cros-ec sensors
https://github.com/torvalds/linux/tree/master/drivers/iio/common/cros_ec_sensors
The old code gave a priority to portrait orientation, so that if
rotation reached the portrait threshold, it switched straight away.
This is problematic if the device you're dealing with isn't a mostly
portrait phone, but a tablet that can be used in both orientations
equally.
Landscape thresholds and portrait thresholds can (and they do) overlap.
In the overlapping area we should try to keep the previous orientation
until that threshold has passed.
[Bastien Nocera: Added test change]
All devices with "Chromium embedded controllers have their display
sensor location set as "lid" and that sensor location is only
available through sysfs.
Prior to this commit, chromebooks with two accelerometers had their
base sensor being used as display.
See: f678d6da74/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c (L137)Closes: #278
On some machines, iio-sensor-proxy was returning all 0's for IIO sensor
values. It turns out that the bits_used for this sensor is 32, which makes
the mask calculation:
*mask = (1 << 32) - 1;
If the compiler interprets the 1 literals as 32-bit ints, it generates
undefined behavior depending on compiler version and optimization level.
On my system, it optimizes out the shift, so the mask value becomes
*mask = (1) - 1;
With a mask value of 0, iio-sensor-proxy will always return 0 for every axis.
Avoid incorrect 0 values caused by compiler optimization.
Closes: #270
