Am 18.06.25 um 13:15 schrieb Werner Sembach:
Hi,
Am 17.06.25 um 23:50 schrieb Armin Wolf:
Am 16.06.25 um 14:32 schrieb Werner Sembach:
Hi,
Am 15.06.25 um 19:59 schrieb Armin Wolf:
[...]
+The EC behind the ``GetSetULong`` method is used by the OEM
software supplied by the manufacturer.
+Reverse-engineering of this software is difficult since it uses an
obfuscator, however some parts
+are not obfuscated.
Iirc Christoffer said there is also another non wmi, but acpi,
get/set cmd that can write only specific regions but is faster. Just
wanted to leave this here for potential future optimizations if you
are interested.
What interface are you referring to exactly?
I think he was referring to these 2 methods in the dsdt:
Scope (_SB)
{
Device (INOU)
{
[...]
Method (ECRR, 1, NotSerialized)
{
Local0 = (0xFE410000 + Arg0)
Local1 = MMRW (Local0, Zero, Zero, Zero)
Return (Local1)
}
Method (ECRW, 2, NotSerialized)
{
Local0 = (0xFE410000 + Arg0)
MMRW (Local0, One, Zero, Arg1)
}
[...]
}
}
They can read/write the 0x04xx and 0x07xx addresses but not the 0x18xx
ones iirc, don't know about the 0x0fxx ones.
I think 0x18xx was never intended to be written probably, but we use
it to implement a custom fan curve option in tuxedo-drivers on older
devices that officially don't support it.
Best regards,
Werner
I see, i too noticed the INOU0000 device during reverse engineering. I will update the documentation to inform future developers about this potentially
feaster interface. However for now i suggest that we stick to the WMI interface.
Thanks,
Armin Wolf