[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160721203322.GB9841@dtor-ws>
Date: Thu, 21 Jul 2016 13:33:22 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Lv Zheng <lv.zheng@...el.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Len Brown <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
Benjamin Tissoires <benjamin.tissoires@...il.com>,
"Bastien Nocera:" <hadess@...ess.net>, linux-input@...r.kernel.org
Subject: Re: [PATCH v4 1/2] ACPI / button: Add KEY_LID_OPEN/KEY_LID_CLOSE for
new usage model
On Thu, Jul 21, 2016 at 03:35:36PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, July 19, 2016 04:11:02 PM Lv Zheng wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never report lid open state. As a proxy layer acting between, ACPI
> > button driver is not able to handle all such cases, but need to re-define
> > the usage model of the ACPI lid. That is:
> > 1. It's initial state is not reliable;
> > 2. There may not be an open event;
> > 3. Userspace should only take action against the close event which is
> > reliable, always sent after a real lid close.
> >
> > OTOH, using an input switch event for the lid device on such platforms can
> > cause the loss of the close event, but the platforms purposely want to use
> > these close events to trigger power saving actions.
> >
> > So we need to introduce a new ABI, which is input key events based, not
> > input switch events based.
> >
> > This patch adds a set of new input key events so that the new userspace
> > programs can use them to handle this usage model correctly. And in the
> > meanwhile, the old input switch event is kept so that no old programs will
> > be broken by the ABI change.
> >
> > Signed-off-by: Lv Zheng <lv.zheng@...el.com>
> > Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > Cc: Benjamin Tissoires <benjamin.tissoires@...il.com>
> > Cc: Bastien Nocera: <hadess@...ess.net>
> > Cc: linux-input@...r.kernel.org
>
> Dmitry, any objections here?
Yes I have (see the other email).
Thanks.
--
Dmitry
Powered by blists - more mailing lists