Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after boot/resume

[Bastien Nocera]

On Tue, 2016-05-17 at 16:27 +0800, Lv Zheng wrote:
> (This patch hasn't been tested, it's sent for comments)
> 
> 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, it could suspend the system. But as:
> 1. Traditional ACPI platform may not generate the lid open event after
> ÂÂÂresuming as the open event is actually handled by the BIOS and the system
> ÂÂÂis then resumed from a FACS vector.
> 2. The _LID control method's initial returning value is not reliable. The
> ÂÂÂ_LID control method is described to return the "current" lid state,
> ÂÂÂhowever the word of "current" has ambiguity, many BIOSen return lid
> ÂÂÂstate upon last lid notification while the developers may think the
> ÂÂÂBIOSen should always return the lid state upon last _LID evaluation.
> ÂÂÂThere won't be difference when we evaluate _LID during the runtime, the
> ÂÂÂproblem is the initial returning value of this function. When the BIOSen
> ÂÂÂimplement this control method with cached value, the initial returning
> ÂÂÂvalue is likely not reliable.
> Thus there is no mean for the ACPI lid driver to provide such an event
> conveying correct current lid state. When there is no such an event or the
> event conveys wrong result, false suspending can be examined.
> 
> The root cause of the issue is systemd itself, it could handle the ACPI
> control method lid device by implementing a special option like
> LidSwitchLevelTriggered=False when it detected the ACPI lid device. However
> there is no explicit documentation clarified the ambiguity, we need to
> work it around in the kernel before systemd changing its mind.
> 
> Link 1: https://lkml.org/2016/3/7/460
> Link 2: https://github.com/systemd/systemd/issues/2087
> Link 3: https://bugzilla.kernel.org/show_bug.cgi?id=89211
> ÂÂÂÂÂÂÂÂhttps://bugzilla.kernel.org/show_bug.cgi?id=106151
> ÂÂÂÂÂÂÂÂhttps://bugzilla.kernel.org/show_bug.cgi?id=106941
> Signed-off-by: Lv Zheng <lv.zheng@xxxxxxxxx>
> Cc: Bastien Nocera: <hadess@xxxxxxxxxx>

As mentioned previously, I'd be much happier if either:
- a new system was put in place that matched the ACPI specs and the way
they are used by Windows
- an additional tag/property was added to show that the API offered by
the LID switch is different from the one that existing since ACPI
support was added to Linux.

And I'd really appreciate it if you stopped saying that it's systemd's
fault.

The kernel has offered an API to user-space that included the state of
the LID switch. And the state of the LID switch has been correct for
the majority of systems and devices for the past decade or so. The fact
that this device means that the LID state isn't reliable anymore means
that the kernel needs to communicate that to user-space.

I'm volunteering to modify systemd and UPower to respect the fact that
the LID switch state isn't available on those devices. If you want to
find something to blame, blame the kernel for implementing an API that
doesn't reflect what the hardware makes available. Though you can only
say that with the benefit of hindsight.

So, NAK from me.