How do you find the WMI calls?

[flukejones]

Hi!

I am the maintainer of https://gitlab.com/asus-linux/asusctl, and also write a lot of the Linux kernel patches to expose WMI methods to users. Most of the time I find WMI methods by trial and error, by searching others repos, or by asking ASUS.

Do you @seerge use any particular method to find these? Reverse engineering drivers? I see you have a few in your project I haven't yet seen before.

[seerge]

@flukejones hello! Nice to have you here, I use your asusctl on my dual boot ubuntu :)

I mainly use DEVS / DSTS methods for the app, and I call them via ACPI proxy-layer that asus has created, as then it's possible to call them even without admin privileges at all.

Main unknown here is "device ID" param that is being used by those methods. Many of them (like ones for fan curves / or GPU disabling) I took from linux kernel sources, discovered by people like you :)

As for the rest - it's also trial and error.

1. I did a scan script (actually did it as way faster exe as well, but it get's flagged by windows defender so i don't post it) that goes over all possible device IDS and runs DSTS method on them, trying to "read" value. Often if device exists for DSTS (at least responds something reasonable) - then it will exist for DEVS too. This way all power limits were discovered. There is a topic dedicated to that Endpoint discovery for different laptop models #38

2. It's also possible to do an ACPI dump using method explained here Endpoint discovery for different laptop models #38 (comment) then you can get some insights and try to guess what it does.

[seerge]

@flukejones on many models (incl G14) it definitely does change power limits as well, so it's not only fans.

Read it as "preset modes" in bios. That you can later customize by overriding fan curves and PPTs

[flukejones]

@seerge we can't get what the PL1 and PL2 was changed to can we?

I've tried a few methods, and the package limits never change - those are hard set at factory. Plus the WMI methods give fuck all feedback, and there doesn't appear to be anything in dts to give indication of limits or defaults.

When I switch profiles with 0x00120075 the following never changes:

cpu0: PKG Limit #1: ENabled (200.000 Watts, 56.000000 sec, clamp DISabled)
cpu0: PKG Limit #2: DISabled (135.000 Watts, 0.002441* sec, clamp DISabled)

(using sudo turbostat --Summary --interval 5 --show Avg_MHz,Busy%,Bzy_MHz,IRQ,PkgTmp,PkgWatt,GFXWatt).

That at least gives the PL2, which provides the maximum value for us. But the rest of the MSR doesn't give much.

[seerge]

Try to set 0x00120075 to 4, it's a "custom" mode and some devices apparently require that to allow PPT limit changes

[flukejones]

I might not have been clear - the effects are there - you can tweak downwards from the known maximum. But the actual PL1 and PL2 the CPU is hard set at never changes (even though they have changed in acpi, and the effect is measurable).

The end result is that although it works there is no way to verify the setting beyond caching the input, and there is no way to easily find the maximum beyond turbostat, and even then that doesn't report the correct PL1.

[seerge]

@flukejones ah, that's indeed seem to be the case with intel CPUs and way asus does this (this topic confirms that #405 ) , so actual PL1/PL2 values don't change if you would query them, but limit is there. I assume this is same as it happens if you would do that via Armoury Crate.

On AMD CPUs it's a bit easier, and at least values change.

From my observations limits always work downwards, and sometimes a bit upwards (up to 10%) from defaults, depending on model. On g14 for example, default CPU limit would be 80W (in turbo mode), but you can rise it up to 90W.

[flukejones]

I see you haven't used:

    public const int PPT_EDCA1 = 0x001200A1;  // CPU EDC
    public const int PPT_TDCA2 = 0x001200A2;  // CPU TDC

What do we know about these?

[seerge]

@flukejones it's max EDC and TDC values, they are not of use for an average user anyway

[flukejones]

Ah thanks. I think I'll skip exposing those maybe. Not sure.