Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?

On Mon, 5 Oct 2020 22:04:27 -0400
Mark Pearson [off-list ref] wrote:

Adding Nitin, lead for this feature, to the thread

+CC linux-input and Dmitry for reasons that will become clear below.

On 2020-10-03 10:02 a.m., Hans de Goede wrote:

quoted

Hi All,

Modern laptops can have various sensors which are kinda
like proximity sensors, but not really (they are more
specific in which part of the laptop the user is
proximate to).

Specifically modern Thinkpad's have 2 readings which we
want to export to userspace, and I'm wondering if we
could use the IIO framework for this since these readings
are in essence sensor readings:

1. These laptops have a sensor in the palm-rests to
check if a user is physically proximate to the device's
palm-rests. This info will be used by userspace for WWAN
functionality to control the transmission level safely.

A patch adding a thinkpad_acpi specific sysfs API for this
is currently pending:
https://patchwork.kernel.org/patch/11722127/

But I'm wondering if it would not be better to use
IIO to export this info.

My first thought on this is it sounds more like a key than a sensor
(simple proximity sensors fall into this category as well.)

Dmitry, any existing stuff like this in input?

If it does make sense to put it in IIO then rest of the questions
obviously relevant.

quoted

2. These laptops have something called lap-mode, which
determines if the laptop's firmware thinks that it is on
a users lap, or sitting on a table. This influences the
max. allowed skin-temperature of the bottom of the laptop
and thus influences thermal management.  Like the palm-rest
snesors, this reading will likely also be used for
controlling wireless transmission levels in the future.

Note that AFAIK the lap_mode reading is not a single sensor
reading, it is a value derived from a bunch of sensor readings,
the raw values of which may or may not be available
separately.

So looking at existing IIO userspace API docs, focussing on
proximity sensors I see:

Documentation/ABI/testing/sysfs-bus-iio
Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935

Where the latter seems to not really be relevant.

Indeed, that one is a very odd beast :) (lightning sensor)

quoted

 From the generic IO API doc, this bit is the most
interesting:

What:           /sys/.../iio:deviceX/in_proximity_raw
What:           /sys/.../iio:deviceX/in_proximity_input
What:           /sys/.../iio:deviceX/in_proximityY_raw
KernelVersion:  3.4
Contact:        linux-iio@vger.kernel.org
Description:
                 Proximity measurement indicating that some
                 object is near the sensor, usually by observing
                 reflectivity of infrared or ultrasound emitted.
                 Often these sensors are unit less and as such conversion
                 to SI units is not possible. Higher proximity measurements
                 indicate closer objects, and vice versa. Units after
                 application of scale and offset are meters.

This seems to be a reasonable match for the Thinkpad sensors
we are discussing here, although those report a simple
0/1 value.

Given this is a bit of computed estimate rather than a true reading, I wonder
a bit if we should treat it as closer to an 'activity classification sensor'.

For those we use a percentage value to represent the output of some probabilistic
classifier.  In reality all the versions we've had so far aren't that clever though
so they only output 0 or 100%.  See in_activity_walking_input in the docs for
example.

quoted

What is missing for the ThinkPad case is something like this:

What:        /sys/.../iio:deviceX/proximity_sensor_location
KernelVersion:  5.11
Contact:        linux-iio@vger.kernel.org
Description:
         Specifies the location of the proximity sensor /
         specifies proximity to what the sensor is measuring.
         Reading this file returns a string describing this, valid values
         for this string are: "screen", "lap", "palmrest"
         Note the list of valid values may be extended in the
         future.

So what do you (IIO devs) think about this?

Would adding a proximity_sensor_location attribute be a reasonable
thing to do for this; and do you think that this would be a good idea ?

Absolutely fine.  There is precedence in cros_ec which has a generic
location sysfs attribute (not associated with a particular channel though
it is fine to do that as well). See Documentation/ABI/testing/sysfs-bus-iio-cros_ec
We haven't moved it to the general docs because there is only one device
providing it so far.  Hence we would move it with the introduction of
this second device.

quoted

Regards,

Hans