Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?

[Mark Pearson <markpearson@lenovo.com>]

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