Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State of fan readings/curves #114

Open
yjmd2222 opened this issue Jun 21, 2024 · 7 comments
Open

State of fan readings/curves #114

yjmd2222 opened this issue Jun 21, 2024 · 7 comments

Comments

@yjmd2222
Copy link

The most recent commits include some things about fan readings. Anybody knows anything about them? I think hiep tried to see if setting fan curve works directly via WMI/EC in the "experimental fan code," but have no idea on the current status.
ACPIPoller introduces a third-party module to always poll on the fan to measure the current/cumulative fan/temperature, so I guess it uses up a lot of resources, hence not used in the OC branch of the Zenbook repo.
The fan readings are not published as are. Had to use SMCSuperIO.kext and the corresponding properties for "generic" device kindly provided by BrandTime for the actual readings by iStat menus and Macs Fan Control. But even so the min/max rpms are invalid (65345 something).
Anyone would like to share their experience or information?

@yjmd2222
Copy link
Author

Interesting findings here: https://www.hackintosh-forum.de/forum/thread/58108-asus-notebook-fan-control-acpi-schreiben-in-ec-ram/ and the issue link in it.
There's a temperature table in the EC RAM which is picked up by the fan mechanism to spin at certain levels at the corresponding temperatures.

@HolzMichel, I'm guessing you are the one that started the thread above. Have you had any more progress other than updating this table with ACPIDebug? And I'm not trying to be offensive, but parts of your offsets and the SSDT are probably wrong, as hexadecimal numbering does not go from 9 to 10. It should be ..., 0x539, 0x53a, 0x53b,...

@HolzMichel
Copy link

Hello @yjmd2222 ,
yes this is an excel auto fill issue, in my real implementation it is correct of course….
I have been using this method for more than a year now and it works very well.
I have two Automator scripts, one runs on startup and sets the „silent“ fan curve.
The other one has a small GUI and let’s me select different modes: silent, full speed, stock and so on.

If it is beneficial for you I can upload what I did here.

@yjmd2222
Copy link
Author

Hello.
It'd be great to see your scripts. Not only me but all others could benefit from them.

@yjmd2222
Copy link
Author

yjmd2222 commented Jul 3, 2024

@HolzMichel, please feel free to upload your scripts any time :)
Meanwhile, I tried to see if setting the values within the ACPI itself is possible. Ugly and nested usage of ECAV, but the log shows successful writes. I only set the first five bytes though.

    Scope (\_SB.PCI0.LPCB.EC0)
    {
        Device (YJMD)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
            {
                If (ECAV ())
                {
                    \RMDT.P1 ("RMDT debug: EC available")
                    \RMDT.P1 ("RMDT debug: Writing to Fan Temp table")
                    \_SB.PCI0.LPCB.EC0.WRAM (0x0537, 0x3C)
                    \_SB.PCI0.LPCB.EC0.WRAM (0x0538, 0x3E)
                    \_SB.PCI0.LPCB.EC0.WRAM (0x0539, 0x40)
                    \_SB.PCI0.LPCB.EC0.WRAM (0x053A, 0x42)
                    \_SB.PCI0.LPCB.EC0.WRAM (0x053B, 0x44)
                    \RMDT.P1 ("RMDT debug: Reading Fan Temp table")
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x0537))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x0538))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x0539))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x053A))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x053B))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x053C))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x053D))
                    \RMDT.P1 (\_SB.PCI0.LPCB.EC0.RRAM (0x053E))
                }
                Else
                {
                    \RMDT.P1 ("RMDT debug: EC not available")
                }
            }

            Method (_STA, 0, NotSerialized)  // _STA: Status
            {
                If (_OSI ("Darwin"))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }
            }
        }

Interestingly, there are two definitions of ECAV object in the ACPI. One in H_EC and the other in EC0. I'm no expert in this area, but I chose EC0.ECAV because it's about writing to and reading the EC RAM if I'm not wrong.
Sorry for misinformation if anybody was interested (This is to say the above striked-through writing was wrong, but my SSDT works sorry again). I was thinking I saw LPCB.ECAV and EC0.ECAV, but I mistook H_EC for LPCB. LPCB is the parent object of H_EC or EC0 in Intel. In most ASUS DSDTs, there exist H_EC and H_EC.ECAV (and EC0 and EC0.ECAV). No LPCB.ECAV anywhere. H_EC and EC0 are common ACPI names for embedded controller in Intel boards. To my knowledge, there can only be one embedded controller, and so either H_EC or EC but not both. And in our laptops, the only actual present device name for the embedded controller, EC0. Checking for availability of H_EC via H_EC.ECAV would not have worked because it's not there and because I am probing EC0. And checking availiability of LPCB.ECAV if that was actually present would not fit here because as I said EC RAM (EC0 RAM) is what's important here.

@HolzMichel
Copy link

HolzMichel commented Jul 4, 2024

@yjmd2222 your approach also looks promising and should work. If I remember correctly I initially tried to do it via SSDT but I couldn’t get the timing right so that either the system kept overwriting the registers with default values again or it never got set - did not know how to really debug this either.
Finally I decided against a deeper dive into ACPI because in newer macOS versions the color banding issue of the iGPU can no longer be addressed by spoofing so the lifetime of this hardware is kind of limited.
I did not forget about you, just couldn’t get my hands on the ZenBook yet.

@yjmd2222
Copy link
Author

yjmd2222 commented Jul 4, 2024

Before someone mentioned the visual artifacts were fixed with AAPL.GfxYTile set to 1: EETagent/T480-OpenCore-Hackintosh#32 (comment)
The revised WEG manual says either spoof to SKL or set AAPL.GfxYTile.

You might want to set that property in DeviceProperties.

Another suggestion is use OCLP and spoof as SKL.

@HolzMichel
Copy link

Wow, that’s nice. I did intense research this winter but could not find this. Will give it a try for sure.
Maybe I will get hands on the zenbook this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants