linux-kernel - Re: [Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D4F87479-4FF7-4DBC-81D5-1BA836D2C889@goldelico.com>
Date:   Thu, 9 May 2019 19:02:49 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Jonathan Cameron <jic23@...nel.org>
Cc:     linux-input <linux-input@...r.kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Eric Piel <eric.piel@...mplin-utc.net>,
        linux-iio <linux-iio@...r.kernel.org>, kernel@...a-handheld.com,
        lkml <linux-kernel@...r.kernel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Hartmut Knaack <knaack.h@....de>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>
Subject: Re: [Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface

> Am 09.05.2019 um 11:09 schrieb H. Nikolaus Schaller <hns@...delico.com>:
> 
> Hi Jonathan,
>> 
>> 
>> And how does that work on the common case of a sensor in the lid of a laptop?
>> how do you know what angle the screen is at?  
> 
> Well, I am not aware of laptops where the sensor is in the lid because I am in the handhelds
> business, but let's assume it is common.
> 
> I realized that if the sensor orientation is related to the lid position, while the reference
> frame reported to user space is to be referenced to the lap or keyboard of the laptop, there does
> not exist a static mount-matrix to describe it properly. So no driver can report that correctly.
> 
> Therefore, such a device needs a dynamic mount matrix, i.e. there should be a kernel driver that
> reads out the lid angle sensor and modifies the mount-matrix of the accelerometer by some sin()/cos()
> table.

One more thought on this topic.

My answer to the question "how do you know what angle the screen is at?" by requiring an ADC to
measure some potentiometer in the hinge to make the mount matrix dynamic is probably completely
wrong...

If we take the definition for the mount matrix, it defines a specific g-vector pointing to
center of earth if the user is holding the device in a specific position and looking on the display
or the keyboard.

So far the description assumes that there is a single accelerometer and display and keys of a phone
are in a single plane, i.e. there is no angle and everything is fine.

Now if we simply take the two accelerometers separately, one z-axis is going through the keyboard
and the other through the display. Which means if the mount matrices are well defined, the accelerometers
should report almost the same values if the display is fully opened by 180 degrees, i.e. the display
is sitting flat on the table. This is what my RFC does by autoscaling. The values differ only
by noise.

Now what about measuring the lid angle? Well, it is already measured by both accelerometers! If they
do not agree, the angle can be calculated by some arctan() based on y and z axis reports...

If you close the lid, the display is turned upside down and y and z axes reverse sign.

So there remains only the issue that user-space must know which sensor device file is which sensor
and can do the calculation of the lid angle. This is possible because the iio accelerometer name
is available through the input event ioctls.

In summary this case also does not need policy or configuration. Just user space using the information
that is already presented.

BR,
Nikolaus