https://bugzilla.kernel.org/show_bug.cgi?id=106941
--- Comment #13 from Lv Zheng <[email protected]> --- Hi, Mika Sorry for interrupting. (In reply to Mika Westerberg from comment #12) > OK, I see. However, I'm not sure how we can fix this from the kernel side. > If Windows waits for the initial event and only then decides what to do, it > explains why it works. At least from the ACPI ASL code I'm not able to find > out any place where the initial value would be set to anything else than 0. There simply won't be the initial event. On Samsung platforms, Linux drain events using a quirk. So there is no worry that the event will be lost. We can see that there is no such a event on some Samsung platforms. The LID event should have already been handled by the BIOS, and OSPM was just invoked via the waking vector. We can also see, 1. There are many BIOS tables resetting LID state in _WAK because of this. 2. There are BIOS tables never initiating LID open event. > > One option is to modify systemd-sleep so that it does not read the initial > status (why would it suspend the device in the first place if it did not > receive an event about lid being closed). If above mentioned platforms can all work with Windows, I don't know how this can be fixed. Just an idea that, userspace may not suspend system by reading the LID status, it probably should only wait for the "LID close" event. If there is no such a event, but LID is closed, it might be OK for Windows to stay awake. Thanks and best regards -Lv -- You are receiving this mail because: You are watching the assignee of the bug. ------------------------------------------------------------------------------ _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
