Hi,
On 10/7/20 10:36 AM, Jonathan Cameron wrote:
On Mon, 5 Oct 2020 22:04:27 -0400
Mark Pearson <markpearson@xxxxxxxxxx> 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:
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.)
That is an interesting suggestion. Using the input/evdev API
would have some advantages such as being able to have a single
event node for all the proximity switches and then being able
to pass a fd to that from a privileged process to a non
privileged one, something which userspace already has
various infrastructure for.
So yes this might indeed be better. Dmitry any thoughts on
this / objections against using the input/evdev API for this?
Note: s/key/switch/ in "sounds more like a key" above I guess.
Dmitry, any existing stuff like this in input?
There already is a SW_FRONT_PROXIMITY defined in
input-event-codes.h, which I guess means detection if
someone is sitting in front of the screen. So we could add:
SW_LAP_PROXIMITY
SW_PALMREST_PROXIMITY,
And then we have a pretty decent API for this I think.
If it does make sense to put it in IIO then rest of the questions
obviously relevant.
Ack, thank you for your input.
Regards,
Hans
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)
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@xxxxxxxxxxxxxxx
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.
What is missing for the ThinkPad case is something like this:
What: /sys/.../iio:deviceX/proximity_sensor_location
KernelVersion: 5.11
Contact: linux-iio@xxxxxxxxxxxxxxx
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.
Regards,
Hans
