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
