Re: [RFC PATCH v1 1/1] ACPI: PM: s2idle: Add lps0_screen_off sysfs interface

[Dmitry Osipenko]

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

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.

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.

-- 
Best regards,
Dmitry