On Wed, Jul 13, 2022 at 5:49 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > On Tue, 28 Jun 2022 14:33:09 +0200 > Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > > [1]: > > > https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/Documentation/ABI/testing/sysfs-bus-iio#n1838 > > > An implementor might consider that for a hand-held device, a > > > 'natural' orientation would be 'front facing camera at the top'. > > > The main hardware reference frame could then be described as : > > > * Y is in the plane of the screen and is positive towards the > > > top of the screen ; > > > * X is in the plane of the screen, perpendicular to Y axis, and > > > positive towards the right hand side of the screen ; > > > * Z is perpendicular to the screen plane and positive out of the > > > screen. > > > > Note though that this does not clearly define what > > e.g. "positive towards the top of the screen" means if > > you look at the axis illustrations in both the Windows, > > Android and W3C docs they all have an arrow pointing > > towards the top of the screen for the Y axis, which > > matches the "positive towards the top of the screen" > > wording. > > > > Yet Android / W3C expect a positive reading when > > the G force vector is pointing down. Which I still > > find confusing. > > > > This means that we to add a text similar to the Windows > > docs here, say something like (made up by me not copy > > pasted from Windows docs): > > > > "The Z-axis reading will be -1G when a device is laying > > flat on a table with its display facing up" > > > > To fix the are we measuring gravity or force countering > > gravity confusion. > > > > Jonathan, shall I submit a patch to add this, maybe with > > some extra text that we are following the Windows/HID > > convention and that Android/W3C do things differently? > > I'm not going to rush this through late in a cycle. > So propose a text update and let's carry on the discussion > around that. (you may already have done so - I'm way behind!) > > Given we have a bunch of mount matrices that aren't rotation > matrices out in the wild, we probably want to cover that as > well, potentially by relaxing the definition to allow > rotoinversions, or at least state they are out there even if > we actively discourage them going forwards. > > Also, I just remembered Linus w wrote the docs in the first > place and there was a long discussion at the time so +CC I recently discussed the mount matrix bindings WRT magnetometers with Jakob Hauser who has made a deep analysis of that subject. The TL;DR is that it turns out that also magnetometers are device-oriented, and thus breaking most of the paradigms used by people like geophysicists. However for the "sensor fusion" usecase for a phone/tablet device is makes perfect sense since e.g. projecting the magnetic line onto the plane of the screen so you can create a compass application the linear algebra becomes more intuitive with everything expressed in device-relative terms. (Some rambiling here: https://wiki.postmarketos.org/wiki/Magnetometer) This is a bit unlucky given that IIO as a whole is probably more ambitious and not just appealing to consumer devices... but now we are stuck with this and the geophysicists will perpetually shake their head as they align their new Linux-driven magnetometer, encapsulated in concrete and mounted in the bedrock to be perfectly perpendicular to earths surface. Maybe when the physicists come around we can add some isometric-mount-matrix = ... as alternative? Please include Jakob on subsequent patches I am sure we can hash this out for all sensors. Yours, Linus Walleij
