Re: [PATCH] Input: cros_ec_keyb: Add support for a front proximity switch

Hi!

quoted

quoted

quoted

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Given that it touches a header file owned by the Chrome OS maintainers
and a driver owned by input, how should it land?  One maintainer Acks
and the other lands?

Sorry about missing this one, however the "front proximity" switch has
been introduced for the benefit of phone devices, to be emitted when a
device is raised to user's ear, and I do not think we should be using
this here.

We have just recently had similar discussion with regard to palm- and
lap-mode sensors and whether they should be reported over input or IIO
as true proximity sensors:

https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/ (local)

Based on what we are doing for other Chrome OS devices that expose
proximity sensors (for example trogdor) we have decided that we all
should be using IIO as it will allow not only on/off, but true proximity
reporting with potential of implementing smarter policies by userspace.

Because of that we should do the same here and export this as IIO
proximity sensor as well.

For devices with a true proximity sensor that's exactly what we're
doing.  I've only been involved in the periphery of the discussion,
but as I understand it there are some models of laptop for which we
don't have a true proximity sensor.  On these devices, the EC is in
charge of deciding about proximity based on a number of factors.

Yes, I understand that on some devices the proximity sensors are not
true sensors but rather on/off signals, potentially derived from a
multitude of sources. However there is still a benefit in exposing them
as IIO proximity devices with limited reporting representing
[near, infinity] range/values. This will mean that userspace needs to
monitor only one set of devices (IIO) instead of both IIO and input, and
will not require constantly expanding EV_SW set to account for
ever-growing number of proximity sensors (lap, palm, general presence,
etc).

While I believe one set of devices is good goal, I don't think IIO is
good solution here. It is being used for user input after
all... Routing on/off values to IIO is strange.

Best regards,
									Pavel

-- 
http://www.livejournal.com/~pavelmachek