On Tue, Jun 06, 2017 at 12:22:09PM +0200, Benjamin Tissoires wrote:
[...]

quoted

This is because the aml table puts many Notify(LID, 0x80) in various control methods.
And not one of them but multiple of them will be invoked by various OS drivers during suspend/resume period.
I think this is not an isolated platform that will invoke multiple redundant "Notify(lid)".

Fortunately, the lid state for the multiple notify(lid) should be same as the first "Notify(lid)".
I suppose this is why SW_LID is invented, as it can really filter such redundant events.
And user space finally can only see 1 "close" event.

But unconditionally prepending "open" before all "close" events surely can break the logic by
delivering multiple "close" events to the user space.

That doesn't matter. What matters is the state of the switch, not the
event. So if user space receives (in case we marked the switch as not
reliable) several close events, all user space will do is realize that
the state is still closed and will act accordingly.

[...]

Again, we don't care if the "event" comes from ACPI, the driver itself or
user space (libinput). All that matters is the current state of the
input node switch, that needs to match the physical world at any time.

as extra comment on those two: you cannot guarantee when e.g. libinput
checks the state. it may start up after the kernel has updated the EV_SW
state, it may close and re-open a device without notice (disabling a
device in X has that effect for example). So the EV_SW/SW_LID events are
nice to have, but we really rely on the *state* of the switch more than the
events.

Cheers,
   Peter