A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-29 19:21:31 -04:00
Code Issues Projects Releases Packages Wiki Activity

Revert "ACPI / button: Remove lid_init_state=method mode"

Browse source 
This reverts commit ecb10b694b.

The only expected ACPI control method lid device's usage model is

 1. Listen to the lid notification,
 2. Evaluate _LID after being notified by BIOS,
 3. Suspend the system (if users configure to do so) after seeing "close".

It's not ensured that BIOS will notify OS after boot/resume, and
it's not ensured that BIOS will always generate "open" event upon
opening the lid.

But there are 2 wrong usage models:

 1. When the lid device is responsible for suspend/resume the system,
    userspace requires to see "open" event to be paired with "close" after
    the system is resumed, or it will suspend the system again.

 2. When an external monitor connects to the laptop attached docks,
    userspace requires to see "close" event after the system is resumed so
    that it can determine whether the internal display should remain dark
    and the external display should be lit on.

After we made default kernel behavior to be suitable for usage model 1,
users of usage model 2 start to report regressions for such behavior
change.

Reversion of button.lid_init_state=method doesn't actually reverts to old
default behavior as doing so can enter a regression loop, but facilitates
users to work the reported regressions around with
button.lid_init_state=method.

Fixes: ecb10b694b (ACPI / button: Remove lid_init_state=method mode)
Cc: 4.11+ <[email protected]> # 4.11+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195455
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1430259
Tested-by: Steffen Weber <[email protected]>
Tested-by: Julian Wiedmann <[email protected]>
Reported-by: Joachim Frieben <[email protected]>
Signed-off-by: Lv Zheng <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
This commit is contained in:
Lv Zheng 2017-05-09 15:02:22 +08:00 • committed by Rafael J. Wysocki
commit f369fdf4f6
2 changed files with 21 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

16
Documentation/acpi/acpi-lid.txt
View file

@ -59,20 +59,28 @@ button driver uses the following 3 modes in order not to trigger issues.
If the userspace hasn't been prepared to ignore the unreliable "opened"
events and the unreliable initial state notification, Linux users can use
the following kernel parameters to handle the possible issues:
A. button.lid_init_state=open:
A. button.lid_init_state=method:
When this option is specified, the ACPI button driver reports the
initial lid state using the returning value of the _LID control method
and whether the "opened"/"closed" events are paired fully relies on the
firmware implementation.
This option can be used to fix some platforms where the returning value
of the _LID control method is reliable but the initial lid state
notification is missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
B. button.lid_init_state=open:
When this option is specified, the ACPI button driver always reports the
initial lid state as "opened" and whether the "opened"/"closed" events
are paired fully relies on the firmware implementation.
This may fix some platforms where the returning value of the _LID
control method is not reliable and the initial lid state notification is
missing.
This option is the default behavior during the period the userspace
isn't ready to handle the buggy AML tables.
If the userspace has been prepared to ignore the unreliable "opened" events
and the unreliable initial state notification, Linux users should always
use the following kernel parameter:
B. button.lid_init_state=ignore:
C. button.lid_init_state=ignore:
When this option is specified, the ACPI button driver never reports the
initial lid state and there is a compensation mechanism implemented to
ensure that the reliable "closed" notifications can always be delievered