Linux-IIO Archive on lore.kernel.org
 help / color / Atom feed
* Using IIO to export laptop palm-sensor and lap-mode info to userspace?
@ 2020-10-03 14:02 Hans de Goede
  2020-10-06  2:04 ` [External] " Mark Pearson
  0 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2020-10-03 14:02 UTC (permalink / raw)
  To: linux-iio; +Cc: Mark Pearson, Bastien Nocera

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


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-03 14:02 Using IIO to export laptop palm-sensor and lap-mode info to userspace? Hans de Goede
@ 2020-10-06  2:04 ` Mark Pearson
  2020-10-07  8:36   ` Jonathan Cameron
  0 siblings, 1 reply; 15+ messages in thread
From: Mark Pearson @ 2020-10-06  2:04 UTC (permalink / raw)
  To: Hans de Goede, linux-iio; +Cc: Bastien Nocera, Nitin Joshi1

Adding Nitin, lead for this feature, to the thread

On 2020-10-03 10:02 a.m., Hans de Goede wrote:
> 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
> 

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-06  2:04 ` [External] " Mark Pearson
@ 2020-10-07  8:36   ` Jonathan Cameron
  2020-10-07  9:51     ` Hans de Goede
  0 siblings, 1 reply; 15+ messages in thread
From: Jonathan Cameron @ 2020-10-07  8:36 UTC (permalink / raw)
  To: Mark Pearson
  Cc: Hans de Goede, linux-iio, Bastien Nocera, Nitin Joshi1,
	linux-input, dmitry.torokhov

On Mon, 5 Oct 2020 22:04:27 -0400
Mark Pearson <markpearson@lenovo.com> wrote:

> Adding Nitin, lead for this feature, to the thread

+CC linux-input and Dmitry for reasons that will become clear below.
> 
> On 2020-10-03 10:02 a.m., Hans de Goede wrote:
> > 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.)

Dmitry, any existing stuff like this in input?

If it does make sense to put it in IIO then rest of the questions
obviously relevant.

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

Indeed, that one is a very odd beast :) (lightning sensor)

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

Given this is a bit of computed estimate rather than a true reading, I wonder
a bit if we should treat it as closer to an 'activity classification sensor'.

For those we use a percentage value to represent the output of some probabilistic
classifier.  In reality all the versions we've had so far aren't that clever though
so they only output 0 or 100%.  See in_activity_walking_input in the docs for
example.

> > 
> > 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 ?

Absolutely fine.  There is precedence in cros_ec which has a generic
location sysfs attribute (not associated with a particular channel though
it is fine to do that as well). See Documentation/ABI/testing/sysfs-bus-iio-cros_ec
We haven't moved it to the general docs because there is only one device
providing it so far.  Hence we would move it with the introduction of
this second device.

> > 
> > Regards,
> > 
> > Hans
> >   



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-07  8:36   ` Jonathan Cameron
@ 2020-10-07  9:51     ` Hans de Goede
  2020-10-07 11:35       ` Bastien Nocera
  0 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2020-10-07  9:51 UTC (permalink / raw)
  To: Jonathan Cameron, Mark Pearson
  Cc: linux-iio, Bastien Nocera, Nitin Joshi1, linux-input, dmitry.torokhov

Hi,

On 10/7/20 10:36 AM, Jonathan Cameron wrote:
> On Mon, 5 Oct 2020 22:04:27 -0400
> Mark Pearson <markpearson@lenovo.com> wrote:
> 
>> Adding Nitin, lead for this feature, to the thread
> 
> +CC linux-input and Dmitry for reasons that will become clear below.
>>
>> On 2020-10-03 10:02 a.m., Hans de Goede wrote:
>>> 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.)

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.

So yes this might indeed be better. Dmitry any thoughts on
this / objections against using the input/evdev API for this?

Note: s/key/switch/ in "sounds more like a key" above I guess.

> Dmitry, any existing stuff like this in input?

There already is a SW_FRONT_PROXIMITY defined in
input-event-codes.h, which I guess means detection if
someone is sitting in front of the screen. So we could add:

SW_LAP_PROXIMITY
SW_PALMREST_PROXIMITY,

And then we have a pretty decent API for this I think.

> If it does make sense to put it in IIO then rest of the questions
> obviously relevant.

Ack, thank you for your input.

Regards,

Hans





>>> 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.
> 
> Indeed, that one is a very odd beast :) (lightning sensor)
> 
>>>
>>>   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.
> 
> Given this is a bit of computed estimate rather than a true reading, I wonder
> a bit if we should treat it as closer to an 'activity classification sensor'.
> 
> For those we use a percentage value to represent the output of some probabilistic
> classifier.  In reality all the versions we've had so far aren't that clever though
> so they only output 0 or 100%.  See in_activity_walking_input in the docs for
> example.
> 
>>>
>>> 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 ?
> 
> Absolutely fine.  There is precedence in cros_ec which has a generic
> location sysfs attribute (not associated with a particular channel though
> it is fine to do that as well). See Documentation/ABI/testing/sysfs-bus-iio-cros_ec
> We haven't moved it to the general docs because there is only one device
> providing it so far.  Hence we would move it with the introduction of
> this second device.
> 
>>>
>>> Regards,
>>>
>>> Hans
>>>    
> 
> 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-07  9:51     ` Hans de Goede
@ 2020-10-07 11:35       ` Bastien Nocera
  2020-10-07 13:08         ` Hans de Goede
  0 siblings, 1 reply; 15+ messages in thread
