Implement YogaSMC

[EETagent]

https://github.com/zhen-zen/YogaSMC https://github.com/benbender/x1c6-hackintosh

https://github.com/benbender/x1c6-hackintosh/blob/experimental/EFI/OC/dsl/SSDT-BATX.dsl https://github.com/benbender/x1c6-hackintosh/blob/experimental/EFI/OC/dsl/SSDT-PNLF-SMOOTH.dsl https://github.com/benbender/x1c6-hackintosh/blob/experimental/EFI/OC/dsl/SSDT-FNKEYS.dsl

[benbender]

Just a few remarks as there are several topics linked:

• YogaSMC is and will be great I'm sure, but it's not quite ready for primetime yet as the userclient-side of things is still developing. It will, among many other things, render the whole FNKey-patching obsolete. @zhen-zen does an amazing job. Praise him ;)

• BacklightSmoother: https://github.com/hieplpvip/AppleBacklightSmoother is ready, working and nice to have! Thanks @hieplpvip!

• BATX is my reimplementation of the old battery-patches for the X1C6. It reimplements the complete Battery-device from ACPI and therefore doesn't need any patches by itself. Its tailored to the needs of VirtualSMC, is cleaner, should be faster, more accurate and feature-complete. However, it doesn't support dual-battery-setups as of yet and needs more testing for edgecases... Sorry for now!

• Please check if you have accesses to _SB.PCI0.LPCB.EC.HWAC in _OWAK() and/or _L17() of your DSDT. I think you have and this access needs to be patched as it crashes in OWAK() on wakeup and might be the root of some of the bugs described here. Method + patch for the issue here: https://github.com/benbender/x1c6-hackintosh/blob/experimental/SSDT-HWAC.dsl

[EETagent]

To Reproduce Sleep + Wakeup, check sudo dmesg or syslog for ACPI-errors when accessing the HWAC-field...

I do not have any HWAC errors after wakeup log.txt

[benbender]

Please check your DSDT with macIASL for occurrences of "HWAC". There should be 3. One fieldUnit-declaration in the ECOR and two accesses. Just checked mine again to see if there were some changes and both accesses are there as described.

They will crash as it is a 16-Bit-field which isn't handled by the Darwin-kernel. Maybe the crash isn't visible because auf msgbuf-size and wake does produce some amount of logs...

PS: yes, I'm pretty sure the crash isn't visible because of 4k-msgbuf-size and the amount of itlwm-logs.

[EETagent]

Yes, I have one in the ECOR and twice here If (((\RRBF & 0x02) || (\_SB.PCI0.LPCB.EC.HWAC & 0x02))) Local0 = \_SB.PCI0.LPCB.EC.HWAC

I do not have any _L17 though

[benbender]

(\_SB.PCI0.LPCB.EC.HWAC & 0x02) should be in OWAK() which is called in _WAK() on wake and will crash. What Bios-Version are you on?

[Charlyo]

@benbender Whats the effect of the HWAC fix SSDT? Got HWAC accesses in both OWAK and _L17 in my T470.

[EETagent]

Method (XWAK, 1, NotSerialized)
    {
        ADBG ("OWAK")
        If (((Arg0 == 0x00) || (Arg0 >= 0x05)))
        {
            Return (WAKI) /* \WAKI */
        }

        \SPS = 0x00
        \_SB.PCI0.LPCB.EC.HCMU = 0x00
        \_SB.PCI0.LPCB.EC.EVNT (0x01)
        \_SB.PCI0.LPCB.EC.HKEY.MHKE (0x01)
        \_SB.PCI0.LPCB.EC.FNST ()
        \UCMS (0x0D)
        \LIDB = 0x00
        If ((Arg0 < 0x04))
        {
            If (((\RRBF & 0x02) || (\_SB.PCI0.LPCB.EC.HWAC & 0x02)))
            {
                Local0 = (Arg0 << 0x08)
                Local0 = (0x2013 | Local0)
                \_SB.PCI0.LPCB.EC.HKEY.MHKQ (Local0)
            }
        }

        \RRBF = Zero
        ADBG ("OWAK END")
        Return (WAKI) /* \WAKI */
    }

XWAK method ( I removed currently unnecessary ifs )

I am on currently unmodified N24ET60W, latest

[benbender]

@Charlyo You can't access the 16-bit-HWAC-EC-field directly in OSX. Those are, as said, 16-bit, which aren't handled by the Darwin-Kernel and will therefor crash. You need to split the access in two 8-bit fields and stick them together with the B1B2()-method.

The effect is that you won't have a crash on accessing the field ;)

@EETagent So you renamed OWAK to XWAK and calling it in your PTSWAK.dsl I guess. However, Arg0 will be 0x03 on sleep and 0x00 on wake. HWAC is accessed and will surely crash. Believe me or not. Patch it or not. I've gave you the hint and everything to fix it. I'm sorry, but I don't get what you are arguing about...

PS: In particular, any fields in the EC larger than 8-bit, must be changed to be accessed 8-bits at one time. This includes 16, 32, 64, and larger fields. - @Rehabman

Source: https://www.tonymacx86.com/threads/guide-how-to-patch-dsdt-for-working-battery-status.116102/

That's the reason for all the battery-patching in the first place...

[EETagent]

@EETagent So you renamed OWAK to XWAK and calling it in your PTSWAK.dsl I guess. However, Arg0 will be 0x03 on sleep and 0x00 on wake. HWAC is accessed and will surely crash. Believe me or not. Patch it or not. I've gave you the hint and everything to fix it. I'm sorry, but I don't get what you are arguing about...

Well, I am definitely not arguing and will implement this as your knowledge of this topic is definitely far more better than mine. Just wanted to be sure if its needed. I apologize if there were any misunderstandings in my poor English

[benbender]

Just some background info: With dmesg you are accessing the kernel-log. This is a so called ringbuffer of (by default) 4kb size (which can be patched to a larger size by DebugEnhancer.kext or to max 16kb via msgbuf-bootarg) and will only show, by default, the last 4kb of the kernel-log. If you get many log-entries, its perfectly possible you are missing many entries. The actual size of msgbuf is checked with sysctl -a kern.msgbuf.

To the bug: As said and known for years, those 16bit-accesses lead to crashes in ACPI and therefor, in this case, undefined/unknown state of the HW after wake as the wakeup-method can't run to its end.

At least I do now understand why hardly anyone catched that bug on different repos before (msgbuf-size) and I assume that thats, at least, part of those many bug-reports of undefined behaviour/powerdrain/etc after wake. That's why I tried to help out and give the needed infos in an accessible manner.

And yes, all this takes time and it's therefor a bit irritating if I have to argue, even if clearly stated before, why the fix is needed. If you don't believe me, that's fine. Do your own research, lern and get smarter. That's always the best :) No offense taken.

PS: Added background and reasoning to SSDT-HWAC.dsl in my repo.

[EETagent]

@benbender How is performance on your machine with YogaSMC? With latest "ACPI patches overhaul" commit in YogaSMC pull request, I'am getting 1200 points in Cinebench R20, DYTC configured to maximum performance . That's considerably lower than common 1500 what I get on Windows and current EFI. Turbo boost is not working probably.

[benbender]

Didn't test to that extend. Doesn't feel slower though... Try to narrow the factors down to just YogaSMC (same SSDT's and just turn YogaSMC on/off and test). If the problem manifests, open an issue over at the YogaSMC-repo.