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

Mario Limonciello
2024-09-23T16:21:14Z

On 9/23/2024 11:11, Antheas Kapenekakis wrote:
>> I don't think it's possible to have it both ways that the ordering is
>> wrong AND the timing is wrong.
>
> I think the current firmware manifests 2 issues on the Ally X: Display
> On needed to be called once the kernel is ready otherwise it NOOPed
> and Display Off needed to be called 1 second before suspend. Then,
> there is the issue in my previous email that also exists in Windows.
>
> I tried from 0 - 4000ms for Display off and 0 - 1500ms for Display on.
> Display Off, as long as the RGB fades 100-200ms before, made no
> difference. Display On likewise made no difference.

Part of the problem here is that we (Linux kernel developers) don't have
the details of how the MCU actually interacts with the OS vs how it
wants to interact with the OS. Only ASUS knows this and all we can do
is guess (or join an NDA).

"For example" (not saying this is the problem; I don't know) if we have
a Linux sequence that we put the XHCI host controller into D3 but don't
turn off the port first this might not matter to most devices because
you're saving power by the controller being in D3. But if the device is
looking for some sequence of packets there could be a failure if those
never happen or happen at the wrong time.

>
> I am currently playing a bit with the calls in the Legion Go. Seems
> like one of them turns off its controller as well.
>
> I did not know fwupd could do microprocessors, if it is simple that
> would be great.

Yeah in this case it interacts with the USB HID interface.

Unfortunately we don't have the HID spec from ASUS, so the entire thing
would need to be reverse engineered.

I hope that more of these handhelds with MCUs that get regular updates
make the same investment.