From: Bastien Nocera @ 2020-10-07 11:35 UTC (permalink / raw)
  To: Hans de Goede, Jonathan Cameron, Mark Pearson
  Cc: linux-iio, Nitin Joshi1, linux-input, dmitry.torokhov

On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
> <snip>
> > Dmitry, any existing stuff like this in input?
> 
> There already is a SW_FRONT_PROXIMITY defined in
> input-event-codes.h, which I guess means detection if
> someone is sitting in front of the screen. So we could add:
> 
> SW_LAP_PROXIMITY
> SW_PALMREST_PROXIMITY,
> 
> And then we have a pretty decent API for this I think.

From the point of view of writing the consumer code for this API, it's
rather a lot of pain to open the device node (hoping that it's the
right one for what we need), getting the initial state, setting up
masks to avoid being woken up for every little event, and parsing those
events.

Where would the necessary bits of metadata for daemons to be able to
find that those switches need to get added?

If you go down that route, you'll definitely want a want to attach the
"palmrest" to the touchpad/keyboard that it corresponds to, otherwise
that might have weird interactions when using external keyboards and
touchpads. (I don't know what you'd use that proximity sensor for
though)

Cheers


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-07 11:35       ` Bastien Nocera
@ 2020-10-07 13:08         ` Hans de Goede
  2020-10-07 13:29           ` Bastien Nocera
  0 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2020-10-07 13:08 UTC (permalink / raw)
  To: Bastien Nocera, Jonathan Cameron, Mark Pearson
  Cc: linux-iio, Nitin Joshi1, linux-input, dmitry.torokhov

Hi,

On 10/7/20 1:35 PM, Bastien Nocera wrote:
> On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
>> <snip>
>>> Dmitry, any existing stuff like this in input?
>>
>> There already is a SW_FRONT_PROXIMITY defined in
>> input-event-codes.h, which I guess means detection if
>> someone is sitting in front of the screen. So we could add:
>>
>> SW_LAP_PROXIMITY
>> SW_PALMREST_PROXIMITY,
>>
>> And then we have a pretty decent API for this I think.
> 
>  From the point of view of writing the consumer code for this API, it's
> rather a lot of pain to open the device node (hoping that it's the
> right one for what we need), getting the initial state, setting up
> masks to avoid being woken up for every little event, and parsing those
> events.

There is not much difference with the iio sysfs API though, you would
also need to iterate over all the iio devices and test if they
are a proximity sensor (and read the new location sysfs file discussed).

> Where would the necessary bits of metadata for daemons to be able to
> find that those switches need to get added?

evdev files export info on which events they can report. Not only
the types of events (EV_SW in this case) but also a bitmask for
which event-codes they can report within that type.

> If you go down that route, you'll definitely want a want to attach the
> "palmrest" to the touchpad/keyboard that it corresponds to, otherwise
> that might have weird interactions when using external keyboards and
> touchpads. (I don't know what you'd use that proximity sensor for
> though)

The proximity sensor is primarily for deciding how strong a signal
wireless devices inside the laptop may emit.

Regards,

Hans


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-07 13:08         ` Hans de Goede
@ 2020-10-07 13:29           ` Bastien Nocera
  2020-10-07 13:32             ` Hans de Goede
  0 siblings, 1 reply; 15+ messages in thread
