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

[Bastien Nocera]

> On 16 Jun 2017, at 10:53, Zheng, Lv <lv.zheng at intel.com> wrote:
> 
> Hi,
> 
>> From: Benjamin Tissoires [mailto:benjamin.tissoires at redhat.com]
>> Subject: Re: [systemd-devel] [WIP PATCH 0/4] Rework the unreliable LID switch exported by ACPI
>> 
>>> On Jun 16 2017 or thereabouts, Zheng, Lv wrote:
>>> Hi, Benjamin
>>> 
>>> Let me just say something one more time.
>>> 
>>>> From: Benjamin Tissoires [mailto:benjamin.tissoires at redhat.com]
>> 
>> [snip]
>>>>>>> 
>>>>>>> We can see:
>>>>>>> "logind" has already implemented a timeout, and will not respond lid state
>>>>>>> unless it can be stable within this timeout period.
>>>>>>> I'm not an expert of logind, maybe this is because of "HoldOffTimeoutSec"?
>>>>>>> 
>>>>>>> I feel "removing the input node for a period where its state is not trustful"
>>>>>>> is technically identical to this mechanism.
>>>>>> 
>>>>>> but you'd be making kernel policy based on one userspace implementation.
>>>>>> e.g. libinput doesn't have a timeout period, it assumes the state is
>>>>>> correct when an input node is present.
>>>>> 
>>>>> Do you see practical issues?
>>>> 
>>>> Yes, libinput can't rely on the LID switch information to disable
>>>> touchpads/touchscreens that are potentially sending false positive.
>>> 
>>> "potential" doesn't mean "practical", right?
>> 
>> I was using potential to say that some actual devices are sending
>> rightful states, while others are not (we already named them a lot in
>> those countless threads). So potential here is from a user space
>> perspective where you are not sure if the state is reliable or not
>> (given we currently don't have this information about reliability).
>> 
>>> After applying my last version.
>>> There are no false-positives IMO.
>>> There are only delays for the reliable key events.
>>>               ^^^^^^
>>> While the "delay" is very common in computing world.
>> 
>> No, if there is a delay, there is a false positive, because the initial
>> state is wrong with respect to the device physical state.
>> 
>>> 
>>>>> After resume, SW_LID state could remain unreliable "close" for a while.
>>>> 
>>>> This is not an option. It is not part of the protocol, having an
>>>> unreliable state.
>>>> 
>>>>> But that's just a kind of delay happens in all computing programs.
>>>>> I suppose all power managing programs have already handled that.
>>>>> I confirmed no breakage for systemd 233.
>>>>> For systemd 229, it cannot handle it well due to bugs.
>>>>> But my latest patch series has worked the bug around.
>>>>> So I don't see any breakage related to post-resume incorrect state period.
>>>>> Do you see problems that my tests haven't covered?
>>>> 
>>>> The problems are that you are not following the protocol. And if systemd
>>>> 233 works around it, that's good, but systemd is not the only listener
>>>> of the LID switch input node, and you are still breaking those by
>>>> refusing to follow the specification of the evdev protocol.
>>> 
>>> As you are talking about protocol, let me just ask once.
>>> 
>>> In computing world,
>>> 1. delay is very common
>>>   There are bus turnaround, network turnaround, ...
>>>   Even measurement itself has delay described by Shannon sampling.
>>>   Should the delay be a part of the protocol?
>> 
>> Please, you are either trolling or just kidding. If there are delays in
>> the "computing world", these has to be handled by the kernel, and not
>> exported to the user space if the kernel protocol says that the state is
>> reliable.
>> 
>>> 2. programs are acting according to rules (we call state machines)
>>>   States are only determined after measurement (like "quantum states")
>>>   I have Schroedinger's cat in my mind.
>>>   Events are determined as they always occur after measurement to trigger "quantum jumps".
>>>   So for EV_SW protocol,
>>>   Should programs rely on the reliable "quantum jumps",
>>>   Or should programs rely on the unreliable "quantum states"?
>> 
>> No comments, this won't get us anywhere.
>> 
>>> 
>>> I think most UI programs care no about state stored in the input node,
>>> they only receive events raised from the input node.
>> 
>> Bullshit. When you launch such a program, you need to query the state
>> because you won't receive the event that happened way before the launch.
>> 
>>> Why should the kernel export a fade-in/fade-out input node to the UI programs and ask them to change?
>>> 
>>> The only program that cares about the state stored in the input node is libinput.
>>> So why should every user program be changed to make libinput easier?
>> 
>> No, all program that listen to LID switches input nodes care about the
>> state. We already told you that, you just don't listen:
>> 
>> - systemd cares about the state as it does polling on the input node in
>>  case it misses an event
>> - libinput cares about the state as previously mentioned
>> - gnome-setting-daemons cares about the state given it decides whether
>>  or not lighting up the monitors depending on the state. And if you
>>  relaunch the daemon, it'll query the state to decide what is the best
>>  arrangement for the screens
> 
> Let's consider this case with delay:
> After resume, gnome-setting-daemon queries SW_LID and got "close".
> Then it lights up the wrong monitors.
> Then I believe "open" will be delivered to it several seconds later.
> Should gnome-setting-daemon light-up correct monitors this time?
> So it just looks like user programs behave with a delay accordingly because of the "platform turnaround" delay.

If you implement it in such a way that GNOME settings daemon behaves weirdly, you'll get my revert request in the mail. Do. Not. Ever. Lie.

> 
>> - KDE should do the same (as it is not a daemon that can catch any
>>  events)
> 
> Cheers,
> Lv
> ¢éì¹»®&Þ~º&¶¬–+-±éݶ¥Šw®žË›±Êâmébžìbž›­Š{ayºʇڙë,j­¢f£¢·hš‹àz¹®w¥¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i