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

[Zheng, Lv]

Hi,

> From: Bastien Nocera [mailto:hadess@xxxxxxxxxx]
> Subject: Re: [RFC PATCH 1/2] ACPI / button: Send "open" state after
> boot/resume
> 
> 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
[Lv Zheng] 
Then what about the old systems?
Surface Pro 1 and Surface 3 are MS platforms that should have already adapted to the Windows.
They are currently suffering from the same issue by running Linux.

> - 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.
[Lv Zheng] 
OK.
Instead of saying this is a fault, I'll say systemd may need an additional option to handle ACPI lid device.

> 
> 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.
[Lv Zheng] 
I'm out of the context here.
This patch is generated to respect the current systemd behavior.
If not, we'd rather just delete the 2 wrong lines.
I know that you need a documentation clarification, we are putting effort on this.

Thanks and best regards
-Lv