subject:"\[PATCH v2 4\/4\] ACPI \/ button\: Add document for ACPI control method lid device restrictions"

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Zheng, Lv

Hi, Dmitry

> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
> > <dmitry.torok...@gmail.com> wrote:
> > > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> > >> Hi,
> > >>
> > >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com>
> wrote:
> > >> > There are many AML tables reporting wrong initial lid state, and
> some of
> > >> > them never reports lid 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 open event;
> > >> > 3. Userspace should only take action against the close event which
> is
> > >> >reliable, always sent after a real lid close.
> > >> > This patch adds documentation of the usage model.
> > >> >
> > >> > Link: https://lkml.org/2016/3/7/460
> > >> > Link: https://github.com/systemd/systemd/issues/2087
> > >> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> > >> > Cc: Bastien Nocera: <had...@hadess.net>
> > >> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> > >> > Cc: linux-in...@vger.kernel.org
> > >> > ---
> > >> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> > >> >  1 file changed, 62 insertions(+)
> > >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> > >> >
> > >> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> > >> > new file mode 100644
> > >> > index 000..7e4f7ed
> > >> > --- /dev/null
> > >> > +++ b/Documentation/acpi/acpi-lid.txt
> > >> > @@ -0,0 +1,62 @@
> > >> > +Usage Model of the ACPI Control Method Lid Device
> > >> > +
> > >> > +Copyright (C) 2016, Intel Corporation
> > >> > +Author: Lv Zheng <lv.zh...@intel.com>
> > >> > +
> > >> > +
> > >> > +Abstract:
> > >> > +
> > >> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> > >> > +control method lid device. To implement this, the AML tables issue
> > >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state has
> > >> > +changed. The _LID control method for the lid device must be
> implemented to
> > >> > +report the "current" state of the lid as either "opened" or "closed".
> > >> > +
> > >> > +This document describes the restrictions and the expections of the
> Linux
> > >> > +ACPI lid device driver.
> > >> > +
> > >> > +
> > >> > +1. Restrictions of the returning value of the _LID control method
> > >> > +
> > >> > +The _LID control method is described to return the "current" lid
> state.
> > >> > +However the word of "current" has ambiguity, many AML tables
> return the lid
> > >> > +state upon the last lid notification instead of returning the lid 
> > >> > state
> > >> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> > >> > +control method is evaluated during the runtime, the problem is its
> initial
> > >> > +returning value. When the AML tables implement this control
> method with
> > >> > +cached value, the initial returning value is likely not reliable. 
> > >> > There
> are
> > >> > +simply so many examples always retuning "closed" as initial lid
> state.
> > >> > +
> > >> > +2. Restrictions of the lid state change notifications
> > >> > +
> > >> > +There are many AML tables never notifying when the lid device
> state is
> > >> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > >> > +"closed" when the lid state is changed to "closed". This is normally
>

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Zheng, Lv

Hi, Dmitry

> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
> >  wrote:
> > > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> > >> Hi,
> > >>
> > >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng 
> wrote:
> > >> > There are many AML tables reporting wrong initial lid state, and
> some of
> > >> > them never reports lid 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 open event;
> > >> > 3. Userspace should only take action against the close event which
> is
> > >> >reliable, always sent after a real lid close.
> > >> > This patch adds documentation of the usage model.
> > >> >
> > >> > Link: https://lkml.org/2016/3/7/460
> > >> > Link: https://github.com/systemd/systemd/issues/2087
> > >> > Signed-off-by: Lv Zheng 
> > >> > Cc: Bastien Nocera: 
> > >> > Cc: Benjamin Tissoires 
> > >> > Cc: linux-in...@vger.kernel.org
> > >> > ---
> > >> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> > >> >  1 file changed, 62 insertions(+)
> > >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> > >> >
> > >> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> > >> > new file mode 100644
> > >> > index 000..7e4f7ed
> > >> > --- /dev/null
> > >> > +++ b/Documentation/acpi/acpi-lid.txt
> > >> > @@ -0,0 +1,62 @@
> > >> > +Usage Model of the ACPI Control Method Lid Device
> > >> > +
> > >> > +Copyright (C) 2016, Intel Corporation
> > >> > +Author: Lv Zheng 
> > >> > +
> > >> > +
> > >> > +Abstract:
> > >> > +
> > >> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> > >> > +control method lid device. To implement this, the AML tables issue
> > >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state has
> > >> > +changed. The _LID control method for the lid device must be
> implemented to
> > >> > +report the "current" state of the lid as either "opened" or "closed".
> > >> > +
> > >> > +This document describes the restrictions and the expections of the
> Linux
> > >> > +ACPI lid device driver.
> > >> > +
> > >> > +
> > >> > +1. Restrictions of the returning value of the _LID control method
> > >> > +
> > >> > +The _LID control method is described to return the "current" lid
> state.
> > >> > +However the word of "current" has ambiguity, many AML tables
> return the lid
> > >> > +state upon the last lid notification instead of returning the lid 
> > >> > state
> > >> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> > >> > +control method is evaluated during the runtime, the problem is its
> initial
> > >> > +returning value. When the AML tables implement this control
> method with
> > >> > +cached value, the initial returning value is likely not reliable. 
> > >> > There
> are
> > >> > +simply so many examples always retuning "closed" as initial lid
> state.
> > >> > +
> > >> > +2. Restrictions of the lid state change notifications
> > >> > +
> > >> > +There are many AML tables never notifying when the lid device
> state is
> > >> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > >> > +"closed" when the lid state is changed to "closed". This is normally
> used
> > >> > +to trigger some system power saving operations on Windows.
> Since it is
> > >> > +fully tested, this notification is reli

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Benjamin Tissoires

On Tue, Jul 19, 2016 at 10:57 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
> Hi, Benjamin
>
>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> On Tue, Jul 19, 2016 at 9:17 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
>> > Hi, Dmitry
>> >
>> >> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
>> >> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI
>> control
>> >> method lid device restrictions
>> >>
>> >> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
>> >> > Hi,
>> >> >
>> >> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com>
>> wrote:
>> >> > > There are many AML tables reporting wrong initial lid state, and
>> some
>> >> of
>> >> > > them never reports lid 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 open event;
>> >> > > 3. Userspace should only take action against the close event which
>> is
>> >> > >reliable, always sent after a real lid close.
>> >> > > This patch adds documentation of the usage model.
>> >> > >
>> >> > > Link: https://lkml.org/2016/3/7/460
>> >> > > Link: https://github.com/systemd/systemd/issues/2087
>> >> > > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
>> >> > > Cc: Bastien Nocera: <had...@hadess.net>
>> >> > > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
>> >> > > Cc: linux-in...@vger.kernel.org
>> >> > > ---
>> >> > >  Documentation/acpi/acpi-lid.txt |   62
>> >> +++
>> >> > >  1 file changed, 62 insertions(+)
>> >> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> >> > >
>> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
>> >> b/Documentation/acpi/acpi-lid.txt
>> >> > > new file mode 100644
>> >> > > index 000..7e4f7ed
>> >> > > --- /dev/null
>> >> > > +++ b/Documentation/acpi/acpi-lid.txt
>> >> > > @@ -0,0 +1,62 @@
>> >> > > +Usage Model of the ACPI Control Method Lid Device
>> >> > > +
>> >> > > +Copyright (C) 2016, Intel Corporation
>> >> > > +Author: Lv Zheng <lv.zh...@intel.com>
>> >> > > +
>> >> > > +
>> >> > > +Abstract:
>> >> > > +
>> >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
>> >> using a
>> >> > > +control method lid device. To implement this, the AML tables issue
>> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
>> state
>> >> has
>> >> > > +changed. The _LID control method for the lid device must be
>> >> implemented to
>> >> > > +report the "current" state of the lid as either "opened" or "closed".
>> >> > > +
>> >> > > +This document describes the restrictions and the expections of the
>> >> Linux
>> >> > > +ACPI lid device driver.
>> >> > > +
>> >> > > +
>> >> > > +1. Restrictions of the returning value of the _LID control method
>> >> > > +
>> >> > > +The _LID control method is described to return the "current" lid
>> state.
>> >> > > +However the word of "current" has ambiguity, many AML tables
>> >> return the lid
>> >> > > +state upon the last lid notification instead of returning the lid 
>> >> > > state
>> >> > > +upon the last _LID evaluation. There won't be difference when the
>> >> _LID
>> >> > > +control method is evaluated during the runtime, the problem is its
>> >> initial
>> >> > > +returning value. When the AML tables implement this control
>> method
>

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Benjamin Tissoires

On Tue, Jul 19, 2016 at 10:57 AM, Zheng, Lv  wrote:
> Hi, Benjamin
>
>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> On Tue, Jul 19, 2016 at 9:17 AM, Zheng, Lv  wrote:
>> > Hi, Dmitry
>> >
>> >> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
>> >> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI
>> control
>> >> method lid device restrictions
>> >>
>> >> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
>> >> > Hi,
>> >> >
>> >> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng 
>> wrote:
>> >> > > There are many AML tables reporting wrong initial lid state, and
>> some
>> >> of
>> >> > > them never reports lid 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 open event;
>> >> > > 3. Userspace should only take action against the close event which
>> is
>> >> > >reliable, always sent after a real lid close.
>> >> > > This patch adds documentation of the usage model.
>> >> > >
>> >> > > Link: https://lkml.org/2016/3/7/460
>> >> > > Link: https://github.com/systemd/systemd/issues/2087
>> >> > > Signed-off-by: Lv Zheng 
>> >> > > Cc: Bastien Nocera: 
>> >> > > Cc: Benjamin Tissoires 
>> >> > > Cc: linux-in...@vger.kernel.org
>> >> > > ---
>> >> > >  Documentation/acpi/acpi-lid.txt |   62
>> >> +++
>> >> > >  1 file changed, 62 insertions(+)
>> >> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> >> > >
>> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
>> >> b/Documentation/acpi/acpi-lid.txt
>> >> > > new file mode 100644
>> >> > > index 000..7e4f7ed
>> >> > > --- /dev/null
>> >> > > +++ b/Documentation/acpi/acpi-lid.txt
>> >> > > @@ -0,0 +1,62 @@
>> >> > > +Usage Model of the ACPI Control Method Lid Device
>> >> > > +
>> >> > > +Copyright (C) 2016, Intel Corporation
>> >> > > +Author: Lv Zheng 
>> >> > > +
>> >> > > +
>> >> > > +Abstract:
>> >> > > +
>> >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
>> >> using a
>> >> > > +control method lid device. To implement this, the AML tables issue
>> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
>> state
>> >> has
>> >> > > +changed. The _LID control method for the lid device must be
>> >> implemented to
>> >> > > +report the "current" state of the lid as either "opened" or "closed".
>> >> > > +
>> >> > > +This document describes the restrictions and the expections of the
>> >> Linux
>> >> > > +ACPI lid device driver.
>> >> > > +
>> >> > > +
>> >> > > +1. Restrictions of the returning value of the _LID control method
>> >> > > +
>> >> > > +The _LID control method is described to return the "current" lid
>> state.
>> >> > > +However the word of "current" has ambiguity, many AML tables
>> >> return the lid
>> >> > > +state upon the last lid notification instead of returning the lid 
>> >> > > state
>> >> > > +upon the last _LID evaluation. There won't be difference when the
>> >> _LID
>> >> > > +control method is evaluated during the runtime, the problem is its
>> >> initial
>> >> > > +returning value. When the AML tables implement this control
>> method
>> >> with
>> >> > > +cached value, the initial returning value is likely not reliable. 
>> >> > > There
>> are
>> >>

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Zheng, Lv

