linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: linux-iio@vger.kernel.org
Cc: Mark Pearson <markpearson@lenovo.com>,
	Bastien Nocera <hadess@hadess.net>
Subject: Using IIO to export laptop palm-sensor and lap-mode info to userspace?
Date: Sat, 3 Oct 2020 16:02:37 +0200	[thread overview]
Message-ID: <9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com> (raw)

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.

2. These laptops have something called lap-mode, which
determines if the laptop's firmware thinks that it is on
a users lap, or sitting on a table. This influences the
max. allowed skin-temperature of the bottom of the laptop
and thus influences thermal management.  Like the palm-rest
snesors, this reading will likely also be used for
controlling wireless transmission levels in the future.

Note that AFAIK the lap_mode reading is not a single sensor
reading, it is a value derived from a bunch of sensor readings,
the raw values of which may or may not be available
separately.

So looking at existing IIO userspace API docs, focussing on
proximity sensors I see:

Documentation/ABI/testing/sysfs-bus-iio
Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935

Where the latter seems to not really be relevant.

 From the generic IO API doc, this bit is the most
interesting:

What:           /sys/.../iio:deviceX/in_proximity_raw
What:           /sys/.../iio:deviceX/in_proximity_input
What:           /sys/.../iio:deviceX/in_proximityY_raw
KernelVersion:  3.4
Contact:        linux-iio@vger.kernel.org
Description:
                 Proximity measurement indicating that some
                 object is near the sensor, usually by observing
                 reflectivity of infrared or ultrasound emitted.
                 Often these sensors are unit less and as such conversion
                 to SI units is not possible. Higher proximity measurements
                 indicate closer objects, and vice versa. Units after
                 application of scale and offset are meters.

This seems to be a reasonable match for the Thinkpad sensors
we are discussing here, although those report a simple
0/1 value.

What is missing for the ThinkPad case is something like this:

What:		/sys/.../iio:deviceX/proximity_sensor_location
KernelVersion:  5.11
Contact:        linux-iio@vger.kernel.org
Description:
		Specifies the location of the proximity sensor /
		specifies proximity to what the sensor is measuring.
		Reading this file returns a string describing this, valid values
		for this string are: "screen", "lap", "palmrest"
		Note the list of valid values may be extended in the
		future.

So what do you (IIO devs) think about this?

Would adding a proximity_sensor_location attribute be a reasonable
thing to do for this; and do you think that this would be a good idea ?

Regards,

Hans


             reply	other threads:[~2020-10-03 14:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-03 14:02 Hans de Goede [this message]
2020-10-06  2:04 ` [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace? Mark Pearson
2020-10-07  8:36   ` Jonathan Cameron
2020-10-07  9:51     ` Hans de Goede
2020-10-07 11:35       ` Bastien Nocera
2020-10-07 13:08         ` Hans de Goede
2020-10-07 13:29           ` Bastien Nocera
2020-10-07 13:32             ` Hans de Goede
2020-10-08  0:14               ` Jeff LaBundy
2020-10-08  7:10                 ` Hans de Goede
2020-10-09  2:19                   ` Jeff LaBundy
2020-10-12 12:13                     ` Hans de Goede
2020-10-12 12:36                   ` Enrico Weigelt, metux IT consult
2020-10-13  1:12                     ` Mark Pearson
2020-10-13  8:38                     ` Hans de Goede
2020-11-12  6:23       ` Dmitry Torokhov
2020-11-12  9:50         ` Hans de Goede
2020-11-13  6:58           ` Dmitry Torokhov
2020-11-19 15:39             ` Hans de Goede
2020-11-19 16:11               ` Bastien Nocera
2020-11-20  9:59               ` Jonathan Cameron
2020-11-23 12:16                 ` Hans de Goede
2020-11-23 16:07                   ` Jonathan Cameron
2020-11-19 15:16         ` Bastien Nocera
2020-11-19 15:24           ` Hans de Goede
2020-11-19 15:58             ` Bastien Nocera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=hadess@hadess.net \
    --cc=linux-iio@vger.kernel.org \
    --cc=markpearson@lenovo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).