Endpoint discovery for different laptop models

Hello, recently I have discovered endpoints that let you set Total PPT and CPU PPT on 2022 models. Armory seem to use them as well.

I did that by running own app-script that literally sent DSTS (asus’es “get device status”) command to all possible DeviceID’s in asus ACPI and checking which one’s would respond at least somehow 😃

Then by just trying to set a new value (with DEVS “set device status”) command to a few discovered DeviceIDs correct endpoints were found.

0x001200A0 - SPL almost everywhere ( Total Platform limit  on all AMD platforms )
0x001200A1 - EDC_LIMIT_VDD
0x001200A2 - TDC_LIMIT_VDD
0x001200A3 - sPPT

0x001200B0 - CPU limit on all AMD platforms
0x001200B1 - Total Platform limit on all AMD platforms

0x001200C0 - does nothing on G14 2022 (NVIDIA GPU dynamic boost 5 ... 20+W)
0x001200C1 - fPPT
0x001200C2 - does nothing on G14 2022 (NVIDIA GPU temp limit 75 ... 87 C)

It could be that on other models (non G14) this endpoints could adjust different settings.

Discover endpoints Method 1

Run this ps1 scan-atkacpi.zip as admin in powershell and post output here

Discover endpoints Method 2

Crate a dump and upload it here (as suggested by @vddCore )

Download ACPICA tools from here: https://acpica.org/downloads/binary-tools Extract, run acpidump tool, then you can use the other tool called iasl to decompile resulting files to something that humans can read.

Both tools include comprehensive help messages, but if all you want to achieve is dumping your DSDT and decompiling it, run acpidump.exe -b to dump them all to .dat files. They’ll be placed in the location you ran the tool from. Then run iasl.exe dsdt.dat and the decompiled ACPI table will be created as dsdt.dsl.

How to test what discovered endpoints do

Run following command in powershell as admin:

Invoke-CimMethod (Get-CimInstance -Namespace root/wmi -ClassName AsusAtkWmi_WMNB) -MethodName DEVS -Arguments @{Device_ID=0x1200C1; Control_status=25}

Where DeviceID is ID from the list (for example 0x1200B0, 0x1200B1, 0x1200C0, 0x1200C1, 0x1200C2)

And Control_status is the “value” , try something like 25 or 50 or 100 … 😃 (on your own risk, but most probably bios will just hardcap some potentially high values)

Then you can just run some CPU / GPU intensive task and check in HWinfo if it has any effect on PPTs / clocks / etc

[vddCore]

Download ACPICA tools from here: https://acpica.org/downloads/binary-tools Extract, run acpidump tool, then you can use the other tool called iasl to decompile resulting files to something that humans can read.

Both tools include comprehensive help messages, but if all you want to achieve is dumping your DSDT and decompiling it, run acpidump.exe -b to dump them all to .dat files. They’ll be placed in the location you ran the tool from. Then run iasl.exe dsdt.dat and the decompiled ACPI table will be created as dsdt.dsl.

[vddCore]

You’re better off directly telling the keyboard to do that for you, as the keypress handling is reliant on AsusOptimization, which ideally we’d like to get rid of completely down the line. Plus, allows you to better control the thing. https://github.com/vddCore/Starlight/blob/master/Starlight/Asus/Aura/AuraDevice.cs#L15

The protocol seems to be consistent between devices even though the hardware device IDs for keyboards on different laptops might differ. If we look hard enough there might be a way to ask the keyboard for its current state, but as of now I do not have enough information to be helpful in that regard.