Created attachment 280803 [details] acpidump / dmesg On a EEEpc 1215P, with any kernel above 4.10, closing the lid does nothing, but there is a warning in dmesg: "ACPI: button: The lid device is not compliant to SW_LID." I have already tried the button.lid_init_state option, but none of the values work. I am attaching the output of acpidump and dmesg with acpi trace enabled. Related bugs: * originally reported as Debian-specific bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919227 (it happened after upgrading from stable to testing) * very similar to https://bugzilla.kernel.org/show_bug.cgi?id=192231 (already closed but not solved)
one last thing: the dmesg output in the attachment was created without button.lid_init_state but I can re-test as needed.
Method (_LID, 0, NotSerialized) // _LID: Lid Status { If (^^PCI0.SBRG.EC0.ECAV ()) { If (!Acquire (^^PCI0.SBRG.EC0.MUEC, 0xFFFF)) { LIDS = ^^PCI0.SBRG.EC0.SF13 /* \_SB_.PCI0.SBRG.EC0_.SF13 */ Release (^^PCI0.SBRG.EC0.MUEC) } } Return (LIDS) /* \_SB_.LID_.LIDS */ } It seems that LID won't work if EC is not initialized properly. We fix a EC issue on 5.0-rc, so please confirm if the problem still exists in the latest upstream kernel.
This morning, even before reading the comment above, I ran into a problem with ACPI not reporting battery status: it was stuck at 100% even if another OS (PrimeOS, basically Android 7) on the same hw was reporting less than 40%. Being lazy, I tried booting kernel 5.02 from here: https://github.com/M-Bab/linux-kernel-amdgpu-binaries (I'm already using it on the desktop, it was simply a quick shortcut to avoid rebuilding) Well, the lid switch was detected just fine and the battery reading was properly updated during charging. Is the fix already present in 5.02? Do you need specific confirmation with 5.04?
Good to know, the patch has already shipped in upstream 5.0. thus I think we can close the bug.