Re: [PATCH v2 0/5] acpi/x86: s2idle: move Display off/on calls outside suspend (fixes ROG Ally suspend)

Antheas Kapenekakis
2024-09-23T17:49:09Z

> Considering the previous experience, maybe you can help to document
> their update protocol? I'm happy to collaborate on the fwupd side if
> you can help push it along.

If I get the time I might try to, but if this patch works on the
original Ally, this fire is handled as far as I am concerned. Even if
it does not merge and even with the little reboot quirk.

So it moves back in the stack of priorities. I still think fw and bios
updates are important and I have been thinking about it too. More on
the GUI side though.

At least BIOS updates are kind of solved for both the Ally and the Go.
However, the Go half bricks itself in almost all updates from WIndows.
I had to power it off during a bios update twice and that's from
Windows. I am not going near it any time soon.

> AFAICT any need for this series goes away when you have an easy way to
> update a handheld that is running Linux already. I would take a pile of
> userspace code over kernel quirks any day.

I cannot agree with you more on skipping the kernel when possible. It
is why most of my work is in userspace.

"Oh custom TDP/Fan on the legion go? Custom TDP is mode 4 that does
not map cleanly to a platform_profile, half of the BIOSes of the
legion go forget the custom TDP when changing TDP profile, and there
is a hw combo to change the TDP. Sniff the kernel net socket for ACPI
events to capture TDP mode changes, then if in Custom mode, wait 2
seconds, set the custom TDP the user saved previously, and then the
fan curve. Want to disable the custom fan curve? Pick a random TDP
profile, switch to it, and repeat."

However, with the kernel firing the _DSMs Display Off and Screen Entry
calls after the suspend sequence back to back with no delay when
WIndows calls them seconds apart before the suspend sequence, I can
personally see the eventuality.

Three talented OSS devs + the Asus engineering team had to work for 1
month on avoiding this table and now they have to move on to
validating the firmware, shipping it, etc. I also spent too much work
on making this upstreamable, but I plan to use this patch so it is
kind of OK, unless the Sleep _DSM does not do much.

Also, did I mention that the Ally gets stuck on 5W TDP semi randomly
after suspend and has a really nice and complex _DSM sleep entry? And
I am the only one that knows it because Handheld Daemon is the only
TDP solution that does not use ryzenadj to set TDP on the Ally. So
next step for me is doing the same series for the Sleep Entry/Exit and
expanding the quirk table. I am not waiting for a BIOS update.

Antheas