On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:

Hi,

On 10/7/20 1:35 PM, Bastien Nocera wrote:

quoted

On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:

quoted

<snip>

quoted

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

quoted

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?

quoted

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 ;)