https://bugzilla.kernel.org/show_bug.cgi?id=106941
--- Comment #14 from Aaron Lu <[email protected]> --- (In reply to Lv Zheng from comment #13) > 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. Hi Lv, The problem here is about things after system boot, not system resume :-) > > > > > 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. I think this is a good idea, we probably need to raise this to systemd. -- 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
