Hi, Enrico, thank you for your input. See Mark's excellent email for answers to most of your questions, I just have one little thing to add. On 10/12/20 2:36 PM, Enrico Weigelt, metux IT consult wrote:
On 08.10.20 09:10, Hans de Goede wrote:
<snip>
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.
Right, also note that although there are doubtlessly sensors involved we don't actually get any meaningful / direct access to these sensors. We only get to talk to firmware which basically gives us: Laptop is on someone's lap: yes/no Someone is resting on the palmrest: yes/no The lack of direct sensor access also makes this a less then ideal case for using iio. So I believe that the suggestion to extend the existing evdev/input SW_FRONT_PROXIMITY support with 2 new SW_LAP_PROXIMITY and SW_PALMREST_PROXIMITY suggestion makes a ton of sense. Switches are binary and given that this really is a derived value and not raw sensor access using the input system seems a better match. Regards, Hans
