On Tue, 9 Dec 2025 at 23:14, Dmitry Osipenko <[email protected]> wrote: > > ... > >> So let me repeat for extra clarity. > >> > >> The only change related to the LPS0 "screen off" and "screen on" > >> notifications that would be tentatively acceptable to me ATM, would be > >> to modify the suspend-to-idle flow to do the "screen off" notification > >> earlier (possibly even at the start of it) and the corresponding > >> "screen on" notification later (possibly at the end of it), provided > >> that one can convincingly argue that this should not introduce > >> regressions. > >> > > > > From what I recall that was my original plan. > > > > Yeah, it is a fair way forward. @Dmitry how would you like to approach > > this? SInce you re-started the discussion. What is your timeline/KPIs > > for this. > > > > I could personally try to whip up a small series after the merge > > window by rewriting what I have[1]. I have more experience now in > > drafting this kind of thing and that series added some cruft to the pm > > core with multiple additions to platform_s2idle_ops > > > > There is a _small_ quantitative difference due to moving the calls. > > Specifically, the power light responds a tad slower when waking a > > device. For the legion go (non-s) devices, Lenovo added a dummy 5 > > second timer to resuming the controllers because of some Windows bugs, > > and moving the calls causes the timer to start later. But that's the > > OEM intended behavior... > > > > Antheas > > > > [1] > > https://github.com/bazzite-org/patchwork/commits/pm-bleeding/modern-standby/ > > Am I understanding correctly that the plan is to have a 2-stage freezer > for suspend-to-idle + standby mode? Rafael, could you please confirm > that you're fine with this 2-stage freezer part of the proposal from > Antheas?
2 stages here refers to a two patch series, where the first part moves the firmware notifications to the beginning of the suspend sequence and the second part introduces a sysfs entry. This way, it can be verified that it is ok for these calls to be moved, and thereafter they are only called before the suspend sequence, not both depending on userspace involvement. In your series, you introduce a call from userspace, but then do the fallback call at the end of the suspend sequence/beginning of resume. > What you expect to be a proper way of implementing a 2-stage freezer? > Would it be a new executable capability, a new syscall or extension of > existing one, a new cgroup type? How would you mark processes that > should not be frozen on the first stage? Or it would be only the process > that writes to /sysfs/power? This would be handled by the init process without any kernel extension, so it is a bit tangential. You can reference the current freezer group in systemd-sleep for what is done currently. It was introduced to prevent waking programs during the transition to hibernation. In addition, freezing userspace _tends_ to improve VRAM evacuation when preparing for hibernation and cache evacuation %, among other things. So under systemd, the kernel essentially is only responsible for freezing systemd. > Thanks everyone for the very detailed input. It is all very productive, > helps a lot with adjusting my understanding of the modern suspend features. > > Agree that the usefulness of the visual aspect of the Display > notification is questionable. Previously I thought this mode involves > power-limiting. The Sleep notification might be much more interesting then. > > I'm heading to vacation till Jan. Antheas, I will be happy to review and > test your code if you'll have time to type a working prototype. > Otherwise, will continue after the Holidays and likely will use your > patches for the base. Happy holidays. I am also heading off soon, but I might have some time in the meantime. Best, Antheas > -- > Best regards, > Dmitry >