Hi, Benjamin

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Tue, Jul 19, 2016 at 9:17 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
> > Hi, Dmitry
> >
> >> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> >> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI
> control
> >> method lid device restrictions
> >>
> >> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> > Hi,
> >> >
> >> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com>
> wrote:
> >> > > There are many AML tables reporting wrong initial lid state, and
> some
> >> of
> >> > > them never reports lid 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 open event;
> >> > > 3. Userspace should only take action against the close event which
> is
> >> > >reliable, always sent after a real lid close.
> >> > > This patch adds documentation of the usage model.
> >> > >
> >> > > Link: https://lkml.org/2016/3/7/460
> >> > > Link: https://github.com/systemd/systemd/issues/2087
> >> > > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> >> > > Cc: Bastien Nocera: <had...@hadess.net>
> >> > > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> >> > > Cc: linux-in...@vger.kernel.org
> >> > > ---
> >> > >  Documentation/acpi/acpi-lid.txt |   62
> >> +++
> >> > >  1 file changed, 62 insertions(+)
> >> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> > >
> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
> >> b/Documentation/acpi/acpi-lid.txt
> >> > > new file mode 100644
> >> > > index 000..7e4f7ed
> >> > > --- /dev/null
> >> > > +++ b/Documentation/acpi/acpi-lid.txt
> >> > > @@ -0,0 +1,62 @@
> >> > > +Usage Model of the ACPI Control Method Lid Device
> >> > > +
> >> > > +Copyright (C) 2016, Intel Corporation
> >> > > +Author: Lv Zheng <lv.zh...@intel.com>
> >> > > +
> >> > > +
> >> > > +Abstract:
> >> > > +
> >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
> >> using a
> >> > > +control method lid device. To implement this, the AML tables issue
> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state
> >> has
> >> > > +changed. The _LID control method for the lid device must be
> >> implemented to
> >> > > +report the "current" state of the lid as either "opened" or "closed".
> >> > > +
> >> > > +This document describes the restrictions and the expections of the
> >> Linux
> >> > > +ACPI lid device driver.
> >> > > +
> >> > > +
> >> > > +1. Restrictions of the returning value of the _LID control method
> >> > > +
> >> > > +The _LID control method is described to return the "current" lid
> state.
> >> > > +However the word of "current" has ambiguity, many AML tables
> >> return the lid
> >> > > +state upon the last lid notification instead of returning the lid 
> >> > > state
> >> > > +upon the last _LID evaluation. There won't be difference when the
> >> _LID
> >> > > +control method is evaluated during the runtime, the problem is its
> >> initial
> >> > > +returning value. When the AML tables implement this control
> method
> >> with
> >> > > +cached value, the initial returning value is likely not reliable. 
> >> > > There
> are
> >> > > +simply so many examples always retuning "closed" as initial lid
> state.
> >> > > +
> >> > > +2. Restrictions of the lid state change notifications
> >> > > +
> >> > > +There are many A

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Zheng, Lv

Hi, Benjamin

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Tue, Jul 19, 2016 at 9:17 AM, Zheng, Lv  wrote:
> > Hi, Dmitry
> >
> >> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> >> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI
> control
> >> method lid device restrictions
> >>
> >> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> > Hi,
> >> >
> >> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng 
> wrote:
> >> > > There are many AML tables reporting wrong initial lid state, and
> some
> >> of
> >> > > them never reports lid 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 open event;
> >> > > 3. Userspace should only take action against the close event which
> is
> >> > >reliable, always sent after a real lid close.
> >> > > This patch adds documentation of the usage model.
> >> > >
> >> > > Link: https://lkml.org/2016/3/7/460
> >> > > Link: https://github.com/systemd/systemd/issues/2087
> >> > > Signed-off-by: Lv Zheng 
> >> > > Cc: Bastien Nocera: 
> >> > > Cc: Benjamin Tissoires 
> >> > > Cc: linux-in...@vger.kernel.org
> >> > > ---
> >> > >  Documentation/acpi/acpi-lid.txt |   62
> >> +++
> >> > >  1 file changed, 62 insertions(+)
> >> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> > >
> >> > > diff --git a/Documentation/acpi/acpi-lid.txt
> >> b/Documentation/acpi/acpi-lid.txt
> >> > > new file mode 100644
> >> > > index 000..7e4f7ed
> >> > > --- /dev/null
> >> > > +++ b/Documentation/acpi/acpi-lid.txt
> >> > > @@ -0,0 +1,62 @@
> >> > > +Usage Model of the ACPI Control Method Lid Device
> >> > > +
> >> > > +Copyright (C) 2016, Intel Corporation
> >> > > +Author: Lv Zheng 
> >> > > +
> >> > > +
> >> > > +Abstract:
> >> > > +
> >> > > +Platforms containing lids convey lid state (open/close) to OSPMs
> >> using a
> >> > > +control method lid device. To implement this, the AML tables issue
> >> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state
> >> has
> >> > > +changed. The _LID control method for the lid device must be
> >> implemented to
> >> > > +report the "current" state of the lid as either "opened" or "closed".
> >> > > +
> >> > > +This document describes the restrictions and the expections of the
> >> Linux
> >> > > +ACPI lid device driver.
> >> > > +
> >> > > +
> >> > > +1. Restrictions of the returning value of the _LID control method
> >> > > +
> >> > > +The _LID control method is described to return the "current" lid
> state.
> >> > > +However the word of "current" has ambiguity, many AML tables
> >> return the lid
> >> > > +state upon the last lid notification instead of returning the lid 
> >> > > state
> >> > > +upon the last _LID evaluation. There won't be difference when the
> >> _LID
> >> > > +control method is evaluated during the runtime, the problem is its
> >> initial
> >> > > +returning value. When the AML tables implement this control
> method
> >> with
> >> > > +cached value, the initial returning value is likely not reliable. 
> >> > > There
> are
> >> > > +simply so many examples always retuning "closed" as initial lid
> state.
> >> > > +
> >> > > +2. Restrictions of the lid state change notifications
> >> > > +
> >> > > +There are many AML tables never notifying when the lid device
> state
> >> is
> >> > > +changed to "opened". But it is ensured that the AML tables alwa

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Benjamin Tissoires

On Tue, Jul 19, 2016 at 9:17 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
> Hi, Dmitry
>
>> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
>> > Hi,
>> >
>> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
>> > > There are many AML tables reporting wrong initial lid state, and some
>> of
>> > > them never reports lid 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 open event;
>> > > 3. Userspace should only take action against the close event which is
>> > >reliable, always sent after a real lid close.
>> > > This patch adds documentation of the usage model.
>> > >
>> > > Link: https://lkml.org/2016/3/7/460
>> > > Link: https://github.com/systemd/systemd/issues/2087
>> > > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
>> > > Cc: Bastien Nocera: <had...@hadess.net>
>> > > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
>> > > Cc: linux-in...@vger.kernel.org
>> > > ---
>> > >  Documentation/acpi/acpi-lid.txt |   62
>> +++
>> > >  1 file changed, 62 insertions(+)
>> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> > >
>> > > diff --git a/Documentation/acpi/acpi-lid.txt
>> b/Documentation/acpi/acpi-lid.txt
>> > > new file mode 100644
>> > > index 000..7e4f7ed
>> > > --- /dev/null
>> > > +++ b/Documentation/acpi/acpi-lid.txt
>> > > @@ -0,0 +1,62 @@
>> > > +Usage Model of the ACPI Control Method Lid Device
>> > > +
>> > > +Copyright (C) 2016, Intel Corporation
>> > > +Author: Lv Zheng <lv.zh...@intel.com>
>> > > +
>> > > +
>> > > +Abstract:
>> > > +
>> > > +Platforms containing lids convey lid state (open/close) to OSPMs
>> using a
>> > > +control method lid device. To implement this, the AML tables issue
>> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
>> has
>> > > +changed. The _LID control method for the lid device must be
>> implemented to
>> > > +report the "current" state of the lid as either "opened" or "closed".
>> > > +
>> > > +This document describes the restrictions and the expections of the
>> Linux
>> > > +ACPI lid device driver.
>> > > +
>> > > +
>> > > +1. Restrictions of the returning value of the _LID control method
>> > > +
>> > > +The _LID control method is described to return the "current" lid state.
>> > > +However the word of "current" has ambiguity, many AML tables
>> return the lid
>> > > +state upon the last lid notification instead of returning the lid state
>> > > +upon the last _LID evaluation. There won't be difference when the
>> _LID
>> > > +control method is evaluated during the runtime, the problem is its
>> initial
>> > > +returning value. When the AML tables implement this control method
>> with
>> > > +cached value, the initial returning value is likely not reliable. There 
>> > > are
>> > > +simply so many examples always retuning "closed" as initial lid state.
>> > > +
>> > > +2. Restrictions of the lid state change notifications
>> > > +
>> > > +There are many AML tables never notifying when the lid device state
>> is
>> > > +changed to "opened". But it is ensured that the AML tables always
>> notify
>> > > +"closed" when the lid state is changed to "closed". This is normally
>> used
>> > > +to trigger some system power saving operations on Windows. Since it
>> is
>> > > +fully tested, this notification is reliable for all AML tables.
>> > > +
>> > > +3. Expections for the userspace users of the ACPI lid device driver
>> > > +
>> > > +The userspace programs should stop relying on
>> > > +

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Benjamin Tissoires

On Tue, Jul 19, 2016 at 9:17 AM, Zheng, Lv  wrote:
> Hi, Dmitry
>
>> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
>> > Hi,
>> >
>> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
>> > > There are many AML tables reporting wrong initial lid state, and some
>> of
>> > > them never reports lid 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 open event;
>> > > 3. Userspace should only take action against the close event which is
>> > >reliable, always sent after a real lid close.
>> > > This patch adds documentation of the usage model.
>> > >
>> > > Link: https://lkml.org/2016/3/7/460
>> > > Link: https://github.com/systemd/systemd/issues/2087
>> > > Signed-off-by: Lv Zheng 
>> > > Cc: Bastien Nocera: 
>> > > Cc: Benjamin Tissoires 
>> > > Cc: linux-in...@vger.kernel.org
>> > > ---
>> > >  Documentation/acpi/acpi-lid.txt |   62
>> +++
>> > >  1 file changed, 62 insertions(+)
>> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> > >
>> > > diff --git a/Documentation/acpi/acpi-lid.txt
>> b/Documentation/acpi/acpi-lid.txt
>> > > new file mode 100644
>> > > index 000..7e4f7ed
>> > > --- /dev/null
>> > > +++ b/Documentation/acpi/acpi-lid.txt
>> > > @@ -0,0 +1,62 @@
>> > > +Usage Model of the ACPI Control Method Lid Device
>> > > +
>> > > +Copyright (C) 2016, Intel Corporation
>> > > +Author: Lv Zheng 
>> > > +
>> > > +
>> > > +Abstract:
>> > > +
>> > > +Platforms containing lids convey lid state (open/close) to OSPMs
>> using a
>> > > +control method lid device. To implement this, the AML tables issue
>> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
>> has
>> > > +changed. The _LID control method for the lid device must be
>> implemented to
>> > > +report the "current" state of the lid as either "opened" or "closed".
>> > > +
>> > > +This document describes the restrictions and the expections of the
>> Linux
>> > > +ACPI lid device driver.
>> > > +
>> > > +
>> > > +1. Restrictions of the returning value of the _LID control method
>> > > +
>> > > +The _LID control method is described to return the "current" lid state.
>> > > +However the word of "current" has ambiguity, many AML tables
>> return the lid
>> > > +state upon the last lid notification instead of returning the lid state
>> > > +upon the last _LID evaluation. There won't be difference when the
>> _LID
>> > > +control method is evaluated during the runtime, the problem is its
>> initial
>> > > +returning value. When the AML tables implement this control method
>> with
>> > > +cached value, the initial returning value is likely not reliable. There 
>> > > are
>> > > +simply so many examples always retuning "closed" as initial lid state.
>> > > +
>> > > +2. Restrictions of the lid state change notifications
>> > > +
>> > > +There are many AML tables never notifying when the lid device state
>> is
>> > > +changed to "opened". But it is ensured that the AML tables always
>> notify
>> > > +"closed" when the lid state is changed to "closed". This is normally
>> used
>> > > +to trigger some system power saving operations on Windows. Since it
>> is
>> > > +fully tested, this notification is reliable for all AML tables.
>> > > +
>> > > +3. Expections for the userspace users of the ACPI lid device driver
>> > > +
>> > > +The userspace programs should stop relying on
>> > > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is
>> only
>> > > +used for the validation purpose.
>> >
>> >

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Zheng, Lv

Hi, Dmitry

> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> > Hi,
> >
> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
> > > There are many AML tables reporting wrong initial lid state, and some
> of
> > > them never reports lid 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 open event;
> > > 3. Userspace should only take action against the close event which is
> > >reliable, always sent after a real lid close.
> > > This patch adds documentation of the usage model.
> > >
> > > Link: https://lkml.org/2016/3/7/460
> > > Link: https://github.com/systemd/systemd/issues/2087
> > > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> > > Cc: Bastien Nocera: <had...@hadess.net>
> > > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> > > Cc: linux-in...@vger.kernel.org
> > > ---
> > >  Documentation/acpi/acpi-lid.txt |   62
> +++
> > >  1 file changed, 62 insertions(+)
> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
> > >
> > > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> > > new file mode 100644
> > > index 000..7e4f7ed
> > > --- /dev/null
> > > +++ b/Documentation/acpi/acpi-lid.txt
> > > @@ -0,0 +1,62 @@
> > > +Usage Model of the ACPI Control Method Lid Device
> > > +
> > > +Copyright (C) 2016, Intel Corporation
> > > +Author: Lv Zheng <lv.zh...@intel.com>
> > > +
> > > +
> > > +Abstract:
> > > +
> > > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> > > +control method lid device. To implement this, the AML tables issue
> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> > > +changed. The _LID control method for the lid device must be
> implemented to
> > > +report the "current" state of the lid as either "opened" or "closed".
> > > +
> > > +This document describes the restrictions and the expections of the
> Linux
> > > +ACPI lid device driver.
> > > +
> > > +
> > > +1. Restrictions of the returning value of the _LID control method
> > > +
> > > +The _LID control method is described to return the "current" lid state.
> > > +However the word of "current" has ambiguity, many AML tables
> return the lid
> > > +state upon the last lid notification instead of returning the lid state
> > > +upon the last _LID evaluation. There won't be difference when the
> _LID
> > > +control method is evaluated during the runtime, the problem is its
> initial
> > > +returning value. When the AML tables implement this control method
> with
> > > +cached value, the initial returning value is likely not reliable. There 
> > > are
> > > +simply so many examples always retuning "closed" as initial lid state.
> > > +
> > > +2. Restrictions of the lid state change notifications
> > > +
> > > +There are many AML tables never notifying when the lid device state
> is
> > > +changed to "opened". But it is ensured that the AML tables always
> notify
> > > +"closed" when the lid state is changed to "closed". This is normally
> used
> > > +to trigger some system power saving operations on Windows. Since it
> is
> > > +fully tested, this notification is reliable for all AML tables.
> > > +
> > > +3. Expections for the userspace users of the ACPI lid device driver
> > > +
> > > +The userspace programs should stop relying on
> > > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is
> only
> > > +used for the validation purpose.
> >
> > I'd say: this file actually calls the _LID method described above. And
> > given the previous explanation, it is not reliable enough on some
> > platforms. So it is strongly advised for user-space program to not
> > solely rely on this file to determine the actual lid state.
>

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-19 Thread Zheng, Lv

Hi, Dmitry

> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> > Hi,
> >
> > On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > > There are many AML tables reporting wrong initial lid state, and some
> of
> > > them never reports lid 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 open event;
> > > 3. Userspace should only take action against the close event which is
> > >reliable, always sent after a real lid close.
> > > This patch adds documentation of the usage model.
> > >
> > > Link: https://lkml.org/2016/3/7/460
> > > Link: https://github.com/systemd/systemd/issues/2087
> > > Signed-off-by: Lv Zheng 
> > > Cc: Bastien Nocera: 
> > > Cc: Benjamin Tissoires 
> > > Cc: linux-in...@vger.kernel.org
> > > ---
> > >  Documentation/acpi/acpi-lid.txt |   62
> +++
> > >  1 file changed, 62 insertions(+)
> > >  create mode 100644 Documentation/acpi/acpi-lid.txt
> > >
> > > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> > > new file mode 100644
> > > index 000..7e4f7ed
> > > --- /dev/null
> > > +++ b/Documentation/acpi/acpi-lid.txt
> > > @@ -0,0 +1,62 @@
> > > +Usage Model of the ACPI Control Method Lid Device
> > > +
> > > +Copyright (C) 2016, Intel Corporation
> > > +Author: Lv Zheng 
> > > +
> > > +
> > > +Abstract:
> > > +
> > > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> > > +control method lid device. To implement this, the AML tables issue
> > > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> > > +changed. The _LID control method for the lid device must be
> implemented to
> > > +report the "current" state of the lid as either "opened" or "closed".
> > > +
> > > +This document describes the restrictions and the expections of the
> Linux
> > > +ACPI lid device driver.
> > > +
> > > +
> > > +1. Restrictions of the returning value of the _LID control method
> > > +
> > > +The _LID control method is described to return the "current" lid state.
> > > +However the word of "current" has ambiguity, many AML tables
> return the lid
> > > +state upon the last lid notification instead of returning the lid state
> > > +upon the last _LID evaluation. There won't be difference when the
> _LID
> > > +control method is evaluated during the runtime, the problem is its
> initial
> > > +returning value. When the AML tables implement this control method
> with
> > > +cached value, the initial returning value is likely not reliable. There 
> > > are
> > > +simply so many examples always retuning "closed" as initial lid state.
> > > +
> > > +2. Restrictions of the lid state change notifications
> > > +
> > > +There are many AML tables never notifying when the lid device state
> is
> > > +changed to "opened". But it is ensured that the AML tables always
> notify
> > > +"closed" when the lid state is changed to "closed". This is normally
> used
> > > +to trigger some system power saving operations on Windows. Since it
> is
> > > +fully tested, this notification is reliable for all AML tables.
> > > +
> > > +3. Expections for the userspace users of the ACPI lid device driver
> > > +
> > > +The userspace programs should stop relying on
> > > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is
> only
> > > +used for the validation purpose.
> >
> > I'd say: this file actually calls the _LID method described above. And
> > given the previous explanation, it is not reliable enough on some
> > platforms. So it is strongly advised for user-space program to not
> > solely rely on this file to determine the actual lid state.
> >
> > > +
> > > +New userspace programs should rely on the lid "closed" notification
> to
> > > +trigger

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi, Dmitry

> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
> > <dmitry.torok...@gmail.com> wrote:
> > > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> > >> Hi,
> > >>
> > >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com>
> wrote:
> > >> > There are many AML tables reporting wrong initial lid state, and
> some of
> > >> > them never reports lid 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 open event;
> > >> > 3. Userspace should only take action against the close event which
> is
> > >> >reliable, always sent after a real lid close.
> > >> > This patch adds documentation of the usage model.
> > >> >
> > >> > Link: https://lkml.org/2016/3/7/460
> > >> > Link: https://github.com/systemd/systemd/issues/2087
> > >> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> > >> > Cc: Bastien Nocera: <had...@hadess.net>
> > >> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> > >> > Cc: linux-in...@vger.kernel.org
> > >> > ---
> > >> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> > >> >  1 file changed, 62 insertions(+)
> > >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> > >> >
> > >> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> > >> > new file mode 100644
> > >> > index 000..7e4f7ed
> > >> > --- /dev/null
> > >> > +++ b/Documentation/acpi/acpi-lid.txt
> > >> > @@ -0,0 +1,62 @@
> > >> > +Usage Model of the ACPI Control Method Lid Device
> > >> > +
> > >> > +Copyright (C) 2016, Intel Corporation
> > >> > +Author: Lv Zheng <lv.zh...@intel.com>
> > >> > +
> > >> > +
> > >> > +Abstract:
> > >> > +
> > >> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> > >> > +control method lid device. To implement this, the AML tables issue
> > >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state has
> > >> > +changed. The _LID control method for the lid device must be
> implemented to
> > >> > +report the "current" state of the lid as either "opened" or "closed".
> > >> > +
> > >> > +This document describes the restrictions and the expections of the
> Linux
> > >> > +ACPI lid device driver.
> > >> > +
> > >> > +
> > >> > +1. Restrictions of the returning value of the _LID control method
> > >> > +
> > >> > +The _LID control method is described to return the "current" lid
> state.
> > >> > +However the word of "current" has ambiguity, many AML tables
> return the lid
> > >> > +state upon the last lid notification instead of returning the lid 
> > >> > state
> > >> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> > >> > +control method is evaluated during the runtime, the problem is its
> initial
> > >> > +returning value. When the AML tables implement this control
> method with
> > >> > +cached value, the initial returning value is likely not reliable. 
> > >> > There
> are
> > >> > +simply so many examples always retuning "closed" as initial lid
> state.
> > >> > +
> > >> > +2. Restrictions of the lid state change notifications
> > >> > +
> > >> > +There are many AML tables never notifying when the lid device
> state is
> > >> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > >> > +"closed" when the lid state is changed to "closed". This is normally
>

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi, Dmitry

> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> > On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
> >  wrote:
> > > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> > >> Hi,
> > >>
> > >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng 
> wrote:
> > >> > There are many AML tables reporting wrong initial lid state, and
> some of
> > >> > them never reports lid 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 open event;
> > >> > 3. Userspace should only take action against the close event which
> is
> > >> >reliable, always sent after a real lid close.
> > >> > This patch adds documentation of the usage model.
> > >> >
> > >> > Link: https://lkml.org/2016/3/7/460
> > >> > Link: https://github.com/systemd/systemd/issues/2087
> > >> > Signed-off-by: Lv Zheng 
> > >> > Cc: Bastien Nocera: 
> > >> > Cc: Benjamin Tissoires 
> > >> > Cc: linux-in...@vger.kernel.org
> > >> > ---
> > >> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> > >> >  1 file changed, 62 insertions(+)
> > >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> > >> >
> > >> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> > >> > new file mode 100644
> > >> > index 000..7e4f7ed
> > >> > --- /dev/null
> > >> > +++ b/Documentation/acpi/acpi-lid.txt
> > >> > @@ -0,0 +1,62 @@
> > >> > +Usage Model of the ACPI Control Method Lid Device
> > >> > +
> > >> > +Copyright (C) 2016, Intel Corporation
> > >> > +Author: Lv Zheng 
> > >> > +
> > >> > +
> > >> > +Abstract:
> > >> > +
> > >> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> > >> > +control method lid device. To implement this, the AML tables issue
> > >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid
> state has
> > >> > +changed. The _LID control method for the lid device must be
> implemented to
> > >> > +report the "current" state of the lid as either "opened" or "closed".
> > >> > +
> > >> > +This document describes the restrictions and the expections of the
> Linux
> > >> > +ACPI lid device driver.
> > >> > +
> > >> > +
> > >> > +1. Restrictions of the returning value of the _LID control method
> > >> > +
> > >> > +The _LID control method is described to return the "current" lid
> state.
> > >> > +However the word of "current" has ambiguity, many AML tables
> return the lid
> > >> > +state upon the last lid notification instead of returning the lid 
> > >> > state
> > >> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> > >> > +control method is evaluated during the runtime, the problem is its
> initial
> > >> > +returning value. When the AML tables implement this control
> method with
> > >> > +cached value, the initial returning value is likely not reliable. 
> > >> > There
> are
> > >> > +simply so many examples always retuning "closed" as initial lid
> state.
> > >> > +
> > >> > +2. Restrictions of the lid state change notifications
> > >> > +
> > >> > +There are many AML tables never notifying when the lid device
> state is
> > >> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > >> > +"closed" when the lid state is changed to "closed". This is normally
> used
> > >> > +to trigger some system power saving operations on Windows.
> Since it is
> > >> > +fully tested, this notification is reli

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi,

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Benjamin Tissoires
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> [I just realised Ctrl+enter means "send" for gmail, see the end of the
> answers]
> 
> On Mon, Jul 11, 2016 at 1:42 PM, Benjamin Tissoires
> <benjamin.tissoi...@gmail.com> wrote:
> > On Mon, Jul 11, 2016 at 5:20 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
> >> Hi,
> >>
> >>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> >>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI
> control
> >>> method lid device restrictions
> >>>
> >>> Hi,
> >>>
> >>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
> >>> > There are many AML tables reporting wrong initial lid state, and
> some of
> >>> > them never reports lid 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 open event;
> >>> > 3. Userspace should only take action against the close event which is
> >>> >reliable, always sent after a real lid close.
> >>> > This patch adds documentation of the usage model.
> >>> >
> >>> > Link: https://lkml.org/2016/3/7/460
> >>> > Link: https://github.com/systemd/systemd/issues/2087
> >>> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> >>> > Cc: Bastien Nocera: <had...@hadess.net>
> >>> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> >>> > Cc: linux-in...@vger.kernel.org
> >>> > ---
> >>> >  Documentation/acpi/acpi-lid.txt |   62
> >>> +++
> >>> >  1 file changed, 62 insertions(+)
> >>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >>> >
> >>> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-
> >>> lid.txt
> >>> > new file mode 100644
> >>> > index 000..7e4f7ed
> >>> > --- /dev/null
> >>> > +++ b/Documentation/acpi/acpi-lid.txt
> >>> > @@ -0,0 +1,62 @@
> >>> > +Usage Model of the ACPI Control Method Lid Device
> >>> > +
> >>> > +Copyright (C) 2016, Intel Corporation
> >>> > +Author: Lv Zheng <lv.zh...@intel.com>
> >>> > +
> >>> > +
> >>> > +Abstract:
> >>> > +
> >>> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using
> >>> a
> >>> > +control method lid device. To implement this, the AML tables issue
> >>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> >>> > +changed. The _LID control method for the lid device must be
> >>> implemented to
> >>> > +report the "current" state of the lid as either "opened" or "closed".
> >>> > +
> >>> > +This document describes the restrictions and the expections of the
> >>> Linux
> >>> > +ACPI lid device driver.
> >>> > +
> >>> > +
> >>> > +1. Restrictions of the returning value of the _LID control method
> >>> > +
> >>> > +The _LID control method is described to return the "current" lid
> state.
> >>> > +However the word of "current" has ambiguity, many AML tables
> return
> >>> the lid
> >>> > +state upon the last lid notification instead of returning the lid state
> >>> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> >>> > +control method is evaluated during the runtime, the problem is its
> >>> initial
> >>> > +returning value. When the AML tables implement this control
> method
> >>> with
> >>> > +cached value, the initial returning value is likely not reliable. There
> are
> >>> > +simply so many examples always retuning "closed" as initial lid
> state.
> >>> > +
> >>> > +2. Restrictions of t

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi,

