On Thu, 2020-11-19 at 16:39 +0100, Hans de Goede wrote:

Hi,

On 11/13/20 7:58 AM, Dmitry Torokhov wrote:

quoted

On Thu, Nov 12, 2020 at 10:50:12AM +0100, Hans de Goede wrote:

quoted

Hi,

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

quoted

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 ?

I think it depends on the kernel we use and architecture. On x86 I
think
we rely on udev, like this:

https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/master/overlay-nocturne/chromeos-base/chromeos-bsp-nocturne/files/udev/99-cros-sx-proximity.rules

DEVPATH=="*/pci0000:00/0000:00:15.1/*", SYMLINK+="proximity-wifi-
right"
DEVPATH=="*/pci0000:00/0000:00:19.1/*", SYMLINK+="proximity-wifi-
left"
ATTR{events/in_proximity1_USE_CS1_thresh_either_en}="1"

So that results in a symlink under /dev, right ? That seems like
it is not really compatible with how most modern userspace discovers
hw (through udev). Although I guess code using udev could still
lookup the symlink in the udev per device data, this just not feel
like a good way forward.

We can tag it, the metadata will be readable in where we need it,
through libudev, so that's not a big bother.