Re: [PATCH] iio: document bindings for mounting matrixes

[Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>]

On 08/24/2016 11:29 PM, Jonathan Cameron wrote:

[snip...]

>>>> +
>>>> +The axes may also be flipped: for a screen you probably want (x) coordinates to
>>>> +go from negative on the left to positive on the right and (z) depth to be
>>>> +negative under the screen and positive in front of it, toward the face of the
>>>> +user.
>>> I'm not sure we don't want to define that it can't be flipped and enforce the
>>> correct coordinate system on the underlying drivers (fingers crossed they are
>>> currently all left or all right handed? - oops should have been keeping an eye on
>>> this).
>> As to coordinate system definition, multiple conventions seem to exist across
>> industries. For UAV, we use the one described here:
>> https://en.wikipedia.org/wiki/Flight_dynamics_(fixed-wing_aircraft)
>>
>> So I feel like we should keep away from any temptation to define the coordinates
>> system too strictly.
>> I also think of systems composed of multiple hardware parts with sensors
>> scattered all over them. What would be the right "device/main hardware" reference
>> frame definition in these cases ?
>> As this is product specific, I feel like "device/main hardware" reference frame
>> definition should be left to the "board/main hardware/device..." implementor's
>> choice.
> Flexible is good, but I think we should define a base rule for the chips frame
> of reference and fix up any that disagree (which is nasty ABI breakage :(
We might as well expose another property to userspace to indicate
coordinates system convention currently in use.
This seems overly complex to me but might ease portability across platforms
and products. I have no clear opinion on this.

Anyway, DT / BSP maintainer would always have the ability to customize
mounting matrix values on a per-product basis to fit their application
expectations.
E.g., from Parrot's UAVs perspective, flight control stack expects 
coordinates
system to be defined according to aeronautic convention (hardcoded).
Even if DT required a strict definition of coordinates system, this 
would implies
no changes to rotation matrix values currently set into our DTs...
> Trivial choice of either right handed or left handed frame might be all we
> define in general.  Useful to define consistent frames for device types that
> are common perhaps as well.  (such as the screen ones Linus has here).
It seems most common definition is what is described here:
https://www.w3.org/TR/2016/CR-orientation-event-20160818/
and here:
https://developer.android.com/guide/topics/sensors/sensors_overview.html#sensors-coords
given that Android devices represent a fair amount of phones and tablets 
in use.

Searched for IoT related things but no clear conventions came out...
And I can't think of PC world as a reference for this kind of stuff.

Yours,
Greg.