Message-ID: <CAJZ5v0hCXGL7Zc1=x3utjhMMRMLyyb+7icetMdkJu0ngThd9iw@mail.gmail.com>
Date: Tue, 9 Dec 2025 23:23:28 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Dmitry Osipenko <dmitry.osipenko@...labora.com>
Cc: Antheas Kapenekakis <lkml@...heas.dev>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Mario Limonciello <superm1@...nel.org>, Robert Beckett <bob.beckett@...labora.com>, 
	linux-acpi@...r.kernel.org, kernel@...labora.com, 
	linux-kernel@...r.kernel.org, 
	Sebastian Reichel <sebastian.reichel@...labora.com>, Xaver Hugl <xaver.hugl@...il.com>, 
	Richard Hughes <richard@...hsie.com>, William Jon McCann <mccann@....edu>, 
	"Jaap A . Haitsma" <jaap@...tsma.org>, Benjamin Canou <bookeldor@...il.com>, 
	Bastien Nocera <hadess@...ess.net>, systemd-devel@...ts.freedesktop.org, 
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface

On Tue, Dec 9, 2025 at 11:14 PM Dmitry Osipenko
<dmitry.osipenko@...labora.com> 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?

I still need to get to the details there, but I don't think that a
2-stage freezer is a good idea.  There is enough fragility in the
freezer that we have already.

> 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?
>
> 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.

Well, the problem is that the Sleep notification has ordering
assumptions AFAIK and it really cannot be triggered from user space.

All really depends on what the goal is, but in any case I think that
the required preliminary step would be to move the "screen off" and
"screen on" notifications in the current suspend-to-idle flow, so they
occur earlier and later, respectively.

Powered by blists - more mailing lists