Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state notification

From	Bastien Nocera <hadess@hadess.net>
Newsgroups	linux.kernel
Subject	Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state notification
Date	2016-06-02 16:10 +0200
Message-ID	<rFBtU-6Tw-11@gated-at.bofh.it> (permalink)
References	<rzIy6-28V-11@gated-at.bofh.it> <rFbpL-788-11@gated-at.bofh.it> <rFcc9-7Eu-3@gated-at.bofh.it> <rFpj3-7HA-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Thu, 2016-06-02 at 01:08 +0000, Zheng, Lv wrote:
> Hi,
> 
> > From: Bastien Nocera [mailto:hadess@hadess.net]
> > Subject: Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial
> > lid state
> > notification
> > 
> > On Wed, 2016-06-01 at 18:10 +0800, Lv Zheng wrote:
> > > Linux userspace (systemd-logind) keeps on rechecking lid state
> > > when the
> > > lid state is closed. If it failed to update the lid state to open
> > > after
> > > boot/resume, the system suspending right after the boot/resume
> > > could
> > be
> > > resulted.
> > > Graphics drivers also uses the lid notifications to implment
> > > MODESET_ON_LID_OPEN option.
> > 
> > "implement"
> [Lv Zheng] 
> Thanks for pointing out, I'll send an UPDATE to this.
> 
> > 
> > > Before the situation is improved from the userspace and from the
> > graphics
> > > driver, users can simply configure ACPI button driver to send
> > > initial
> > > "open" lid state using button.lid_init_state=open to avoid such
> > > kind of
> > > issues. And our ultimate target should be making
> > > button.lid_init_state=ignore the default behavior. This patch
> > > implements
> > > the 2 options and keep the old behavior
> > > (button.lid_init_state=method).
> > 
> > I still don't think it's reasonable to expect any changes in user-
> > space
> > unless you start documenting what the API to user-space actually
> > is.
> [Lv Zheng] 
> IMO, the ACPI lid driver should be responsible for sending lid key
> event (especially "close") to the user space.
> So if someone need to implement an ACPI lid key event quirk, we could
> help to implement it from the kernel space.
> And since the initial lid state is not stable, we have to stop doing
> quirks around it inside of the Linux kernel, or inside of the
> customized AML tables.
> User space can still access /proc/acpi/button/lid/LID0/state, but
> should stop thinking that it is reliable.
> 
> These are what I can conclude from the bugs.

There's still no documentation for user-space in the patch, and no way
to disable the "legacy" support (disabling access to the cached LID
state, especially through the input layer which is what logind and
upower use).

You can't expect user-space to change in major ways for those few
devices if the API doesn't force them to, through deprecation notices
and documentation.

Cheers

Thread

[PATCH v3 3/3] ACPI / button: Add quirks for initial lid state notification Lv Zheng <lv.zheng@intel.com> - 2016-06-01 12:20 +0200
  Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state  notification Bastien Nocera <hadess@hadess.net> - 2016-06-01 13:10 +0200
    RE: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state  notification "Zheng, Lv" <lv.zheng@intel.com> - 2016-06-02 03:10 +0200
      Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state  notification Bastien Nocera <hadess@hadess.net> - 2016-06-02 16:10 +0200
        Re: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state notification Benjamin Tissoires <benjamin.tissoires@gmail.com> - 2016-06-02 17:30 +0200
          RE: [PATCH v3 3/3] ACPI / button: Add quirks for initial lid state  notification "Zheng, Lv" <lv.zheng@intel.com> - 2016-06-03 02:50 +0200

csiph-web