From: Bastien Nocera @ 2020-10-07 13:29 UTC (permalink / raw)
  To: Hans de Goede, Jonathan Cameron, Mark Pearson
  Cc: linux-iio, Nitin Joshi1, linux-input, dmitry.torokhov

On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/7/20 1:35 PM, Bastien Nocera wrote:
> > On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
> > > <snip>
> > > > Dmitry, any existing stuff like this in input?
> > > 
> > > There already is a SW_FRONT_PROXIMITY defined in
> > > input-event-codes.h, which I guess means detection if
> > > someone is sitting in front of the screen. So we could add:
> > > 
> > > SW_LAP_PROXIMITY
> > > SW_PALMREST_PROXIMITY,
> > > 
> > > And then we have a pretty decent API for this I think.
> > 
> >  From the point of view of writing the consumer code for this API,
> > it's
> > rather a lot of pain to open the device node (hoping that it's the
> > right one for what we need), getting the initial state, setting up
> > masks to avoid being woken up for every little event, and parsing
> > those
> > events.
> 
> There is not much difference with the iio sysfs API though, you would
> also need to iterate over all the iio devices and test if they
> are a proximity sensor (and read the new location sysfs file
> discussed).
> 
> > Where would the necessary bits of metadata for daemons to be able
> > to
> > find that those switches need to get added?
> 
> evdev files export info on which events they can report. Not only
> the types of events (EV_SW in this case) but also a bitmask for
> which event-codes they can report within that type.

I know that, I've written enough of that type of code ;)

I meant a way to avoid having to go open each evdev, read its
capabilities, and close them when it doesn't, and re-do that every time
a new event device appears. In other words, can you please make sure
there will be a udev property that we can use to enumerate and filter
devices with those capabilities?

> > If you go down that route, you'll definitely want a want to attach
> > the
> > "palmrest" to the touchpad/keyboard that it corresponds to,
> > otherwise
> > that might have weird interactions when using external keyboards
> > and
> > touchpads. (I don't know what you'd use that proximity sensor for
> > though)
> 
> The proximity sensor is primarily for deciding how strong a signal
> wireless devices inside the laptop may emit.

So we'll need a way to know what wireless device is inside the laptop
so that policy only applies to that one. This was already fun when it
was just event devices that needed grouping ;)


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-07 13:29           ` Bastien Nocera
@ 2020-10-07 13:32             ` Hans de Goede
  2020-10-08  0:14               ` Jeff LaBundy
  0 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2020-10-07 13:32 UTC (permalink / raw)
  To: Bastien Nocera, Jonathan Cameron, Mark Pearson
  Cc: linux-iio, Nitin Joshi1, linux-input, dmitry.torokhov

Hi,

On 10/7/20 3:29 PM, Bastien Nocera wrote:
> On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10/7/20 1:35 PM, Bastien Nocera wrote:
>>> On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
>>>> <snip>
>>>>> Dmitry, any existing stuff like this in input?
>>>>
>>>> There already is a SW_FRONT_PROXIMITY defined in
>>>> input-event-codes.h, which I guess means detection if
>>>> someone is sitting in front of the screen. So we could add:
>>>>
>>>> SW_LAP_PROXIMITY
>>>> SW_PALMREST_PROXIMITY,
>>>>
>>>> And then we have a pretty decent API for this I think.
>>>
>>>   From the point of view of writing the consumer code for this API,
>>> it's
>>> rather a lot of pain to open the device node (hoping that it's the
>>> right one for what we need), getting the initial state, setting up
>>> masks to avoid being woken up for every little event, and parsing
>>> those
>>> events.
>>
>> There is not much difference with the iio sysfs API though, you would
>> also need to iterate over all the iio devices and test if they
>> are a proximity sensor (and read the new location sysfs file
>> discussed).
>>
>>> Where would the necessary bits of metadata for daemons to be able
>>> to
>>> find that those switches need to get added?
>>
>> evdev files export info on which events they can report. Not only
>> the types of events (EV_SW in this case) but also a bitmask for
>> which event-codes they can report within that type.
> 
> I know that, I've written enough of that type of code ;)
> 
> I meant a way to avoid having to go open each evdev, read its
> capabilities, and close them when it doesn't, and re-do that every time
> a new event device appears. In other words, can you please make sure
> there will be a udev property that we can use to enumerate and filter
> devices with those capabilities?

Ah I see, yes that should not be a problem since we already run
a helper on all new evdev-s anyways (assuming we go this route).

Regards,

Hans


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-07 13:32             ` Hans de Goede
@ 2020-10-08  0:14               ` Jeff LaBundy
  2020-10-08  7:10                 ` Hans de Goede
  0 siblings, 1 reply; 15+ messages in thread
