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

Antheas Kapenekakis
2024-09-23T16:54:52Z

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

I want to say that that is beginning to change, at least for these
devices. Manufacturers want the experience that comes with owning the
whole OS. Mobile phones and TVs figured that out long ago.

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

The problem here is probably that. Killing the power too early made it
not save its state, asking it to be brought up before it powers on
made it NOOP, and asking it to be brought up in prepare_early ended up
with a bunch of race conditions with the kernel.

Lenovo figured it out, so there is no reason Asus wouldn't. Although
the latest bios from lenovo made the controllers take 2 seconds longer
to wake up. We did not have any problem in Linux, that was in Windows.
Unplugging XInput devices is really a mess.

I am really happy with the patch on the Ally X. We will get to testing
it on the Ally. It does a little reboot with powersave on, but that is
a cosmetic failure and happens in Windows too. When Asus fixes that I
will point them to Windows to update if they care about powersave so
much.

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

I do not think every manufacturer creates a HID spec for updates. They
use the same cookiecutter stuff, for which there is no linux
implementation at all, so kind of the same. Probably after we do 1-3,
we will have all of them.

I saw that HID interface though, and the Legion Go has one and I am
none the wiser.

I've been doing HID for over a year by now, so I am used to it.
Biggest problem is you cannot trigger an update in Windows whenever
you want to sniff it. At least on the Lenovo.

However, I think I have bigger fish to fry, so it is not high in my
priority list.

Antheas