> From: linux-acpi-ow...@vger.kernel.org [mailto:linux-acpi-
> ow...@vger.kernel.org] On Behalf Of Benjamin Tissoires
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> [I just realised Ctrl+enter means "send" for gmail, see the end of the
> answers]
> 
> On Mon, Jul 11, 2016 at 1:42 PM, Benjamin Tissoires
>  wrote:
> > On Mon, Jul 11, 2016 at 5:20 AM, Zheng, Lv  wrote:
> >> Hi,
> >>
> >>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> >>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI
> control
> >>> method lid device restrictions
> >>>
> >>> Hi,
> >>>
> >>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> >>> > There are many AML tables reporting wrong initial lid state, and
> some of
> >>> > them never reports lid 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 open event;
> >>> > 3. Userspace should only take action against the close event which is
> >>> >reliable, always sent after a real lid close.
> >>> > This patch adds documentation of the usage model.
> >>> >
> >>> > Link: https://lkml.org/2016/3/7/460
> >>> > Link: https://github.com/systemd/systemd/issues/2087
> >>> > Signed-off-by: Lv Zheng 
> >>> > Cc: Bastien Nocera: 
> >>> > Cc: Benjamin Tissoires 
> >>> > Cc: linux-in...@vger.kernel.org
> >>> > ---
> >>> >  Documentation/acpi/acpi-lid.txt |   62
> >>> +++
> >>> >  1 file changed, 62 insertions(+)
> >>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >>> >
> >>> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-
> >>> lid.txt
> >>> > new file mode 100644
> >>> > index 000..7e4f7ed
> >>> > --- /dev/null
> >>> > +++ b/Documentation/acpi/acpi-lid.txt
> >>> > @@ -0,0 +1,62 @@
> >>> > +Usage Model of the ACPI Control Method Lid Device
> >>> > +
> >>> > +Copyright (C) 2016, Intel Corporation
> >>> > +Author: Lv Zheng 
> >>> > +
> >>> > +
> >>> > +Abstract:
> >>> > +
> >>> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using
> >>> a
> >>> > +control method lid device. To implement this, the AML tables issue
> >>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> >>> > +changed. The _LID control method for the lid device must be
> >>> implemented to
> >>> > +report the "current" state of the lid as either "opened" or "closed".
> >>> > +
> >>> > +This document describes the restrictions and the expections of the
> >>> Linux
> >>> > +ACPI lid device driver.
> >>> > +
> >>> > +
> >>> > +1. Restrictions of the returning value of the _LID control method
> >>> > +
> >>> > +The _LID control method is described to return the "current" lid
> state.
> >>> > +However the word of "current" has ambiguity, many AML tables
> return
> >>> the lid
> >>> > +state upon the last lid notification instead of returning the lid state
> >>> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> >>> > +control method is evaluated during the runtime, the problem is its
> >>> initial
> >>> > +returning value. When the AML tables implement this control
> method
> >>> with
> >>> > +cached value, the initial returning value is likely not reliable. There
> are
> >>> > +simply so many examples always retuning "closed" as initial lid
> state.
> >>> > +
> >>> > +2. Restrictions of the lid state change notifications
> >>> > +
> >>> > +There are many AML tables never notifying when the lid device
> state is
> >>> > +changed to "opened".

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
> <dmitry.torok...@gmail.com> wrote:
> > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
> >> > There are many AML tables reporting wrong initial lid state, and some
> of
> >> > them never reports lid 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 open event;
> >> > 3. Userspace should only take action against the close event which is
> >> >reliable, always sent after a real lid close.
> >> > This patch adds documentation of the usage model.
> >> >
> >> > Link: https://lkml.org/2016/3/7/460
> >> > Link: https://github.com/systemd/systemd/issues/2087
> >> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> >> > Cc: Bastien Nocera: <had...@hadess.net>
> >> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> >> > Cc: linux-in...@vger.kernel.org
> >> > ---
> >> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >> >  1 file changed, 62 insertions(+)
> >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> >
> >> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> >> > new file mode 100644
> >> > index 000..7e4f7ed
> >> > --- /dev/null
> >> > +++ b/Documentation/acpi/acpi-lid.txt
> >> > @@ -0,0 +1,62 @@
> >> > +Usage Model of the ACPI Control Method Lid Device
> >> > +
> >> > +Copyright (C) 2016, Intel Corporation
> >> > +Author: Lv Zheng <lv.zh...@intel.com>
> >> > +
> >> > +
> >> > +Abstract:
> >> > +
> >> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> >> > +control method lid device. To implement this, the AML tables issue
> >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> >> > +changed. The _LID control method for the lid device must be
> implemented to
> >> > +report the "current" state of the lid as either "opened" or "closed".
> >> > +
> >> > +This document describes the restrictions and the expections of the
> Linux
> >> > +ACPI lid device driver.
> >> > +
> >> > +
> >> > +1. Restrictions of the returning value of the _LID control method
> >> > +
> >> > +The _LID control method is described to return the "current" lid
> state.
> >> > +However the word of "current" has ambiguity, many AML tables
> return the lid
> >> > +state upon the last lid notification instead of returning the lid state
> >> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> >> > +control method is evaluated during the runtime, the problem is its
> initial
> >> > +returning value. When the AML tables implement this control
> method with
> >> > +cached value, the initial returning value is likely not reliable. There
> are
> >> > +simply so many examples always retuning "closed" as initial lid state.
> >> > +
> >> > +2. Restrictions of the lid state change notifications
> >> > +
> >> > +There are many AML tables never notifying when the lid device state
> is
> >> > +changed to "opened". But it is ensured that the AML tables always
> notify
> >> > +"closed" when the lid state is changed to "closed". This is normally
> used
> >> > +to trigger some system power saving operations on Windows. Since
> it is
> >> > +fully tested, this notification is reliable for all AML tables.
> >> > +
> >> > +3. Expections for the userspace users of the ACPI lid device driver
> >> > +
> >> > +The userspace programs should stop relying on
> >> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
>  wrote:
> > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> >> > There are many AML tables reporting wrong initial lid state, and some
> of
> >> > them never reports lid 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 open event;
> >> > 3. Userspace should only take action against the close event which is
> >> >reliable, always sent after a real lid close.
> >> > This patch adds documentation of the usage model.
> >> >
> >> > Link: https://lkml.org/2016/3/7/460
> >> > Link: https://github.com/systemd/systemd/issues/2087
> >> > Signed-off-by: Lv Zheng 
> >> > Cc: Bastien Nocera: 
> >> > Cc: Benjamin Tissoires 
> >> > Cc: linux-in...@vger.kernel.org
> >> > ---
> >> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >> >  1 file changed, 62 insertions(+)
> >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> >
> >> > diff --git a/Documentation/acpi/acpi-lid.txt
> b/Documentation/acpi/acpi-lid.txt
> >> > new file mode 100644
> >> > index 000..7e4f7ed
> >> > --- /dev/null
> >> > +++ b/Documentation/acpi/acpi-lid.txt
> >> > @@ -0,0 +1,62 @@
> >> > +Usage Model of the ACPI Control Method Lid Device
> >> > +
> >> > +Copyright (C) 2016, Intel Corporation
> >> > +Author: Lv Zheng 
> >> > +
> >> > +
> >> > +Abstract:
> >> > +
> >> > +Platforms containing lids convey lid state (open/close) to OSPMs
> using a
> >> > +control method lid device. To implement this, the AML tables issue
> >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state
> has
> >> > +changed. The _LID control method for the lid device must be
> implemented to
> >> > +report the "current" state of the lid as either "opened" or "closed".
> >> > +
> >> > +This document describes the restrictions and the expections of the
> Linux
> >> > +ACPI lid device driver.
> >> > +
> >> > +
> >> > +1. Restrictions of the returning value of the _LID control method
> >> > +
> >> > +The _LID control method is described to return the "current" lid
> state.
> >> > +However the word of "current" has ambiguity, many AML tables
> return the lid
> >> > +state upon the last lid notification instead of returning the lid state
> >> > +upon the last _LID evaluation. There won't be difference when the
> _LID
> >> > +control method is evaluated during the runtime, the problem is its
> initial
> >> > +returning value. When the AML tables implement this control
> method with
> >> > +cached value, the initial returning value is likely not reliable. There
> are
> >> > +simply so many examples always retuning "closed" as initial lid state.
> >> > +
> >> > +2. Restrictions of the lid state change notifications
> >> > +
> >> > +There are many AML tables never notifying when the lid device state
> is
> >> > +changed to "opened". But it is ensured that the AML tables always
> notify
> >> > +"closed" when the lid state is changed to "closed". This is normally
> used
> >> > +to trigger some system power saving operations on Windows. Since
> it is
> >> > +fully tested, this notification is reliable for all AML tables.
> >> > +
> >> > +3. Expections for the userspace users of the ACPI lid device driver
> >> > +
> >> > +The userspace programs should stop relying on
> >> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is
> only
> >> > +used for the validation purpose.
> >>
> >> I'd say: this file actually calls the _LID method described above. And
> >> g

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi,

> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Mon, 2016-07-11 at 03:20 +, Zheng, Lv wrote:
> >
> 
> > > This worries me as there is no plan after "During the period the
> > > userspace hasn't been switched to use the new event".
> > >
> > > I really hope you'll keep sending SW_LID for reliable LID
> > > platforms,
> > > and not remove it entirely as you will break platforms.
> >
> > [Lv Zheng]
> > We won't remove SW_LID from the kernel :).
> >
> > And we haven't removed SW_LID from the acpi button driver.
> > We'll just stop sending "initial lid state" from acpi button driver,
> > i.e., the behavior carried out by "button.lid_init_state=ignore".
> >
> > Maybe it is not sufficient, after the userspace has been changed to
> > support the new event, we should stop sending SW_LID from acpi button
> > driver.
> 
> For the affected devices? Sure, but I don't think that's a reasonable
> thing to do for "all" the devices. We have a majority of laptops where
> this isn't a problem, and it's not even a problem any more on one of
> the devices that triggered this discussion (there's a patch for make
> the LID status match reality for the Surface 3).
[Lv Zheng] 
It looks, even with this fixed, there are tables never generating "lid open" 
event.
Thus the lid notification is definitely not a "switch event".

Thanks and best regards
-Lv

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-12 Thread Zheng, Lv

Hi,

> From: Bastien Nocera [mailto:had...@hadess.net]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> On Mon, 2016-07-11 at 03:20 +, Zheng, Lv wrote:
> >
> 
> > > This worries me as there is no plan after "During the period the
> > > userspace hasn't been switched to use the new event".
> > >
> > > I really hope you'll keep sending SW_LID for reliable LID
> > > platforms,
> > > and not remove it entirely as you will break platforms.
> >
> > [Lv Zheng]
> > We won't remove SW_LID from the kernel :).
> >
> > And we haven't removed SW_LID from the acpi button driver.
> > We'll just stop sending "initial lid state" from acpi button driver,
> > i.e., the behavior carried out by "button.lid_init_state=ignore".
> >
> > Maybe it is not sufficient, after the userspace has been changed to
> > support the new event, we should stop sending SW_LID from acpi button
> > driver.
> 
> For the affected devices? Sure, but I don't think that's a reasonable
> thing to do for "all" the devices. We have a majority of laptops where
> this isn't a problem, and it's not even a problem any more on one of
> the devices that triggered this discussion (there's a patch for make
> the LID status match reality for the Surface 3).
[Lv Zheng] 
It looks, even with this fixed, there are tables never generating "lid open" 
event.
Thus the lid notification is definitely not a "switch event".

