Hi,

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

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.

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";
        };

Hmm, interesting. I did not know iio-devices could
have a label sysfs attribute (nor that that could be
set through device-tree). I was thinking about adding
an in_proximity_location sysfs attribute. But using
labels (and standardizing a set of label names) will
work nicely too.

I have no real preference for this either way, so
I guess we might as well go with labels to avoid
having any unnecessary discrepancies between ChromeOS
and whatever we do for the Thinkpad sensors.

Is there a know set of labels which ChromeOS is currently
using? If we are going to use labels for this it would
be good IMHO to define a set of standard labels for
this in say Documentation/ABI/testing/sysfs-bus-iio-labels.

quoted

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

quoted

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

drivers/iio/proximity/sx9310.c

If I'm reading that correctly the it exports a raw "distance"
reading and a suggested threshold value for the code interpreting
the reading to use.

So that would be a bit different then the Thinkpad sensors, but
exporting just a 0-1 range for the in_proximity_raw value for the
Thinkpad case should not be a problem. Or we could just make it
repot 0 and 100 and export a fixed in_proximity_nearlevel of 50,
that would make the userspace API more like other proximity sensors.

Regards,

Hans