[systemd-devel] accelerometer mount-matrix quirks

[Bastien Nocera]

On Tue, 2016-11-22 at 23:43 +0100, Thomas H.P. Andersen wrote:
> 
> 
> On Tue, Nov 22, 2016 at 5:26 PM, Bastien Nocera <hadess at hadess.net>
> wrote:
> > On Tue, 2016-11-22 at 17:23 +0100, Lennart Poettering wrote:
> > > On Tue, 22.11.16 12:13, Bastien Nocera (hadess at hadess.net) wrote:
> > >
> > > > Hey,
> > > >
> > > > 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
> > > > or
> > > > iio-sensor-proxy.
> > > >
> > > > Opinions?
> > >
> > > If it's generic enough then the hwdb is definitely a good place
> > for
> > > things like that. If the concept however only has value for
> > > iio-sensor-proxy specifically then it should probably live in
> > that
> > > package. Of course the lines are blurry there, so compare with
> > the
> > > input case: hwdb carries dpi quirk data for all kinds of mice,
> > and if
> > > this 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.

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