Thanks and best regards
-Lv

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Dmitry Torokhov

On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
>  wrote:
> > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> >> > There are many AML tables reporting wrong initial lid state, and some of
> >> > them never reports lid 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 open event;
> >> > 3. Userspace should only take action against the close event which is
> >> >reliable, always sent after a real lid close.
> >> > This patch adds documentation of the usage model.
> >> >
> >> > Link: https://lkml.org/2016/3/7/460
> >> > Link: https://github.com/systemd/systemd/issues/2087
> >> > Signed-off-by: Lv Zheng 
> >> > Cc: Bastien Nocera: 
> >> > Cc: Benjamin Tissoires 
> >> > Cc: linux-in...@vger.kernel.org
> >> > ---
> >> >  Documentation/acpi/acpi-lid.txt |   62 
> >> > +++
> >> >  1 file changed, 62 insertions(+)
> >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> >
> >> > diff --git a/Documentation/acpi/acpi-lid.txt 
> >> > b/Documentation/acpi/acpi-lid.txt
> >> > new file mode 100644
> >> > index 000..7e4f7ed
> >> > --- /dev/null
> >> > +++ b/Documentation/acpi/acpi-lid.txt
> >> > @@ -0,0 +1,62 @@
> >> > +Usage Model of the ACPI Control Method Lid Device
> >> > +
> >> > +Copyright (C) 2016, Intel Corporation
> >> > +Author: Lv Zheng 
> >> > +
> >> > +
> >> > +Abstract:
> >> > +
> >> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
> >> > +control method lid device. To implement this, the AML tables issue
> >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> >> > +changed. The _LID control method for the lid device must be implemented 
> >> > to
> >> > +report the "current" state of the lid as either "opened" or "closed".
> >> > +
> >> > +This document describes the restrictions and the expections of the Linux
> >> > +ACPI lid device driver.
> >> > +
> >> > +
> >> > +1. Restrictions of the returning value of the _LID control method
> >> > +
> >> > +The _LID control method is described to return the "current" lid state.
> >> > +However the word of "current" has ambiguity, many AML tables return the 
> >> > lid
> >> > +state upon the last lid notification instead of returning the lid state
> >> > +upon the last _LID evaluation. There won't be difference when the _LID
> >> > +control method is evaluated during the runtime, the problem is its 
> >> > initial
> >> > +returning value. When the AML tables implement this control method with
> >> > +cached value, the initial returning value is likely not reliable. There 
> >> > are
> >> > +simply so many examples always retuning "closed" as initial lid state.
> >> > +
> >> > +2. Restrictions of the lid state change notifications
> >> > +
> >> > +There are many AML tables never notifying when the lid device state is
> >> > +changed to "opened". But it is ensured that the AML tables always notify
> >> > +"closed" when the lid state is changed to "closed". This is normally 
> >> > used
> >> > +to trigger some system power saving operations on Windows. Since it is
> >> > +fully tested, this notification is reliable for all AML tables.
> >> > +
> >> > +3. Expections for the userspace users of the ACPI lid device driver
> >> > +
> >> > +The userspace programs should stop relying on
> >> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
> >> > only
> >> > +used for the validation purpose.
> >>
> >> I'd say: this file actually calls the _LID method described above. And
> >> given the previous explanation, it is not reliable enough on some
> >> platforms. So it is strongly advised for user-space program to not
> >> solely rely on this file to determine the actual lid state.
> >>
> >> > +
> >> > +New userspace programs should rely on the lid "closed" notification to
> >> > +trigger some power saving operations and may stop taking actions 
> >> > according
> >> > +to the lid "opened" notification. A new input switch event - 
> >> > SW_ACPI_LID is
> >> > +prepared for the new userspace to implement this ACPI control method lid
> >> > +device specific logics.
> >>
> >> That's not entirely what we discussed before (to prevent regressions):
> >> - if the device doesn't have reliable LID switch state, then there
> >> would be the new input event, and so userspace should only rely on
> >> opened notifications.
> >> - if the device has reliable switch information, the new input event
> >> should not be exported and userspace knows that the current input
> >>

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Dmitry Torokhov

On Mon, Jul 11, 2016 at 01:34:08PM +0200, Benjamin Tissoires wrote:
> On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
>  wrote:
> > On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> >> Hi,
> >>
> >> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> >> > There are many AML tables reporting wrong initial lid state, and some of
> >> > them never reports lid 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 open event;
> >> > 3. Userspace should only take action against the close event which is
> >> >reliable, always sent after a real lid close.
> >> > This patch adds documentation of the usage model.
> >> >
> >> > Link: https://lkml.org/2016/3/7/460
> >> > Link: https://github.com/systemd/systemd/issues/2087
> >> > Signed-off-by: Lv Zheng 
> >> > Cc: Bastien Nocera: 
> >> > Cc: Benjamin Tissoires 
> >> > Cc: linux-in...@vger.kernel.org
> >> > ---
> >> >  Documentation/acpi/acpi-lid.txt |   62 
> >> > +++
> >> >  1 file changed, 62 insertions(+)
> >> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >> >
> >> > diff --git a/Documentation/acpi/acpi-lid.txt 
> >> > b/Documentation/acpi/acpi-lid.txt
> >> > new file mode 100644
> >> > index 000..7e4f7ed
> >> > --- /dev/null
> >> > +++ b/Documentation/acpi/acpi-lid.txt
> >> > @@ -0,0 +1,62 @@
> >> > +Usage Model of the ACPI Control Method Lid Device
> >> > +
> >> > +Copyright (C) 2016, Intel Corporation
> >> > +Author: Lv Zheng 
> >> > +
> >> > +
> >> > +Abstract:
> >> > +
> >> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
> >> > +control method lid device. To implement this, the AML tables issue
> >> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> >> > +changed. The _LID control method for the lid device must be implemented 
> >> > to
> >> > +report the "current" state of the lid as either "opened" or "closed".
> >> > +
> >> > +This document describes the restrictions and the expections of the Linux
> >> > +ACPI lid device driver.
> >> > +
> >> > +
> >> > +1. Restrictions of the returning value of the _LID control method
> >> > +
> >> > +The _LID control method is described to return the "current" lid state.
> >> > +However the word of "current" has ambiguity, many AML tables return the 
> >> > lid
> >> > +state upon the last lid notification instead of returning the lid state
> >> > +upon the last _LID evaluation. There won't be difference when the _LID
> >> > +control method is evaluated during the runtime, the problem is its 
> >> > initial
> >> > +returning value. When the AML tables implement this control method with
> >> > +cached value, the initial returning value is likely not reliable. There 
> >> > are
> >> > +simply so many examples always retuning "closed" as initial lid state.
> >> > +
> >> > +2. Restrictions of the lid state change notifications
> >> > +
> >> > +There are many AML tables never notifying when the lid device state is
> >> > +changed to "opened". But it is ensured that the AML tables always notify
> >> > +"closed" when the lid state is changed to "closed". This is normally 
> >> > used
> >> > +to trigger some system power saving operations on Windows. Since it is
> >> > +fully tested, this notification is reliable for all AML tables.
> >> > +
> >> > +3. Expections for the userspace users of the ACPI lid device driver
> >> > +
> >> > +The userspace programs should stop relying on
> >> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
> >> > only
> >> > +used for the validation purpose.
> >>
> >> I'd say: this file actually calls the _LID method described above. And
> >> given the previous explanation, it is not reliable enough on some
> >> platforms. So it is strongly advised for user-space program to not
> >> solely rely on this file to determine the actual lid state.
> >>
> >> > +
> >> > +New userspace programs should rely on the lid "closed" notification to
> >> > +trigger some power saving operations and may stop taking actions 
> >> > according
> >> > +to the lid "opened" notification. A new input switch event - 
> >> > SW_ACPI_LID is
> >> > +prepared for the new userspace to implement this ACPI control method lid
> >> > +device specific logics.
> >>
> >> That's not entirely what we discussed before (to prevent regressions):
> >> - if the device doesn't have reliable LID switch state, then there
> >> would be the new input event, and so userspace should only rely on
> >> opened notifications.
> >> - if the device has reliable switch information, the new input event
> >> should not be exported and userspace knows that the current input
> >> switch event is reliable.
> >>
> >> Also, using a new "switch" event is a terrible idea. Switches have a
> >> state (open/close) and you are

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Benjamin Tissoires

[I just realised Ctrl+enter means "send" for gmail, see the end of the answers]

On Mon, Jul 11, 2016 at 1:42 PM, Benjamin Tissoires
<benjamin.tissoi...@gmail.com> wrote:
> On Mon, Jul 11, 2016 at 5:20 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
>> Hi,
>>
>>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>>> method lid device restrictions
>>>
>>> Hi,
>>>
>>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
>>> > There are many AML tables reporting wrong initial lid state, and some of
>>> > them never reports lid 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 open event;
>>> > 3. Userspace should only take action against the close event which is
>>> >reliable, always sent after a real lid close.
>>> > This patch adds documentation of the usage model.
>>> >
>>> > Link: https://lkml.org/2016/3/7/460
>>> > Link: https://github.com/systemd/systemd/issues/2087
>>> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
>>> > Cc: Bastien Nocera: <had...@hadess.net>
>>> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
>>> > Cc: linux-in...@vger.kernel.org
>>> > ---
>>> >  Documentation/acpi/acpi-lid.txt |   62
>>> +++
>>> >  1 file changed, 62 insertions(+)
>>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
>>> >
>>> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
>>> lid.txt
>>> > new file mode 100644
>>> > index 000..7e4f7ed
>>> > --- /dev/null
>>> > +++ b/Documentation/acpi/acpi-lid.txt
>>> > @@ -0,0 +1,62 @@
>>> > +Usage Model of the ACPI Control Method Lid Device
>>> > +
>>> > +Copyright (C) 2016, Intel Corporation
>>> > +Author: Lv Zheng <lv.zh...@intel.com>
>>> > +
>>> > +
>>> > +Abstract:
>>> > +
>>> > +Platforms containing lids convey lid state (open/close) to OSPMs using
>>> a
>>> > +control method lid device. To implement this, the AML tables issue
>>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
>>> > +changed. The _LID control method for the lid device must be
>>> implemented to
>>> > +report the "current" state of the lid as either "opened" or "closed".
>>> > +
>>> > +This document describes the restrictions and the expections of the
>>> Linux
>>> > +ACPI lid device driver.
>>> > +
>>> > +
>>> > +1. Restrictions of the returning value of the _LID control method
>>> > +
>>> > +The _LID control method is described to return the "current" lid state.
>>> > +However the word of "current" has ambiguity, many AML tables return
>>> the lid
>>> > +state upon the last lid notification instead of returning the lid state
>>> > +upon the last _LID evaluation. There won't be difference when the _LID
>>> > +control method is evaluated during the runtime, the problem is its
>>> initial
>>> > +returning value. When the AML tables implement this control method
>>> with
>>> > +cached value, the initial returning value is likely not reliable. There 
>>> > are
>>> > +simply so many examples always retuning "closed" as initial lid state.
>>> > +
>>> > +2. Restrictions of the lid state change notifications
>>> > +
>>> > +There are many AML tables never notifying when the lid device state is
>>> > +changed to "opened". But it is ensured that the AML tables always
>>> notify
>>> > +"closed" when the lid state is changed to "closed". This is normally used
>>> > +to trigger some system power saving operations on Windows. Since it is
>>> > +fully tested, this notification is reliable for all AML tables.
>>> > +
>>> > +3. Expections for the userspace users of the ACPI lid device driver
>>> > +
>>> > +The us

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Benjamin Tissoires

[I just realised Ctrl+enter means "send" for gmail, see the end of the answers]

On Mon, Jul 11, 2016 at 1:42 PM, Benjamin Tissoires
 wrote:
