> Am 09.05.2019 um 11:09 schrieb H. Nikolaus Schaller <[email protected]>: > > 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
