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

Hi, Sending this as a WIP as it still need a few changes, but it mostly works as expected (still not fully compliant yet). So this is based on Lennart's comment in [1]: if the LID state is not reliable, the kernel should not export the LID switch device as long as we are not sure about its

[systemd-devel] [WIP PATCH 3/4] ACPI: button: Let input filter out the LID events

The input stack already filters out the LID events. So instead of filtering them out at the source, we can hook up after the input processing and propagate the lid switch events when the input stack tells us to. An other benefit is that if userspace (think libinput) "fixes" the lid switch state

[systemd-devel] [WIP PATCH 4/4] ACPI: button: Fix lid notification locks

From: Lv Zheng acpi/button.c now contains the logic to avoid frequently replayed events which originally was ensured by using blocking notifier. On the contrary, using a blocking notifier is wrong as it could keep on returning NOTIFY_DONE, causing events lost. This patch

[systemd-devel] [WIP PATCH 2/4] ACPI: button: remove the LID input node when the state is unknown

Because of the variation of firmware implementation, there is a chance the LID state is unknown: 1. Some platforms send "open" ACPI notification to the OS and the event arrive before the button driver is resumed; 2. Some platforms send "open" ACPI notification to the OS, but the event

[systemd-devel] [WIP PATCH 1/4] ACPI: button: extract input creation/destruction helpers

When the LID switch ACPI implementation is unreliable, we might want to remove the device when we are not sure about the state. This should prevent any suspend/resume loops given that in that case, there will be no more LID switch input node. This patch prepares the dynamic creation/destruction

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

On Thu, 2017-06-01 at 20:46 +0200, Benjamin Tissoires wrote: > Hi, > > Sending this as a WIP as it still need a few changes, but it mostly > works as > expected (still not fully compliant yet). > > So this is based on Lennart's comment in [1]: if the LID state is not > reliable, > the kernel