From: Jeff LaBundy @ 2020-10-08  0:14 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Bastien Nocera, Jonathan Cameron, Mark Pearson, linux-iio,
	Nitin Joshi1, linux-input, dmitry.torokhov

Hi all,

On Wed, Oct 07, 2020 at 03:32:07PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/7/20 3:29 PM, Bastien Nocera wrote:
> >On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 10/7/20 1:35 PM, Bastien Nocera wrote:
> >>>On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
> >>>><snip>
> >>>>>Dmitry, any existing stuff like this in input?

It seems we are talking about "specific absorption rate" (SAR) type
devices that signal the WLAN controller to reduce transmitted power
while a user is nearby.

I just wanted to chime in and confirm that we do have at least one
precedent for these being in input (keyboard/iqs62x-keys) and not
iio so I agree with Jonathan here. My argument is that we want to
signal binary events (user grabbed onto or let go of the handset)
rather than deliver continuous data.

The example I've shown reports events as keycodes since some of the
events it can express represent momentary conditions. In hindsight,
however, an argument can be made to express some of this information
as a switch (user is or is not near the device) and the new event
codes proposed here seem like a step in the right direction.

> >>>>
> >>>>There already is a SW_FRONT_PROXIMITY defined in
> >>>>input-event-codes.h, which I guess means detection if
> >>>>someone is sitting in front of the screen. So we could add:
> >>>>
> >>>>SW_LAP_PROXIMITY
> >>>>SW_PALMREST_PROXIMITY,
> >>>>
> >>>>And then we have a pretty decent API for this I think.
> >>>
> >>>  From the point of view of writing the consumer code for this API,
> >>>it's
> >>>rather a lot of pain to open the device node (hoping that it's the
> >>>right one for what we need), getting the initial state, setting up
> >>>masks to avoid being woken up for every little event, and parsing
> >>>those
> >>>events.
> >>
> >>There is not much difference with the iio sysfs API though, you would
> >>also need to iterate over all the iio devices and test if they
> >>are a proximity sensor (and read the new location sysfs file
> >>discussed).
> >>
> >>>Where would the necessary bits of metadata for daemons to be able
> >>>to
> >>>find that those switches need to get added?
> >>
> >>evdev files export info on which events they can report. Not only
> >>the types of events (EV_SW in this case) but also a bitmask for
> >>which event-codes they can report within that type.
> >
> >I know that, I've written enough of that type of code ;)
> >
> >I meant a way to avoid having to go open each evdev, read its
> >capabilities, and close them when it doesn't, and re-do that every time
> >a new event device appears. In other words, can you please make sure
> >there will be a udev property that we can use to enumerate and filter
> >devices with those capabilities?
> 
> Ah I see, yes that should not be a problem since we already run
> a helper on all new evdev-s anyways (assuming we go this route).
> 
> Regards,
> 
> Hans
> 

