From: Bastien Nocera <hadess@hadess.net>
To: Hans de Goede <hdegoede@redhat.com>,
Jonathan Cameron <Jonathan.Cameron@Huawei.com>,
Mark Pearson <markpearson@lenovo.com>
Cc: linux-iio@vger.kernel.org, Nitin Joshi1 <njoshi1@lenovo.com>,
linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
Subject: Re: [External] Using IIO to export laptop palm-sensor and lap-mode info to userspace?
Date: Wed, 07 Oct 2020 13:35:55 +0200 [thread overview]
Message-ID: <b400b6956270a2433373dd6cbdae3332aa683f4f.camel@hadess.net> (raw)
In-Reply-To: <218be284-4a37-e9f9-749d-c126ef1d098b@redhat.com>
On Wed, 2020-10-07 at 11:51 +0200, Hans de Goede wrote:
> <snip>
> > 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.
Where would the necessary bits of metadata for daemons to be able to
find that those switches need to get added?
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)
Cheers
next prev parent reply other threads:[~2020-10-07 11:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-03 14:02 Using IIO to export laptop palm-sensor and lap-mode info to userspace? Hans de Goede
2020-10-06 2:04 ` [External] " Mark Pearson
2020-10-07 8:36 ` Jonathan Cameron
2020-10-07 9:51 ` Hans de Goede
2020-10-07 11:35 ` Bastien Nocera [this message]
2020-10-07 13:08 ` Hans de Goede
2020-10-07 13:29 ` Bastien Nocera
2020-10-07 13:32 ` Hans de Goede
2020-10-08 0:14 ` Jeff LaBundy
2020-10-08 7:10 ` Hans de Goede
2020-10-09 2:19 ` Jeff LaBundy
2020-10-12 12:13 ` Hans de Goede
2020-10-12 12:36 ` Enrico Weigelt, metux IT consult
2020-10-13 1:12 ` Mark Pearson
2020-10-13 8:38 ` Hans de Goede
2020-11-12 6:23 ` Dmitry Torokhov
2020-11-12 9:50 ` Hans de Goede
2020-11-13 6:58 ` Dmitry Torokhov
2020-11-19 15:39 ` Hans de Goede
2020-11-19 16:11 ` Bastien Nocera
2020-11-20 9:59 ` Jonathan Cameron
2020-11-23 12:16 ` Hans de Goede
2020-11-23 16:07 ` Jonathan Cameron
2020-11-19 15:16 ` Bastien Nocera
2020-11-19 15:24 ` Hans de Goede
2020-11-19 15:58 ` Bastien Nocera
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b400b6956270a2433373dd6cbdae3332aa683f4f.camel@hadess.net \
--to=hadess@hadess.net \
--cc=Jonathan.Cameron@Huawei.com \
--cc=dmitry.torokhov@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=markpearson@lenovo.com \
--cc=njoshi1@lenovo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).