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 ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