Kind regards,
Jeff LaBundy

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  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:36                   ` Enrico Weigelt, metux IT consult
  0 siblings, 2 replies; 15+ messages in thread
From: Hans de Goede @ 2020-10-08  7:10 UTC (permalink / raw)
  To: Jeff LaBundy
  Cc: Bastien Nocera, Jonathan Cameron, Mark Pearson, linux-iio,
	Nitin Joshi1, linux-input, dmitry.torokhov

Hi,

On 10/8/20 2:14 AM, Jeff LaBundy wrote:
> Hi all,
> 
> On Wed, Oct 07, 2020 at 03:32:07PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10/7/20 3:29 PM, Bastien Nocera wrote:
>>> On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 10/7/20 1:35 PM, Bastien Nocera wrote:
>>>>> On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
>>>>>> <snip>
>>>>>>> Dmitry, any existing stuff like this in input?
> 
> It seems we are talking about "specific absorption rate" (SAR) type
> devices that signal the WLAN controller to reduce transmitted power
> while a user is nearby.

Yes and no. At least the lap-mode detection (laptop on someones
lap rather then sitting on a table) is currently used by the
embedded-controller for thermal management decisions, basically
when on someones lap the configurable TPD of the CPU is set lower
to keep the laptop's bottom skin temperate < 45 degrees Celsius
(I think it is 45 but the exact number does not matter).

The lap-mode info is currently exported with a thinkpad_acpi specific
sysfs attribute with the idea that userspace could potentially use
this to indicate to the user that turbo clocks will be lower
because of this.

With upcoming WLAN cards with configurable transmit power,
this will also be used as what you call a SAR device.

AFAIK the palmrest case is mostly a SAR device.

Note I'm explaining the alternative lap-mode use-case to make
sure everyone is on the same page. I completely agree with the
gist of your email :)

> I just wanted to chime in and confirm that we do have at least one
> precedent for these being in input (keyboard/iqs62x-keys) and not
> iio so I agree with Jonathan here. My argument is that we want to
> signal binary events (user grabbed onto or let go of the handset)
> rather than deliver continuous data.

I was curious what keycode you are using for this, but I see
that the keycodes come from devicetree, so I guess I should
just ask: what keycode are you using for this ?

> The example I've shown reports events as keycodes since some of the
> events it can express represent momentary conditions. In hindsight,
> however, an argument can be made to express some of this information
> as a switch (user is or is not near the device) and the new event
> codes proposed here seem like a step in the right direction.

I'm glad that you like the new proposed switch event-codes.

Regards,

Hans


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  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
  1 sibling, 1 reply; 15+ messages in thread
From: Jeff LaBundy @ 2020-10-09  2:19 UTC (permalink / raw)
  To: Hans de Goede
  Cc: Bastien Nocera, Jonathan Cameron, Mark Pearson, linux-iio,
	Nitin Joshi1, linux-input, dmitry.torokhov

Hi Hans,

On Thu, Oct 08, 2020 at 09:10:19AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/8/20 2:14 AM, Jeff LaBundy wrote:
> >Hi all,
> >
> >On Wed, Oct 07, 2020 at 03:32:07PM +0200, Hans de Goede wrote:
> >>Hi,
> >>
> >>On 10/7/20 3:29 PM, Bastien Nocera wrote:
> >>>On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:
> >>>>Hi,
> >>>>
> >>>>On 10/7/20 1:35 PM, Bastien Nocera wrote:
> >>>>>On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
> >>>>>><snip>
> >>>>>>>Dmitry, any existing stuff like this in input?
> >
> >It seems we are talking about "specific absorption rate" (SAR) type
> >devices that signal the WLAN controller to reduce transmitted power
> >while a user is nearby.
> 
> Yes and no. At least the lap-mode detection (laptop on someones
> lap rather then sitting on a table) is currently used by the
> embedded-controller for thermal management decisions, basically
> when on someones lap the configurable TPD of the CPU is set lower
> to keep the laptop's bottom skin temperate < 45 degrees Celsius
> (I think it is 45 but the exact number does not matter).

This is a much-appreciated feature. :)

> 
> The lap-mode info is currently exported with a thinkpad_acpi specific
> sysfs attribute with the idea that userspace could potentially use
> this to indicate to the user that turbo clocks will be lower
> because of this.
> 
> With upcoming WLAN cards with configurable transmit power,
> this will also be used as what you call a SAR device.
> 
> AFAIK the palmrest case is mostly a SAR device.
> 
> Note I'm explaining the alternative lap-mode use-case to make
> sure everyone is on the same page. I completely agree with the
> gist of your email :)

Acknowledged on all counts; thank you for this additional background
information.

> 
> >I just wanted to chime in and confirm that we do have at least one
> >precedent for these being in input (keyboard/iqs62x-keys) and not
> >iio so I agree with Jonathan here. My argument is that we want to
> >signal binary events (user grabbed onto or let go of the handset)
> >rather than deliver continuous data.
> 
> I was curious what keycode you are using for this, but I see
> that the keycodes come from devicetree, so I guess I should
> just ask: what keycode are you using for this ?

The idea here was that a vendor might implement their own daemon
that interprets any keycode of their choice, hence leaving the
keycodes assignable via devicetree.

This particular device also acts as a capacitive/inductive button
sensor, and these applications were the primary motivation for it
landing in input with its status bits mapped to keycodes.

I don't think there are any keycodes that exist today that would
universally work for this application. The couple that seem most
closely related (e.g. KEY_WLAN or KEY_RFKILL) are typically used
for disabling the adapter entirely or for airplane mode (please
correct me if I'm wrong).

To that end, I'm keen to see how this interface unfolds because
SAR detection tends to be an available mode of operation for
several of the capacitive touch devices I've been working with.

> 
> >The example I've shown reports events as keycodes since some of the
> >events it can express represent momentary conditions. In hindsight,
> >however, an argument can be made to express some of this information
> >as a switch (user is or is not near the device) and the new event
> >codes proposed here seem like a step in the right direction.
> 
> I'm glad that you like the new proposed switch event-codes.
> 
> Regards,
> 
> Hans
> 

Kind regards,
Jeff LaBundy

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-09  2:19                   ` Jeff LaBundy
@ 2020-10-12 12:13                     ` Hans de Goede
  0 siblings, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2020-10-12 12:13 UTC (permalink / raw)
  To: Jeff LaBundy
  Cc: Bastien Nocera, Jonathan Cameron, Mark Pearson, linux-iio,
	Nitin Joshi1, linux-input, dmitry.torokhov

Hi,

On 10/9/20 4:19 AM, Jeff LaBundy wrote:
> Hi Hans,
> 
> On Thu, Oct 08, 2020 at 09:10:19AM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10/8/20 2:14 AM, Jeff LaBundy wrote:
>>> Hi all,
>>>
>>> On Wed, Oct 07, 2020 at 03:32:07PM +0200, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 10/7/20 3:29 PM, Bastien Nocera wrote:
>>>>> On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/7/20 1:35 PM, Bastien Nocera wrote:
>>>>>>> On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
>>>>>>>> <snip>
>>>>>>>>> Dmitry, any existing stuff like this in input?
>>>
>>> It seems we are talking about "specific absorption rate" (SAR) type
>>> devices that signal the WLAN controller to reduce transmitted power
>>> while a user is nearby.
>>
>> Yes and no. At least the lap-mode detection (laptop on someones
>> lap rather then sitting on a table) is currently used by the
>> embedded-controller for thermal management decisions, basically
>> when on someones lap the configurable TPD of the CPU is set lower
>> to keep the laptop's bottom skin temperate < 45 degrees Celsius
>> (I think it is 45 but the exact number does not matter).
> 
> This is a much-appreciated feature. :)
> 
>>
>> The lap-mode info is currently exported with a thinkpad_acpi specific
>> sysfs attribute with the idea that userspace could potentially use
>> this to indicate to the user that turbo clocks will be lower
>> because of this.
>>
>> With upcoming WLAN cards with configurable transmit power,
>> this will also be used as what you call a SAR device.
>>
>> AFAIK the palmrest case is mostly a SAR device.
>>
>> Note I'm explaining the alternative lap-mode use-case to make
>> sure everyone is on the same page. I completely agree with the
>> gist of your email :)
> 
> Acknowledged on all counts; thank you for this additional background
> information.
> 
>>
>>> I just wanted to chime in and confirm that we do have at least one
>>> precedent for these being in input (keyboard/iqs62x-keys) and not
>>> iio so I agree with Jonathan here. My argument is that we want to
>>> signal binary events (user grabbed onto or let go of the handset)
>>> rather than deliver continuous data.
>>
>> I was curious what keycode you are using for this, but I see
>> that the keycodes come from devicetree, so I guess I should
>> just ask: what keycode are you using for this ?
> 
> The idea here was that a vendor might implement their own daemon
> that interprets any keycode of their choice, hence leaving the
> keycodes assignable via devicetree.
> 
> This particular device also acts as a capacitive/inductive button
> sensor, and these applications were the primary motivation for it
> landing in input with its status bits mapped to keycodes.
> 
> I don't think there are any keycodes that exist today that would
> universally work for this application. The couple that seem most
> closely related (e.g. KEY_WLAN or KEY_RFKILL) are typically used
> for disabling the adapter entirely or for airplane mode (please
> correct me if I'm wrong).

You're right (aka not wrong), KEY_WLAN and KEY_RFKILL are used to
toggle wireless radios on/off and re-using them for some SAR
purpose would lead to nothing but confusion. We really need to
define some standard *new* event-codes for this, such as e.g.
the proposed SW_LAP_PROXIMITY and SW_PALMREST_PROXIMITY.

> To that end, I'm keen to see how this interface unfolds because
> SAR detection tends to be an available mode of operation for
> several of the capacitive touch devices I've been working with.

I guess that for touchscreens at least (which are on the front),
using the existing SW_FRONT_PROXIMITY would make the most sense.

Regards,

Hans


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  2020-10-08  7:10                 ` Hans de Goede
  2020-10-09  2:19                   ` Jeff LaBundy
@ 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
  1 sibling, 2 replies; 15+ messages in thread
From: Enrico Weigelt, metux IT consult @ 2020-10-12 12:36 UTC (permalink / raw)
  To: Hans de Goede, Jeff LaBundy
  Cc: Bastien Nocera, Jonathan Cameron, Mark Pearson, linux-iio,
	Nitin Joshi1, linux-input, dmitry.torokhov

On 08.10.20 09:10, Hans de Goede wrote:

Hi folks,

> Yes and no. At least the lap-mode detection (laptop on someones
> lap rather then sitting on a table) is currently used by the
> embedded-controller for thermal management decisions, basically
> when on someones lap the configurable TPD of the CPU is set lower
> to keep the laptop's bottom skin temperate < 45 degrees Celsius
> (I think it is 45 but the exact number does not matter).

Am I the only one who thinks the whole concept is a pretty weird
idea ?

IIRC the machine becomes slower when it *thinks* its on my lap,
but runs faster - and becomes hotter - when it's laying around
somewhere, eg. ontop of some papers ?

Where can I get the drugs that these guys took ? :o

> With upcoming WLAN cards with configurable transmit power,
> this will also be used as what you call a SAR device.

Same fun. Once a person comes near, the signal gets weaker and
potentially connection breaks. Great fun for debugging.

Back to the technical side: IMHO we should first work out what the
actual purpose of these sensors could be - are they useful for
anything else than just these specific cases ? If not, I'm not
sure whether it makes sense to put them into IIO at all, but using
a specific board driver instead.

Okay, maybe we find these sensors somewhere else (maybe some embedded
stuff), for completely different purpose - in that case having one
standard driver (for the sensor itself) could make sense.

But that leads me to bigger topic: we've got several cases of some
sensors/chips used in different subsystems, eg. simple one-shot
ADCs, eeprom's, etc. ... maybe we should move them to separate
subsystems, which then can be wired to other (more specific) ones
in a very generic way ? ... just some quick+dirty thoughs,


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  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
  1 sibling, 0 replies; 15+ messages in thread
From: Mark Pearson @ 2020-10-13  1:12 UTC (permalink / raw)
  To: Enrico Weigelt, metux IT consult, Hans de Goede, Jeff LaBundy
  Cc: Bastien Nocera, Jonathan Cameron, linux-iio, Nitin Joshi1,
	linux-input, dmitry.torokhov

Hi,

On 2020-10-12 8:36 a.m., Enrico Weigelt, metux IT consult wrote:
> On 08.10.20 09:10, Hans de Goede wrote:
> 
> Hi folks,
> 
>> Yes and no. At least the lap-mode detection (laptop on someones
>> lap rather then sitting on a table) is currently used by the
>> embedded-controller for thermal management decisions, basically
>> when on someones lap the configurable TPD of the CPU is set lower
>> to keep the laptop's bottom skin temperate < 45 degrees Celsius
>> (I think it is 45 but the exact number does not matter).
> 
> Am I the only one who thinks the whole concept is a pretty weird
> idea ?
> 
> IIRC the machine becomes slower when it *thinks* its on my lap,
> but runs faster - and becomes hotter - when it's laying around
> somewhere, eg. ontop of some papers ?
> 
> Where can I get the drugs that these guys took ? :o
This made me smile :) But I think it's safe to so no dubious substances 
were involved and it's really not that weird. We try very hard to not 
burn our customers, many of them appreciate that. We haven't yet 
implemented a paper sensor so that feature isn't available yet.

A lot of Linux users, quite reasonably, want to be able to access the 
maximum power available from their unit and so the logical conclusion is 
you can have max power (and therefore temperatures) when it's not on 
your lap, but in the interest of making the device safe and comfortable 
when it's on your lap the power rating drops.
I think this implementation is pretty common across all vendors these 
days - we're just exposing the lapmode sensor to user space to make it 
more obvious to users *why* the power dropped. We will also use both the 
lapmode and palm sensor for WWAN.

> 
>> With upcoming WLAN cards with configurable transmit power,
>> this will also be used as what you call a SAR device.
Minor correction - we're using this for WWAN

> 
> Same fun. Once a person comes near, the signal gets weaker and
> potentially connection breaks. Great fun for debugging.

My understanding is it's the way it's done on Windows and it is a FCC 
legal requirement so we can't get away from it. We could do what I think 
most vendors do and only provide the low power mode, but we're trying to 
give full and equivalent support to Linux users, so they can have full 
power when possible, and that means these proximity sensors being 
available to user space.

I hear you on the debugging but Windows seems to have managed OK.

> 
> Back to the technical side: IMHO we should first work out what the
> actual purpose of these sensors could be - are they useful for
> anything else than just these specific cases ? If not, I'm not
> sure whether it makes sense to put them into IIO at all, but using
> a specific board driver instead.

Hopefully the above helps explain the purpose of them a bit.

 From my point of view, I'm pretty new to the kernel contribution side 
of things so want to do whatever is recommended from the kernel 
community but gets these sensor states to user space so we can give 
Linux users a better experience on Lenovo platforms.

I think we've settled on using the input system instead of iio so maybe 
this thread is moot - but I wanted to respond in case details were 
useful or interesting.

> 
> Okay, maybe we find these sensors somewhere else (maybe some embedded
> stuff), for completely different purpose - in that case having one
> standard driver (for the sensor itself) could make sense.

It's hard to comment here as I only know about Lenovo implementations, 
but I wouldn't be hugely surprised if other vendors wanted to do 
similar. For now, to my knowledge, it is just a Lenovo implementation 
and the user-space consumer is a Lenovo application.

> 
> But that leads me to bigger topic: we've got several cases of some
> sensors/chips used in different subsystems, eg. simple one-shot
> ADCs, eeprom's, etc. ... maybe we should move them to separate
> subsystems, which then can be wired to other (more specific) ones
> in a very generic way ? ... just some quick+dirty thoughs,
> 
> 
> --mtx
> 

Mark

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
  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
  1 sibling, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2020-10-13  8:38 UTC (permalink / raw)
  To: Enrico Weigelt, metux IT consult, Jeff LaBundy
  Cc: Bastien Nocera, Jonathan Cameron, Mark Pearson, linux-iio,
	Nitin Joshi1, linux-input, dmitry.torokhov

Hi,

Enrico, thank you for your input.

See Mark's excellent email for answers to most of your questions,
I just have one little thing to add.

On 10/12/20 2:36 PM, Enrico Weigelt, metux IT consult wrote:
> On 08.10.20 09:10, Hans de Goede wrote:

<snip>

> Back to the technical side: IMHO we should first work out what the
> actual purpose of these sensors could be - are they useful for
> anything else than just these specific cases ? If not, I'm not
> sure whether it makes sense to put them into IIO at all, but using
> a specific board driver instead.

Right, also note that although there are doubtlessly sensors involved
we don't actually get any meaningful / direct access to these sensors.

We only get to talk to firmware which basically gives us:

Laptop is on someone's lap: yes/no
Someone is resting on the palmrest: yes/no

The lack of direct sensor access also makes this a less then
ideal case for using iio. So I believe that the suggestion
to extend the existing evdev/input SW_FRONT_PROXIMITY support
with 2 new SW_LAP_PROXIMITY and SW_PALMREST_PROXIMITY suggestion
makes a ton of sense. Switches are binary and given that this
really is a derived value and not raw sensor access using the
input system seems a better match.

Regards,

Hans


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, back to index

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-03 14:02 Using IIO to export laptop palm-sensor and lap-mode info to userspace? Hans de Goede
2020-10-06  2:04 ` [External] " 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

Linux-IIO Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iio/0 linux-iio/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iio linux-iio/ https://lore.kernel.org/linux-iio \
		linux-iio@vger.kernel.org
	public-inbox-index linux-iio

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-iio


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git