The following approach fixes button.lid_init_state=method mode for systemd 233: https://patchwork.kernel.org/patch/9756457/ https://patchwork.kernel.org/patch/9756467/ But it is not working well with old systemd 229. This solution tries to make a more comfortable approach for systemd 229. There are platform variations implementing ACPI lid device in different way: 1. Some platforms send "open" events to OS and the events arrive before button driver is resumed; 2. Some platforms send "open" events to OS, but the events arrive after button driver is resumed, ex., Samsung N210+; 3. Some platforms never send "open" events to OS, but send "open" events to update the cached _LID return value, and the update events arrive before button driver is resumed; 4. Some platforms never send "open" events to OS, but send "open" events to update the cached _LID return value, but the update events arrive after button driver is resumed, ex., Surface Pro 3; 5. Some platforms never send "open" events, _LID returns value sticks to "close", ex., Surface Pro 1. [PATCH 1] tries to fix case 2,4, making them working with any systemd. [PATCH 2] tries to fix case 5, making it working with systemd 233. This is also a replacement of the following solution: https://patchwork.kernel.org/patch/9760867/ It seems adding/removing input node and requesting systemd to change again is unnecessary for such platforms, so this patch simply converts "lid_unreliable" into "button.lid_init_state=ignore". This material is just sent to demonstrate solutions and issues, the final solution is not determined yet. So marking them as RFC. Lv Zheng (2): ACPI: button: Fix issue that button notify cannot report stateful SW_LID state ACPI: button: Add a quirk mode for Surface Pro 1 like laptop drivers/acpi/button.c | 188 ++++++++++++++++++++++++-------------------------- 1 file changed, 89 insertions(+), 99 deletions(-) -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
