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

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"

On newer ARM we use "label" attribute in DTS:

arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi

        ap_sar_sensor: proximity@28 {
                compatible = "semtech,sx9310";
                reg = <0x28>;
                #io-channel-cells = <1>;
                pinctrl-names = "default";
                pinctrl-0 = <&p_sensor_int_l>;

                interrupt-parent = <&tlmm>;
                interrupts = <24 IRQ_TYPE_LEVEL_LOW>;

                vdd-supply = <&pp3300_a>;
                svdd-supply = <&pp1800_prox>;

                status = "disabled";
                label = "proximity-wifi";
        };

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

One of the sensors we use is sx9310 that I believe can report range, but
I think we configure them to trigger when a threshold is crossed.

Events are handled by our powerd:

https://chromium.googlesource.com/chromiumos/platform2/+/master/power_manager/powerd/system/sar_watcher.cc

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

drivers/iio/proximity/sx9310.c

Also sx932x - https://lore.kernel.org/patchwork/patch/1005708/

Thanks.

-- 
Dmitry