Post by Thomas H.P. AndersenPost by Bastien NoceraPost by Lennart PoetteringPost by Bastien NoceraHey,
I'm adding support for reading the mount-matrix[1] from
accelerometer
devices in iio-sensor-proxy, but we'll need to add a way to override
the mount-matrix in case the data from the device-tree is incorrect, or
missing[2].
I was wondering whether we should ship the hwdb quirks in
systemd
Post by Lennart PoetteringPost by Bastien Noceraor
iio-sensor-proxy.
Opinions?
If it's generic enough then the hwdb is definitely a good place
for
Post by Lennart Poetteringthings like that. If the concept however only has value for
iio-sensor-proxy specifically then it should probably live in
that
Post by Lennart Poetteringpackage. Of course the lines are blurry there, so compare with
the
Post by Lennart Poetteringinput case: hwdb carries dpi quirk data for all kinds of mice,
and if
Post by Lennart Poetteringthis data is like that, then it fits in.
The quirks apply to the devices, and are in the same format as what's
offered by the kernel when the firmware provides it, so it's not iio-
sensor-proxy specific in any way. If we were to replace iio-sensor-
proxy, we'd still use this metadata.
I'll send a patch in as soon as I've done testing on a machine that
does need this quirking.
Hi Bastien,
I recently opened a PR to iio-sensor-proxy with a quirk for my
laptop.
I know, and that's what restarted the discussion I had a couple of
months back with Hans about applying the mount-matrix ;)
He also has a machine on which he could test it.
Post by Thomas H.P. AndersenSince this is my main computer testing is easy. Let me know if I can help.
If you want to give a try to sending a patch with a new "70-
accelerometer.hwdb" file, something along the lines of:
# Documentation[1]
iio:b0003v1111p0000*
ACCEL_MOUNT_MATRIX="1, 0, 0; 0, 1, 0; 0, 0, 1"
Which matches your device, and which you can retrieve in
iio_buffer_accel_open() in src/drv-iio-buffer-accel.c
Would save me quite some time, as I currently can't fully test the
patch.
Would be great if you could also attach the output of the DSDT for that
machine, to see whether that mount-matrix is already in there in some
form, and we're just not parsing it. We'd need to make a note if in the
hwdb that we should remove that quirk when the DSDT is parsed kernel-
side.
Cheers
[1]: This is what I have so far:
Accelerometer orientation
-------------------------
When the accelerometer is not mounted the same way as the screen, we need
to modify the readings from the accelerometer to make sure that the computed
orientation matches the screen one.
For this, we use a 3x3 matrix, as defined in the commit adding the [mount-matrix property](https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dfc57732ad38f93ae6232a3b4e64fd077383a0f1)
to IIO devices. This information is usually exported in:
- the device-tree for ARM devices
- the ACPI DSDT for Intel-compatible devices
The latter is currently [not parsed](http://marc.info/?l=linux-iio&m=147981183211362&w=2) as of kernel 4.9-rc5.
If there is no mount-matrix defined in the device-tree or ACPI DSDT, or
the data is incorrect, it can be overridden with a udev property, in the
`70-accelerometer.hwdb` file, for example:
```
iio:FIXME
ACCEL_MOUNT_MATRIX="1, 0, 0; 0, 1, 0; 0, 0, 1"
```
Note that some devices have the framebuffer rotation that changes between
the bootloader and the main system, which might mean that the accelerometer
is then wrongly oriented. This is a missing feature in the [i915 kernel driver](https://bugs.freedesktop.org/show_bug.cgi?id=94894)
which needs to be fixed, and won't require quirks.