Differential D59583
acpi: Increase length of time (1s -> 5s) for quirk Authored by dteske on Fri, Sep 11, 4:23 AM. Tags None Referenced Files
Subscribers None
Details The ACPI quirk on Framework Laptop 12 firmware was previously clocked However, when KMS is not loaded, that very same notification comes in Use the already-defined ACPI_MINIMUM_AWAKETIME (5) seconds as our new Introduce new tunable hw.acpi.button_replay_window Unload i915kms and disable it, then reboot to console-only. With sysctl hw.acpi.power_button_state=fw_suspend (default) press the power button on the Framework laptop to put it into S3 sleep. The power button (which has a light in it) will show it is in sleep when the light starts to "throb" / "pulse" When the light is observed to be pulsing, press the power button once more to bring the system out of S3 sleep state. EFIFB is not yet fixed so do not expect the screen to turn on, just watch the power button. Without this patch, a few seconds after going solid, the light will go back to pulsing (and the machine will be unreachable by ssh / network). With this patch, the light will stay solid after coming back up. There's an issue with EFIFB still so the screen does not come back after coming out of S3 but the network is operational and the machine responds to ssh, proving that it is back up when the light is remaining solid.
Diff Detail
Event TimelineComment Actions Successfully tested and test passed. Was able to come out of S3 sleep state on new kernel whereas previous kernel with only 1s replay window was still going back to sleep when lacking KMS Comment Actions I really think the original comment, although longer, was more informative. Could you please restore it (with amendments about the new findings and change)? It certainly makes sense to use the ACPI_MINIMUM_AWAKETIME constant for this purpose. The actual 5s delay it is set to looks a bit arbitrary. It was introduced by ece50487e93560078a83b5e0685015d373babc13, apparently to fix problems on Toshiba and Thinkpad laptops. It's probably worth mentioning it in the commit message (at least the reference to that commit). I'm on the verge on asking to offer a tunable for this along with this commit, just in case, since it shouldn't take more than a few minutes. What do you think? In any case, a default of 5s is fine by me. Comment Actions My vote is for sysctl tunable (not loader tunable). Most of hw.acpi knobs are CTLFLAG_RW, no TUN, such as power_button_state, sleep_delay, verbose, handle_reboot, etc. sysctl.conf makes more sense to keep the hw.acpi knobs together (aside from the few and the minority which are loader tunable). On top of that, it would be incredibly frustrating to perform a field bisection of new hardware exhibiting a similar quirk if I had to reboot each time to change the value. For example, say I come across some hardware that is exhibiting the situation just outside the min awake time, my debug process would be to massively expand the window (to 30s) as an initial litmus and then tune it back in bisection to find out if a reasonable value exists (without rebooting between bisection over the course of several days in a system integration rally). Comment Actions Make them RWTUN. Best of both world. Then you can set them in the loader if you want (or more importantly need to), but you can also set them after boot if you are debugging. Most of the ACPI ones should be this, honestly. There's very few that can't be like that. |