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
The scale should always be set to 1.0 by default, and only ever be
overridden if we could successfully read it from sysfs, and ch_present
is obviously false until we've found the channel in question.
Check whether we managed to open the index file instead of crashing.
#0 0x00007f31843660c7 in __vfscanf_internal () at /lib64/libc.so.6
#1 0x00007f31843657ed in __isoc99_fscanf () at /lib64/libc.so.6
#2 0x0000560bfd6b942b in build_channel_array (counter=0x560bfdea01c8, device_dir=0x560bfde90810 "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:273F:1008.0044/HID-SENSOR-200041.2.auto/iio:device0")
at iio-buffer-utils.c:320
#3 0x0000560bfd6b942b in build_channels (data=0x560bfdea01b0) at iio-buffer-utils.c:739
(gdb) frame 2
#2 0x0000560bfd6b942b in build_channel_array (counter=0x560bfdea01c8, device_dir=0x560bfde90810 "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:273F:1008.0044/HID-SENSOR-200041.2.auto/iio:device0")
at iio-buffer-utils.c:320
320 fscanf (sysfsfp, "%u", ¤t->index);
(gdb) p sysfsfp
$1 = (FILE *) 0x0
It was useful when we only had a couple of entries, but it's rather
pointless now that pretty much all the systems should work, and the ones
that don't should be listed in open issues on GitHub.
If we don't have an ACCEL_MOUNT_MATRIX property for this device,
then check if there is a mount matrix available in sysfs.
Some kernel drivers export the mount matrix there, e.g. st_accel.
This fixes an issue where the screen was automatically rotated to
an incorrect orientation on Acer Veriton Z4660G/Z6860G/A890.
