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

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.

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.

Thanks.

-- 
Dmitry