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