> On Mon, Jul 11, 2016 at 5:20 AM, Zheng, Lv  wrote:
>> Hi,
>>
>>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>>> method lid device restrictions
>>>
>>> Hi,
>>>
>>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
>>> > There are many AML tables reporting wrong initial lid state, and some of
>>> > them never reports lid 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 open event;
>>> > 3. Userspace should only take action against the close event which is
>>> >reliable, always sent after a real lid close.
>>> > This patch adds documentation of the usage model.
>>> >
>>> > Link: https://lkml.org/2016/3/7/460
>>> > Link: https://github.com/systemd/systemd/issues/2087
>>> > Signed-off-by: Lv Zheng 
>>> > Cc: Bastien Nocera: 
>>> > Cc: Benjamin Tissoires 
>>> > Cc: linux-in...@vger.kernel.org
>>> > ---
>>> >  Documentation/acpi/acpi-lid.txt |   62
>>> +++
>>> >  1 file changed, 62 insertions(+)
>>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
>>> >
>>> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
>>> lid.txt
>>> > new file mode 100644
>>> > index 000..7e4f7ed
>>> > --- /dev/null
>>> > +++ b/Documentation/acpi/acpi-lid.txt
>>> > @@ -0,0 +1,62 @@
>>> > +Usage Model of the ACPI Control Method Lid Device
>>> > +
>>> > +Copyright (C) 2016, Intel Corporation
>>> > +Author: Lv Zheng 
>>> > +
>>> > +
>>> > +Abstract:
>>> > +
>>> > +Platforms containing lids convey lid state (open/close) to OSPMs using
>>> a
>>> > +control method lid device. To implement this, the AML tables issue
>>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
>>> > +changed. The _LID control method for the lid device must be
>>> implemented to
>>> > +report the "current" state of the lid as either "opened" or "closed".
>>> > +
>>> > +This document describes the restrictions and the expections of the
>>> Linux
>>> > +ACPI lid device driver.
>>> > +
>>> > +
>>> > +1. Restrictions of the returning value of the _LID control method
>>> > +
>>> > +The _LID control method is described to return the "current" lid state.
>>> > +However the word of "current" has ambiguity, many AML tables return
>>> the lid
>>> > +state upon the last lid notification instead of returning the lid state
>>> > +upon the last _LID evaluation. There won't be difference when the _LID
>>> > +control method is evaluated during the runtime, the problem is its
>>> initial
>>> > +returning value. When the AML tables implement this control method
>>> with
>>> > +cached value, the initial returning value is likely not reliable. There 
>>> > are
>>> > +simply so many examples always retuning "closed" as initial lid state.
>>> > +
>>> > +2. Restrictions of the lid state change notifications
>>> > +
>>> > +There are many AML tables never notifying when the lid device state is
>>> > +changed to "opened". But it is ensured that the AML tables always
>>> notify
>>> > +"closed" when the lid state is changed to "closed". This is normally used
>>> > +to trigger some system power saving operations on Windows. Since it is
>>> > +fully tested, this notification is reliable for all AML tables.
>>> > +
>>> > +3. Expections for the userspace users of the ACPI lid device driver
>>> > +
>>> > +The userspace programs should stop relying on
>>> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
>>> > only
>>> > +used for the validation purpose

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Benjamin Tissoires

On Mon, Jul 11, 2016 at 5:20 AM, Zheng, Lv <lv.zh...@intel.com> wrote:
> Hi,
>
>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> Hi,
>>
>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
>> > There are many AML tables reporting wrong initial lid state, and some of
>> > them never reports lid 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 open event;
>> > 3. Userspace should only take action against the close event which is
>> >reliable, always sent after a real lid close.
>> > This patch adds documentation of the usage model.
>> >
>> > Link: https://lkml.org/2016/3/7/460
>> > Link: https://github.com/systemd/systemd/issues/2087
>> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
>> > Cc: Bastien Nocera: <had...@hadess.net>
>> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
>> > Cc: linux-in...@vger.kernel.org
>> > ---
>> >  Documentation/acpi/acpi-lid.txt |   62
>> +++
>> >  1 file changed, 62 insertions(+)
>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> >
>> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
>> lid.txt
>> > new file mode 100644
>> > index 000..7e4f7ed
>> > --- /dev/null
>> > +++ b/Documentation/acpi/acpi-lid.txt
>> > @@ -0,0 +1,62 @@
>> > +Usage Model of the ACPI Control Method Lid Device
>> > +
>> > +Copyright (C) 2016, Intel Corporation
>> > +Author: Lv Zheng <lv.zh...@intel.com>
>> > +
>> > +
>> > +Abstract:
>> > +
>> > +Platforms containing lids convey lid state (open/close) to OSPMs using
>> a
>> > +control method lid device. To implement this, the AML tables issue
>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
>> > +changed. The _LID control method for the lid device must be
>> implemented to
>> > +report the "current" state of the lid as either "opened" or "closed".
>> > +
>> > +This document describes the restrictions and the expections of the
>> Linux
>> > +ACPI lid device driver.
>> > +
>> > +
>> > +1. Restrictions of the returning value of the _LID control method
>> > +
>> > +The _LID control method is described to return the "current" lid state.
>> > +However the word of "current" has ambiguity, many AML tables return
>> the lid
>> > +state upon the last lid notification instead of returning the lid state
>> > +upon the last _LID evaluation. There won't be difference when the _LID
>> > +control method is evaluated during the runtime, the problem is its
>> initial
>> > +returning value. When the AML tables implement this control method
>> with
>> > +cached value, the initial returning value is likely not reliable. There 
>> > are
>> > +simply so many examples always retuning "closed" as initial lid state.
>> > +
>> > +2. Restrictions of the lid state change notifications
>> > +
>> > +There are many AML tables never notifying when the lid device state is
>> > +changed to "opened". But it is ensured that the AML tables always
>> notify
>> > +"closed" when the lid state is changed to "closed". This is normally used
>> > +to trigger some system power saving operations on Windows. Since it is
>> > +fully tested, this notification is reliable for all AML tables.
>> > +
>> > +3. Expections for the userspace users of the ACPI lid device driver
>> > +
>> > +The userspace programs should stop relying on
>> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
>> > only
>> > +used for the validation purpose.
>>
>> I'd say: this file actually calls the _LID method described above. And
>> given the previous explanation, it is not reliable enough on some
>> platforms. So it is strongly advised for user-space program to not
>> solely rely on this file to determine the actual lid state.
> [Lv Zheng]
> OK.
>
>>
>

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Benjamin Tissoires

On Mon, Jul 11, 2016 at 5:20 AM, Zheng, Lv  wrote:
> Hi,
>
>> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
>> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
>> method lid device restrictions
>>
>> Hi,
>>
>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
>> > There are many AML tables reporting wrong initial lid state, and some of
>> > them never reports lid 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 open event;
>> > 3. Userspace should only take action against the close event which is
>> >reliable, always sent after a real lid close.
>> > This patch adds documentation of the usage model.
>> >
>> > Link: https://lkml.org/2016/3/7/460
>> > Link: https://github.com/systemd/systemd/issues/2087
>> > Signed-off-by: Lv Zheng 
>> > Cc: Bastien Nocera: 
>> > Cc: Benjamin Tissoires 
>> > Cc: linux-in...@vger.kernel.org
>> > ---
>> >  Documentation/acpi/acpi-lid.txt |   62
>> +++
>> >  1 file changed, 62 insertions(+)
>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> >
>> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
>> lid.txt
>> > new file mode 100644
>> > index 000..7e4f7ed
>> > --- /dev/null
>> > +++ b/Documentation/acpi/acpi-lid.txt
>> > @@ -0,0 +1,62 @@
>> > +Usage Model of the ACPI Control Method Lid Device
>> > +
>> > +Copyright (C) 2016, Intel Corporation
>> > +Author: Lv Zheng 
>> > +
>> > +
>> > +Abstract:
>> > +
>> > +Platforms containing lids convey lid state (open/close) to OSPMs using
>> a
>> > +control method lid device. To implement this, the AML tables issue
>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
>> > +changed. The _LID control method for the lid device must be
>> implemented to
>> > +report the "current" state of the lid as either "opened" or "closed".
>> > +
>> > +This document describes the restrictions and the expections of the
>> Linux
>> > +ACPI lid device driver.
>> > +
>> > +
>> > +1. Restrictions of the returning value of the _LID control method
>> > +
>> > +The _LID control method is described to return the "current" lid state.
>> > +However the word of "current" has ambiguity, many AML tables return
>> the lid
>> > +state upon the last lid notification instead of returning the lid state
>> > +upon the last _LID evaluation. There won't be difference when the _LID
>> > +control method is evaluated during the runtime, the problem is its
>> initial
>> > +returning value. When the AML tables implement this control method
>> with
>> > +cached value, the initial returning value is likely not reliable. There 
>> > are
>> > +simply so many examples always retuning "closed" as initial lid state.
>> > +
>> > +2. Restrictions of the lid state change notifications
>> > +
>> > +There are many AML tables never notifying when the lid device state is
>> > +changed to "opened". But it is ensured that the AML tables always
>> notify
>> > +"closed" when the lid state is changed to "closed". This is normally used
>> > +to trigger some system power saving operations on Windows. Since it is
>> > +fully tested, this notification is reliable for all AML tables.
>> > +
>> > +3. Expections for the userspace users of the ACPI lid device driver
>> > +
>> > +The userspace programs should stop relying on
>> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
>> > only
>> > +used for the validation purpose.
>>
>> I'd say: this file actually calls the _LID method described above. And
>> given the previous explanation, it is not reliable enough on some
>> platforms. So it is strongly advised for user-space program to not
>> solely rely on this file to determine the actual lid state.
> [Lv Zheng]
> OK.
>
>>
>> > +
>> > +New userspace programs should rely on the lid "closed" notification to
>> > +trigger some power saving operations a

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Benjamin Tissoires

On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
 wrote:
> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
>> Hi,
>>
>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
>> > There are many AML tables reporting wrong initial lid state, and some of
>> > them never reports lid 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 open event;
>> > 3. Userspace should only take action against the close event which is
>> >reliable, always sent after a real lid close.
>> > This patch adds documentation of the usage model.
>> >
>> > Link: https://lkml.org/2016/3/7/460
>> > Link: https://github.com/systemd/systemd/issues/2087
>> > Signed-off-by: Lv Zheng 
>> > Cc: Bastien Nocera: 
>> > Cc: Benjamin Tissoires 
>> > Cc: linux-in...@vger.kernel.org
>> > ---
>> >  Documentation/acpi/acpi-lid.txt |   62 
>> > +++
>> >  1 file changed, 62 insertions(+)
>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> >
>> > diff --git a/Documentation/acpi/acpi-lid.txt 
>> > b/Documentation/acpi/acpi-lid.txt
>> > new file mode 100644
>> > index 000..7e4f7ed
>> > --- /dev/null
>> > +++ b/Documentation/acpi/acpi-lid.txt
>> > @@ -0,0 +1,62 @@
>> > +Usage Model of the ACPI Control Method Lid Device
>> > +
>> > +Copyright (C) 2016, Intel Corporation
>> > +Author: Lv Zheng 
>> > +
>> > +
>> > +Abstract:
>> > +
>> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
>> > +control method lid device. To implement this, the AML tables issue
>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
>> > +changed. The _LID control method for the lid device must be implemented to
>> > +report the "current" state of the lid as either "opened" or "closed".
>> > +
>> > +This document describes the restrictions and the expections of the Linux
>> > +ACPI lid device driver.
>> > +
>> > +
>> > +1. Restrictions of the returning value of the _LID control method
>> > +
>> > +The _LID control method is described to return the "current" lid state.
>> > +However the word of "current" has ambiguity, many AML tables return the 
>> > lid
>> > +state upon the last lid notification instead of returning the lid state
>> > +upon the last _LID evaluation. There won't be difference when the _LID
>> > +control method is evaluated during the runtime, the problem is its initial
>> > +returning value. When the AML tables implement this control method with
>> > +cached value, the initial returning value is likely not reliable. There 
>> > are
>> > +simply so many examples always retuning "closed" as initial lid state.
>> > +
>> > +2. Restrictions of the lid state change notifications
>> > +
>> > +There are many AML tables never notifying when the lid device state is
>> > +changed to "opened". But it is ensured that the AML tables always notify
>> > +"closed" when the lid state is changed to "closed". This is normally used
>> > +to trigger some system power saving operations on Windows. Since it is
>> > +fully tested, this notification is reliable for all AML tables.
>> > +
>> > +3. Expections for the userspace users of the ACPI lid device driver
>> > +
>> > +The userspace programs should stop relying on
>> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
>> > only
>> > +used for the validation purpose.
>>
>> I'd say: this file actually calls the _LID method described above. And
>> given the previous explanation, it is not reliable enough on some
>> platforms. So it is strongly advised for user-space program to not
>> solely rely on this file to determine the actual lid state.
>>
>> > +
>> > +New userspace programs should rely on the lid "closed" notification to
>> > +trigger some power saving operations and may stop taking actions according
>> > +to the lid "opened" notification. A new input switch event - SW_ACPI_LID 
>> > is
>> > +prepared for the new userspace to implement this ACPI control method lid
>> > +device specific logics.
>>
>> That's not entirely what we discussed before (to prevent regressions):
>> - if the device doesn't have reliable LID switch state, then there
>> would be the new input event, and so userspace should only rely on
>> opened notifications.
>> - if the device has reliable switch information, the new input event
>> should not be exported and userspace knows that the current input
>> switch event is reliable.
>>
>> Also, using a new "switch" event is a terrible idea. Switches have a
>> state (open/close) and you are using this to forward a single open
>> event. So using a switch just allows you to say to userspace you are
>> using the "new" LID meaning, but you'll still have to manually reset

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Benjamin Tissoires

