From: Doug Anderson <dianders@chromium.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Stephen Boyd <swboyd@chromium.org>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Benson Leung <bleung@chromium.org>,
LKML <linux-kernel@vger.kernel.org>,
"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
Guenter Roeck <groeck@chromium.org>
Subject: Re: [PATCH] Input: cros_ec_keyb: Add support for a front proximity switch
Date: Thu, 7 Jan 2021 06:57:10 -0800 [thread overview]
Message-ID: <CAD=FV=VmNQDSZFT3vaJ64DYyGqoE39uig581ZmaX0s-Y1U_CTw@mail.gmail.com> (raw)
In-Reply-To: <X/ZwRqJFJ9BY4Z3z@google.com>
Hi,
On Wed, Jan 6, 2021 at 6:22 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Doug, Stephen,
>
> On Wed, Jan 06, 2021 at 05:16:10PM -0800, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Dec 4, 2020 at 4:48 PM Stephen Boyd <swboyd@chromium.org> wrote:
> > >
> > > Some cros ECs support a front proximity MKBP event via
> > > 'EC_MKBP_FRONT_PROXIMITY'. Map this to the 'SW_FRONT_PROXIMITY' input
> > > event code so it can be reported up to userspace.
> > >
> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Cc: Benson Leung <bleung@chromium.org>
> > > Cc: Guenter Roeck <groeck@chromium.org>
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > > drivers/input/keyboard/cros_ec_keyb.c | 5 +++++
> > > include/linux/platform_data/cros_ec_commands.h | 1 +
> > > 2 files changed, 6 insertions(+)
> >
> > This seems really straightforward.
> >
> > 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/
>
> 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.
Unfortunately, it's not a public bug, but since you're at Google I
think you can look at b/168714440 to find the relevant discussion.
These are the models that Stephen is trying to add support for here...
-Doug
next prev parent reply other threads:[~2021-01-07 14:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-05 0:47 [PATCH] Input: cros_ec_keyb: Add support for a front proximity switch Stephen Boyd
2021-01-07 1:16 ` Doug Anderson
2021-01-07 2:21 ` Dmitry Torokhov
2021-01-07 14:57 ` Doug Anderson [this message]
2021-01-07 19:46 ` Dmitry Torokhov
2021-01-15 22:45 ` Stephen Boyd
2021-02-02 13:43 ` Pavel Machek
[not found] ` <CABXOdTcT4f_mg=ukPd0sD90o-aKg3qgiuLDRNPU8SUuFnFbRxA@mail.gmail.com>
2021-01-15 22:43 ` Stephen Boyd
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='CAD=FV=VmNQDSZFT3vaJ64DYyGqoE39uig581ZmaX0s-Y1U_CTw@mail.gmail.com' \
--to=dianders@chromium.org \
--cc=bleung@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=enric.balletbo@collabora.com \
--cc=groeck@chromium.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swboyd@chromium.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.