Hi,

On 11/12/20 7:23 AM, Dmitry Torokhov wrote:

On Wed, Oct 07, 2020 at 11:51:05AM +0200, Hans de Goede wrote:

quoted

Hi,

On 10/7/20 10:36 AM, Jonathan Cameron wrote:

quoted

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

quoted

Adding Nitin, lead for this feature, to the thread

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

quoted

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.)

[ sorry for sitting on this thread for so long ]

So I think the important question here is if we only ever want yes/no
answer, or if we can consider adjusting behavior of the system based on
the "closeness" of an object to the device, in which case I think IIO is
more flexible.

FWIW in Chrome OS land we name IIO proximity sensors using a scheme
"proximity-lte", "proximity-wifi", "proximity-wifi-left",
"proximity-wifi-right", etc, and then userspace implements various
policies (SAR, etc) based off it.

Interesting, so 2 questions:

1. So your encoding the location in the sensor's parent-device name
instead of using a new sysfs attribute for this ?

2. Do these sensors just give a boolean value atm, or do they already
report a range ?  IIRC one of the objections from the iio folks in
the Lenovo case was that booleans are not really a good fit for iio
(IIRC they also said we could still use iio for this).

Perhaps you can provide an URL to the kernel code implementing these ?

quoted

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.

I am not sure if multiplexing all proximity switches into one evdev node
is that great option, as I am sure we'll soon have devices with 2x
palmrest switches and being capable finely adjusting transmit power,
etc.

Right, so going with iio, together with a naming scheme like used
on ChromeOS might indeed be more future proof (and make things
easier for running ChromeOS on non ChromeOS hardware and the other
way around).

Regards,

Hans