On Fri, Jul 8, 2016 at 7:51 PM, Dmitry Torokhov
 wrote:
> On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
>> Hi,
>>
>> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
>> > There are many AML tables reporting wrong initial lid state, and some of
>> > them never reports lid 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 open event;
>> > 3. Userspace should only take action against the close event which is
>> >reliable, always sent after a real lid close.
>> > This patch adds documentation of the usage model.
>> >
>> > Link: https://lkml.org/2016/3/7/460
>> > Link: https://github.com/systemd/systemd/issues/2087
>> > Signed-off-by: Lv Zheng 
>> > Cc: Bastien Nocera: 
>> > Cc: Benjamin Tissoires 
>> > Cc: linux-in...@vger.kernel.org
>> > ---
>> >  Documentation/acpi/acpi-lid.txt |   62 
>> > +++
>> >  1 file changed, 62 insertions(+)
>> >  create mode 100644 Documentation/acpi/acpi-lid.txt
>> >
>> > diff --git a/Documentation/acpi/acpi-lid.txt 
>> > b/Documentation/acpi/acpi-lid.txt
>> > new file mode 100644
>> > index 000..7e4f7ed
>> > --- /dev/null
>> > +++ b/Documentation/acpi/acpi-lid.txt
>> > @@ -0,0 +1,62 @@
>> > +Usage Model of the ACPI Control Method Lid Device
>> > +
>> > +Copyright (C) 2016, Intel Corporation
>> > +Author: Lv Zheng 
>> > +
>> > +
>> > +Abstract:
>> > +
>> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
>> > +control method lid device. To implement this, the AML tables issue
>> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
>> > +changed. The _LID control method for the lid device must be implemented to
>> > +report the "current" state of the lid as either "opened" or "closed".
>> > +
>> > +This document describes the restrictions and the expections of the Linux
>> > +ACPI lid device driver.
>> > +
>> > +
>> > +1. Restrictions of the returning value of the _LID control method
>> > +
>> > +The _LID control method is described to return the "current" lid state.
>> > +However the word of "current" has ambiguity, many AML tables return the 
>> > lid
>> > +state upon the last lid notification instead of returning the lid state
>> > +upon the last _LID evaluation. There won't be difference when the _LID
>> > +control method is evaluated during the runtime, the problem is its initial
>> > +returning value. When the AML tables implement this control method with
>> > +cached value, the initial returning value is likely not reliable. There 
>> > are
>> > +simply so many examples always retuning "closed" as initial lid state.
>> > +
>> > +2. Restrictions of the lid state change notifications
>> > +
>> > +There are many AML tables never notifying when the lid device state is
>> > +changed to "opened". But it is ensured that the AML tables always notify
>> > +"closed" when the lid state is changed to "closed". This is normally used
>> > +to trigger some system power saving operations on Windows. Since it is
>> > +fully tested, this notification is reliable for all AML tables.
>> > +
>> > +3. Expections for the userspace users of the ACPI lid device driver
>> > +
>> > +The userspace programs should stop relying on
>> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is 
>> > only
>> > +used for the validation purpose.
>>
>> I'd say: this file actually calls the _LID method described above. And
>> given the previous explanation, it is not reliable enough on some
>> platforms. So it is strongly advised for user-space program to not
>> solely rely on this file to determine the actual lid state.
>>
>> > +
>> > +New userspace programs should rely on the lid "closed" notification to
>> > +trigger some power saving operations and may stop taking actions according
>> > +to the lid "opened" notification. A new input switch event - SW_ACPI_LID 
>> > is
>> > +prepared for the new userspace to implement this ACPI control method lid
>> > +device specific logics.
>>
>> That's not entirely what we discussed before (to prevent regressions):
>> - if the device doesn't have reliable LID switch state, then there
>> would be the new input event, and so userspace should only rely on
>> opened notifications.
>> - if the device has reliable switch information, the new input event
>> should not be exported and userspace knows that the current input
>> switch event is reliable.
>>
>> Also, using a new "switch" event is a terrible idea. Switches have a
>> state (open/close) and you are using this to forward a single open
>> event. So using a switch just allows you to say to userspace you are
>> using the "new" LID meaning, but you'll still have to manually reset
>> the switch and you will have to document how this event is not a
>> switch.
>>
>> Please use a simple KEY_LID_OPEN event you will

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Bastien Nocera

On Mon, 2016-07-11 at 03:20 +, Zheng, Lv wrote:
> 

> > This worries me as there is no plan after "During the period the
> > userspace hasn't been switched to use the new event".
> > 
> > I really hope you'll keep sending SW_LID for reliable LID
> > platforms,
> > and not remove it entirely as you will break platforms.
> 
> [Lv Zheng] 
> We won't remove SW_LID from the kernel :).
> 
> And we haven't removed SW_LID from the acpi button driver.
> We'll just stop sending "initial lid state" from acpi button driver,
> i.e., the behavior carried out by "button.lid_init_state=ignore".
> 
> Maybe it is not sufficient, after the userspace has been changed to
> support the new event, we should stop sending SW_LID from acpi button
> driver.

For the affected devices? Sure, but I don't think that's a reasonable
thing to do for "all" the devices. We have a majority of laptops where
this isn't a problem, and it's not even a problem any more on one of
the devices that triggered this discussion (there's a patch for make
the LID status match reality for the Surface 3).

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-11 Thread Bastien Nocera

On Mon, 2016-07-11 at 03:20 +, Zheng, Lv wrote:
> 

> > This worries me as there is no plan after "During the period the
> > userspace hasn't been switched to use the new event".
> > 
> > I really hope you'll keep sending SW_LID for reliable LID
> > platforms,
> > and not remove it entirely as you will break platforms.
> 
> [Lv Zheng] 
> We won't remove SW_LID from the kernel :).
> 
> And we haven't removed SW_LID from the acpi button driver.
> We'll just stop sending "initial lid state" from acpi button driver,
> i.e., the behavior carried out by "button.lid_init_state=ignore".
> 
> Maybe it is not sufficient, after the userspace has been changed to
> support the new event, we should stop sending SW_LID from acpi button
> driver.

For the affected devices? Sure, but I don't think that's a reasonable
thing to do for "all" the devices. We have a majority of laptops where
this isn't a problem, and it's not even a problem any more on one of
the devices that triggered this discussion (there's a patch for make
the LID status match reality for the Surface 3).

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-10 Thread Zheng, Lv

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng <lv.zh...@intel.com> wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid 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 open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng <lv.zh...@intel.com>
> > Cc: Bastien Nocera: <had...@hadess.net>
> > Cc: Benjamin Tissoires <benjamin.tissoi...@gmail.com>
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
> lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng <lv.zh...@intel.com>
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using
> a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be
> implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the
> Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return
> the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its
> initial
> > +returning value. When the AML tables implement this control method
> with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
[Lv Zheng] 
OK.

> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions
> according
> > +to the lid "opened" notification. A new input switch event -
> SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method
> lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-10 Thread Zheng, Lv

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid 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 open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > Cc: Benjamin Tissoires 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
> lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng 
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using
> a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be
> implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the
> Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return
> the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its
> initial
> > +returning value. When the AML tables implement this control method
> with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
[Lv Zheng] 
OK.

> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions
> according
> > +to the lid "opened" notification. A new input switch event -
> SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method
> lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent regressions):
> - if the device doesn't have reliable LID switch state, then there
> would be the new input event, and so userspace should

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-08 Thread Dmitry Torokhov

On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid 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 open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > Cc: Benjamin Tissoires 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62 
> > +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt 
> > b/Documentation/acpi/acpi-lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng 
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its initial
> > +returning value. When the AML tables implement this control method with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions according
> > +to the lid "opened" notification. A new input switch event - SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent regressions):
> - if the device doesn't have reliable LID switch state, then there
> would be the new input event, and so userspace should only rely on
> opened notifications.
> - if the device has reliable switch information, the new input event
> should not be exported and userspace knows that the current input
> switch event is reliable.
> 
> Also, using a new "switch" event is a terrible idea. Switches have a
> state (open/close) and you are using this to forward a single open
> event. So using a switch just allows you to say to userspace you are
> using the "new" LID meaning, but you'll still have to manually reset
> the switch and you will have to document how this event is not a
> switch.
> 
> Please use a simple KEY_LID_OPEN event you will send through
> [input_key_event(KEY_LID_OPEN, 1), input_sync(),
>

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-08 Thread Dmitry Torokhov

On Fri, Jul 08, 2016 at 11:17:39AM +0200, Benjamin Tissoires wrote:
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid 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 open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > Cc: Benjamin Tissoires 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62 
> > +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt 
> > b/Documentation/acpi/acpi-lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng 
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its initial
> > +returning value. When the AML tables implement this control method with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions according
> > +to the lid "opened" notification. A new input switch event - SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent regressions):
> - if the device doesn't have reliable LID switch state, then there
> would be the new input event, and so userspace should only rely on
> opened notifications.
> - if the device has reliable switch information, the new input event
> should not be exported and userspace knows that the current input
> switch event is reliable.
> 
> Also, using a new "switch" event is a terrible idea. Switches have a
> state (open/close) and you are using this to forward a single open
> event. So using a switch just allows you to say to userspace you are
> using the "new" LID meaning, but you'll still have to manually reset
> the switch and you will have to document how this event is not a
> switch.
> 
> Please use a simple KEY_LID_OPEN event you will send through
> [input_key_event(KEY_LID_OPEN, 1), input_sync(),
> input_key_event(KEY_LID_OPEN, 0), input_sync()], which userspace knows
> how to handle.
> 
> > +
> > +During the

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-08 Thread Benjamin Tissoires

Hi,

On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> There are many AML tables reporting wrong initial lid state, and some of
> them never reports lid 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 open event;
> 3. Userspace should only take action against the close event which is
>reliable, always sent after a real lid close.
> This patch adds documentation of the usage model.
>
> Link: https://lkml.org/2016/3/7/460
> Link: https://github.com/systemd/systemd/issues/2087
> Signed-off-by: Lv Zheng 
> Cc: Bastien Nocera: 
> Cc: Benjamin Tissoires 
> Cc: linux-in...@vger.kernel.org
> ---
>  Documentation/acpi/acpi-lid.txt |   62 
> +++
>  1 file changed, 62 insertions(+)
>  create mode 100644 Documentation/acpi/acpi-lid.txt
>
> diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-lid.txt
> new file mode 100644
> index 000..7e4f7ed
> --- /dev/null
> +++ b/Documentation/acpi/acpi-lid.txt
> @@ -0,0 +1,62 @@
> +Usage Model of the ACPI Control Method Lid Device
> +
> +Copyright (C) 2016, Intel Corporation
> +Author: Lv Zheng 
> +
> +
> +Abstract:
> +
> +Platforms containing lids convey lid state (open/close) to OSPMs using a
> +control method lid device. To implement this, the AML tables issue
> +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> +changed. The _LID control method for the lid device must be implemented to
> +report the "current" state of the lid as either "opened" or "closed".
> +
> +This document describes the restrictions and the expections of the Linux
> +ACPI lid device driver.
> +
> +
> +1. Restrictions of the returning value of the _LID control method
> +
> +The _LID control method is described to return the "current" lid state.
> +However the word of "current" has ambiguity, many AML tables return the lid
> +state upon the last lid notification instead of returning the lid state
> +upon the last _LID evaluation. There won't be difference when the _LID
> +control method is evaluated during the runtime, the problem is its initial
> +returning value. When the AML tables implement this control method with
> +cached value, the initial returning value is likely not reliable. There are
> +simply so many examples always retuning "closed" as initial lid state.
> +
> +2. Restrictions of the lid state change notifications
> +
> +There are many AML tables never notifying when the lid device state is
> +changed to "opened". But it is ensured that the AML tables always notify
> +"closed" when the lid state is changed to "closed". This is normally used
> +to trigger some system power saving operations on Windows. Since it is
> +fully tested, this notification is reliable for all AML tables.
> +
> +3. Expections for the userspace users of the ACPI lid device driver
> +
> +The userspace programs should stop relying on
> +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> +used for the validation purpose.

