Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
From: Hans de Goede <hidden>
Date: 2020-10-07 13:32:15
Also in:
linux-iio
Hi, On 10/7/20 3:29 PM, Bastien Nocera wrote:
On Wed, 2020-10-07 at 15:08 +0200, Hans de Goede wrote:quoted
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?
Ah I see, yes that should not be a problem since we already run a helper on all new evdev-s anyways (assuming we go this route). Regards, Hans