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 <andr...@kemnade.info>:
> Hi,
> On Thu, 5 Apr 2018 18:44:59 +0200
> "H. Nikolaus Schaller" <h...@goldelico.com> wrote:
>> Hi Sven,
>>> Am 05.04.2018 um 18:05 schrieb Sven Dyroff <s.dyr...@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 

IMHO this is not possible to solve in either kernel or user-space without 
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 
drivers... The bridge just translates what iio delivers.

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

And even worse: every chip vendor may have their own definition of polarity of 
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 


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 
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 
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" :(


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Gta04-owner mailing list

Reply via email to