I'd say: this file actually calls the _LID method described above. And
given the previous explanation, it is not reliable enough on some
platforms. So it is strongly advised for user-space program to not
solely rely on this file to determine the actual lid state.

> +
> +New userspace programs should rely on the lid "closed" notification to
> +trigger some power saving operations and may stop taking actions according
> +to the lid "opened" notification. A new input switch event - SW_ACPI_LID is
> +prepared for the new userspace to implement this ACPI control method lid
> +device specific logics.

That's not entirely what we discussed before (to prevent regressions):
- if the device doesn't have reliable LID switch state, then there
would be the new input event, and so userspace should only rely on
opened notifications.
- if the device has reliable switch information, the new input event
should not be exported and userspace knows that the current input
switch event is reliable.

Also, using a new "switch" event is a terrible idea. Switches have a
state (open/close) and you are using this to forward a single open
event. So using a switch just allows you to say to userspace you are
using the "new" LID meaning, but you'll still have to manually reset
the switch and you will have to document how this event is not a
switch.

Please use a simple KEY_LID_OPEN event you will send through
[input_key_event(KEY_LID_OPEN, 1), input_sync(),
input_key_event(KEY_LID_OPEN, 0), input_sync()], which userspace knows
how to handle.

> +
> +During the period the userspace hasn't been switched to use the new
> +SW_ACPI_LID event, Linux users can use the following boot parameter to
> +handle possible issues:
> +

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-08 Thread Benjamin Tissoires

Hi,

On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> There are many AML tables reporting wrong initial lid state, and some of
> them never reports lid 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 open event;
> 3. Userspace should only take action against the close event which is
>reliable, always sent after a real lid close.
> This patch adds documentation of the usage model.
>
> Link: https://lkml.org/2016/3/7/460
> Link: https://github.com/systemd/systemd/issues/2087
> Signed-off-by: Lv Zheng 
> Cc: Bastien Nocera: 
> Cc: Benjamin Tissoires 
> Cc: linux-in...@vger.kernel.org
> ---
>  Documentation/acpi/acpi-lid.txt |   62 
> +++
>  1 file changed, 62 insertions(+)
>  create mode 100644 Documentation/acpi/acpi-lid.txt
>
> diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-lid.txt
> new file mode 100644
> index 000..7e4f7ed
> --- /dev/null
> +++ b/Documentation/acpi/acpi-lid.txt
> @@ -0,0 +1,62 @@
> +Usage Model of the ACPI Control Method Lid Device
> +
> +Copyright (C) 2016, Intel Corporation
> +Author: Lv Zheng 
> +
> +
> +Abstract:
> +
> +Platforms containing lids convey lid state (open/close) to OSPMs using a
> +control method lid device. To implement this, the AML tables issue
> +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> +changed. The _LID control method for the lid device must be implemented to
> +report the "current" state of the lid as either "opened" or "closed".
> +
> +This document describes the restrictions and the expections of the Linux
> +ACPI lid device driver.
> +
> +
> +1. Restrictions of the returning value of the _LID control method
> +
> +The _LID control method is described to return the "current" lid state.
> +However the word of "current" has ambiguity, many AML tables return the lid
> +state upon the last lid notification instead of returning the lid state
> +upon the last _LID evaluation. There won't be difference when the _LID
> +control method is evaluated during the runtime, the problem is its initial
> +returning value. When the AML tables implement this control method with
> +cached value, the initial returning value is likely not reliable. There are
> +simply so many examples always retuning "closed" as initial lid state.
> +
> +2. Restrictions of the lid state change notifications
> +
> +There are many AML tables never notifying when the lid device state is
> +changed to "opened". But it is ensured that the AML tables always notify
> +"closed" when the lid state is changed to "closed". This is normally used
> +to trigger some system power saving operations on Windows. Since it is
> +fully tested, this notification is reliable for all AML tables.
> +
> +3. Expections for the userspace users of the ACPI lid device driver
> +
> +The userspace programs should stop relying on
> +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> +used for the validation purpose.

I'd say: this file actually calls the _LID method described above. And
given the previous explanation, it is not reliable enough on some
platforms. So it is strongly advised for user-space program to not
solely rely on this file to determine the actual lid state.

> +
> +New userspace programs should rely on the lid "closed" notification to
> +trigger some power saving operations and may stop taking actions according
> +to the lid "opened" notification. A new input switch event - SW_ACPI_LID is
> +prepared for the new userspace to implement this ACPI control method lid
> +device specific logics.

That's not entirely what we discussed before (to prevent regressions):
- if the device doesn't have reliable LID switch state, then there
would be the new input event, and so userspace should only rely on
opened notifications.
- if the device has reliable switch information, the new input event
should not be exported and userspace knows that the current input
switch event is reliable.

Also, using a new "switch" event is a terrible idea. Switches have a
state (open/close) and you are using this to forward a single open
event. So using a switch just allows you to say to userspace you are
using the "new" LID meaning, but you'll still have to manually reset
the switch and you will have to document how this event is not a
switch.

Please use a simple KEY_LID_OPEN event you will send through
[input_key_event(KEY_LID_OPEN, 1), input_sync(),
input_key_event(KEY_LID_OPEN, 0), input_sync()], which userspace knows
how to handle.

> +
> +During the period the userspace hasn't been switched to use the new
> +SW_ACPI_LID event, Linux users can use the following boot parameter to
> +handle possible issues:
> +  button.lid_init_state=method:
> +   This is the default behavior of the Linux ACPI lid driver, Linux kernel
> +   reports the

[PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-07 Thread Lv Zheng

There are many AML tables reporting wrong initial lid state, and some of
them never reports lid 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 open event;
3. Userspace should only take action against the close event which is
   reliable, always sent after a real lid close.
This patch adds documentation of the usage model.

Link: https://lkml.org/2016/3/7/460
Link: https://github.com/systemd/systemd/issues/2087
Signed-off-by: Lv Zheng 
Cc: Bastien Nocera: 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
---
 Documentation/acpi/acpi-lid.txt |   62 +++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/acpi/acpi-lid.txt

diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-lid.txt
new file mode 100644
index 000..7e4f7ed
--- /dev/null
+++ b/Documentation/acpi/acpi-lid.txt
@@ -0,0 +1,62 @@
+Usage Model of the ACPI Control Method Lid Device
+
+Copyright (C) 2016, Intel Corporation
+Author: Lv Zheng 
+
+
+Abstract:
+
+Platforms containing lids convey lid state (open/close) to OSPMs using a
+control method lid device. To implement this, the AML tables issue
+Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
+changed. The _LID control method for the lid device must be implemented to
+report the "current" state of the lid as either "opened" or "closed".
+
+This document describes the restrictions and the expections of the Linux
+ACPI lid device driver.
+
+
+1. Restrictions of the returning value of the _LID control method
+
+The _LID control method is described to return the "current" lid state.
+However the word of "current" has ambiguity, many AML tables return the lid
+state upon the last lid notification instead of returning the lid state
+upon the last _LID evaluation. There won't be difference when the _LID
+control method is evaluated during the runtime, the problem is its initial
+returning value. When the AML tables implement this control method with
+cached value, the initial returning value is likely not reliable. There are
+simply so many examples always retuning "closed" as initial lid state.
+
+2. Restrictions of the lid state change notifications
+
+There are many AML tables never notifying when the lid device state is
+changed to "opened". But it is ensured that the AML tables always notify
+"closed" when the lid state is changed to "closed". This is normally used
+to trigger some system power saving operations on Windows. Since it is
+fully tested, this notification is reliable for all AML tables.
+
+3. Expections for the userspace users of the ACPI lid device driver
+
+The userspace programs should stop relying on
+/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
+used for the validation purpose.
+
+New userspace programs should rely on the lid "closed" notification to
+trigger some power saving operations and may stop taking actions according
+to the lid "opened" notification. A new input switch event - SW_ACPI_LID is
+prepared for the new userspace to implement this ACPI control method lid
+device specific logics.
+
+During the period the userspace hasn't been switched to use the new
+SW_ACPI_LID event, Linux users can use the following boot parameter to
+handle possible issues:
+  button.lid_init_state=method:
+   This is the default behavior of the Linux ACPI lid driver, Linux kernel
+   reports the initial lid state using the returning value of the _LID
+   control method.
+   This can be used to fix some platforms if the _LID control method's
+   returning value is reliable.
+  button.lid_init_state=open:
+   Linux kernel always reports the initial lid state as "opened".
+   This may fix some platforms if the returning value of the _LID control
+   method is not reliable.
-- 
1.7.10

[PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

2016-07-07 Thread Lv Zheng

There are many AML tables reporting wrong initial lid state, and some of
them never reports lid 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 open event;
3. Userspace should only take action against the close event which is
   reliable, always sent after a real lid close.
This patch adds documentation of the usage model.

Link: https://lkml.org/2016/3/7/460
Link: https://github.com/systemd/systemd/issues/2087
Signed-off-by: Lv Zheng 
Cc: Bastien Nocera: 
Cc: Benjamin Tissoires 
Cc: linux-in...@vger.kernel.org
---
 Documentation/acpi/acpi-lid.txt |   62 +++
 1 file changed, 62 insertions(+)
 create mode 100644 Documentation/acpi/acpi-lid.txt

diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-lid.txt
new file mode 100644
index 000..7e4f7ed
--- /dev/null
+++ b/Documentation/acpi/acpi-lid.txt
@@ -0,0 +1,62 @@
+Usage Model of the ACPI Control Method Lid Device
+
+Copyright (C) 2016, Intel Corporation
+Author: Lv Zheng 
+
+
+Abstract:
+
+Platforms containing lids convey lid state (open/close) to OSPMs using a
+control method lid device. To implement this, the AML tables issue
+Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
+changed. The _LID control method for the lid device must be implemented to
+report the "current" state of the lid as either "opened" or "closed".
+
+This document describes the restrictions and the expections of the Linux
+ACPI lid device driver.
+
+
+1. Restrictions of the returning value of the _LID control method
+
+The _LID control method is described to return the "current" lid state.
+However the word of "current" has ambiguity, many AML tables return the lid
+state upon the last lid notification instead of returning the lid state
+upon the last _LID evaluation. There won't be difference when the _LID
+control method is evaluated during the runtime, the problem is its initial
+returning value. When the AML tables implement this control method with
+cached value, the initial returning value is likely not reliable. There are
+simply so many examples always retuning "closed" as initial lid state.
+
+2. Restrictions of the lid state change notifications
+
+There are many AML tables never notifying when the lid device state is
+changed to "opened". But it is ensured that the AML tables always notify
+"closed" when the lid state is changed to "closed". This is normally used
+to trigger some system power saving operations on Windows. Since it is
+fully tested, this notification is reliable for all AML tables.
+
+3. Expections for the userspace users of the ACPI lid device driver
+
+The userspace programs should stop relying on
+/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
+used for the validation purpose.
+
+New userspace programs should rely on the lid "closed" notification to
+trigger some power saving operations and may stop taking actions according
+to the lid "opened" notification. A new input switch event - SW_ACPI_LID is
+prepared for the new userspace to implement this ACPI control method lid
+device specific logics.
+
+During the period the userspace hasn't been switched to use the new
+SW_ACPI_LID event, Linux users can use the following boot parameter to
+handle possible issues:
+  button.lid_init_state=method:
+   This is the default behavior of the Linux ACPI lid driver, Linux kernel
+   reports the initial lid state using the returning value of the _LID
+   control method.
+   This can be used to fix some platforms if the _LID control method's
+   returning value is reliable.
+  button.lid_init_state=open:
+   Linux kernel always reports the initial lid state as "opened".
+   This may fix some platforms if the returning value of the _LID control
+   method is not reliable.
-- 
1.7.10

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

[PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

[PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

36 matches

Site Navigation

Mail list logo

Footer information