[systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI

[Zheng, Lv]

Hi,

> From: Lennart Poettering [mailto:mzxreary at 0pointer.de]
> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
> 
> On Thu, 01.06.17 20:46, Benjamin Tissoires (benjamin.tissoires at redhat.com) wrote:
> 
> > Hi,
> >
> > Sending this as a WIP as it still need a few changes, but it mostly works as
> > expected (still not fully compliant yet).
> >
> > So this is based on Lennart's comment in [1]: if the LID state is not reliable,
> > the kernel should not export the LID switch device as long as we are not sure
> > about its state.
> 
> Ah nice! I (obviously) like this approach.
> 
> > Note that systemd currently doesn't sync the state when the input node just
> > appears. This is a systemd bug, and it should not be handled by the kernel
> > community.
> 
> Uh if this is borked, we should indeed fix this in systemd. Is there
> already a systemd github bug about this? If not, please create one,
> and we'll look into it!

This is not my opinion.
My opinion is as follows.

We confirmed Ubuntu shipped systemd (version 229) with "reliable|unreliable" platforms.
We can see 2 problems:
1. LID_OPEN cannot cancel an on-going suspend sequence
   After boot, if user space receives "LID_CLOSE" key event,
   systemd may not suspend the platform right after seeing the event,
   it may suspend the platform several seconds later.
   This is not a problem.

   The problem is, if "LID_OPEN" is sent within this deferring period,
   Systemd doesn't cancel previously scheduled "suspend".
   And the platform may be suspended with lid opened.
   Then users need to close and re-open the lid to wake the system up.
   Causing another "LID_CLOSE/LID_OPEN" sequence delivered to the user space after resume.
   Users then can see a suspend/resume loop.
   This problem can even be seen on "reliable" platforms.
   It can be easily triggered by user actions.
2. Need explicit LID_OPEN to stay woken-up
   After boot, systemd seems to be wait for a significant "LID_OPEN".
   If it cannot see a "LID_OPEN" within several seconds,
   it suspends the platform.
   So if a platform doesn't send "LID_OPEN" or fails to send "LID_OPEN" within this period.
   Users then can see a suspend/resume loop.

However we've tested with github cloned systemd (version 233).
The 2 problems seem to have been fixed.
It works well with current ACPI button driver,
but you need to boot linux kernel with button.lid_init_state=ignore.
I don't know the story of the improvement.
Systemd developers should know that better than me.

So IMO, systemd needn't do any further improvement.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But the kernel button driver implements several "lid_init_state" modes.
It appears "method" mode is determined to be the default mode.
Thus we need to do:
1. improve button driver "method" mode to make systemd 233 work well with it.
2. determine if we need to improve button driver to make it work well with systemd 229.

Thanks and best regards
Lv