[Gta04-owner] Second trial with QtMoko2 - accelerometer orientation GTA04A4 vs. A5

[H. Nikolaus Schaller]

Hi,
I have added a description to the subject since we tend to use the same for everything :)

> Am 05.04.2018 um 20:24 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> On Thu, 5 Apr 2018 18:44:59 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi Sven,
>> 
>>> Am 05.04.2018 um 18:05 schrieb Sven Dyroff <S.Dyroff at phytec.de>:
>>> 
>>> Hello Nikolaus,
>>> 
>>>> I have now booted my GTA04A4 and the orientation is completely correct.
>>>> Hm. Maybe a subtle difference between GTA04A4 and A5? They use different accelerometer chips.
>>> 
>>> something like that is what I already assumed. Would have wondered me if some scaling factors would have gone lost by just rebuilding QtMoko...
>>> 
>>> The bad news of this is, that I guess it will perhaps not be quite easy to get the used behaviour from the GTA04A4 reproduced on the GTA04A5 again.
>> 
>> Well, it is the task of the kernel to properly abstract from hardware differences and provide the same values to the user space.
>> 
>> This seems not yet to be covered by our kernel driver patch set.
>> 
> I would rather guess here that userspace just does not use that
> information. But I will have to do research.

I have now tried the GTA04A5 with 4.15.15 kernel and indeed the y axis is swapped.

IMHO this is not possible to solve in either kernel or user-space without additional
information about how the sensor is mounted on the PCB!

> 
> If there is such thing  only missing in our bridge,

No it is not missing in the bridge, it is already missing in the iio accelerometer
drivers... The bridge just translates what iio delivers.

Probably the iio accel interface provides raw orientation data and not normalized
to how the chips are placed.

And even worse: every chip vendor may have their own definition of polarity of X/Y/Z
so two chips at the same place and XYZ orientation may still flip coordinates.

If we look into the bindings, none of them seems to define a device orientation property:

https://elixir.bootlin.com/linux/v4.16/source/Documentation/devicetree/bindings/iio/accel

Our bridge could try to fix that. But it is "transparent" in the sense that it has no DT
record on its own.

We only could make it scan for additional (otherwise ignored) DT properties of the
iio device and handle that.

> we
> need to do some work anyways and I would
> a) if bridge stuff has upstreaming chances, and it is easy to fix
> there, then maybe it is a good idea to fix it there.
> b) if not, I would rather try to switch to iio. At least there is a clean interface.
> We already have some iio scanning code for the pressure measurement, so
> we can share some code.

Yes, but switching to iio does not solve this problem...

The problem is either when kernel reads the chip registers or when qtmoko passes
the values it did receive (independently of iio or input-event) to user-space
it should negate one axis for the GTA04A5 and not for GTA04A3/A4.

We could of course check /proc/devicetree/model for A34 vs. A5 but that is not
really a nice solution.

In other words: we need a device dependent transformation of chip register values
to AccelHandle* data.

Should really start parsing DT from user-space?

> 
> At the moment my machine is building qte...
> 
>>> 
>>>> there is even a short rumble if the ball hits the walls :) Nice.
>>> 
>>> Yes, it's also a demonstration for the buzzer.
>>> 
>>> You never tried that little but lovely game before?
>> 
>> Probably once or twice since Neo Freerunner came out...
>> That is too long ago to remember.
>> 
>> You know I am designing hardware for gaming devices (e.g. Pyra handheld).
>> This alone (incl. kernel hacking) is more than enough Adventure Game :)
>> 
>> If you would ask me:
>> * did you play "CAD" recently?
>> * did you play "upstream to kernel.org" recently?
>> * did you play "bug hunting" recently?
>> * did you play "EOL component" recently?
> 
> * did you play "components out of stock" recently?

And fight against "50 weeks delivery time" :(

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20180406/9969f969/attachment-0001.asc>