Create a correct SSDT for sleep, wake, and shutdown

[LeeBinder]

Hi whatnameisit. I hope to find you in good health and spirit.

Ever since switching to your OC release, I've had delayed shutdowns, even more so if booted via OC.

Your latest release' SSDT-PTS.aml+ corresponding patch improved the behavior somewhat, again more if booted via Clover, but still did not restore super-quick shutdown how it used to be when I was still using tctien's release.

So today I grabbed his _PTS part from the legacy SSDT-S510-KabyLakeR.aml, created SSDT-PTS_ tctien.aml, deactivated yours, activated his, reboot, shutdown -> all good again.

I tested this numerous times booted via both, OC and Clover, in Mojave and Catalina, incl. inserting some sleep/ wake cycles -> shutdown still speedy as it used to and supposed to be.

Here's the asl for you so you can see if this also speeds up your shutdowns:

DefinitionBlock ("", "SSDT", 2, "hack", "pts", 0x00000000)
{
    External (_SB_.PCI0.XHC_.PMEE, FieldUnitObj)
    External (RMCF.RMON, MethodObj)    // 0 Arguments
    External (RMCF.SHUT, IntObj)
    External (RMCF.XPEE, IntObj)
    External (ZPTS, MethodObj)    // 1 Arguments

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
         if (5 == Arg0)  // Shutdown fix, if enabled
        {
            If (CondRefOf(\RMCF.SHUT)) { If (\RMCF.SHUT) { Return } }
        }
        If (CondRefOf (\RMCF.RMON))  // enable discrete graphics
        {
            \RMCF.RMON ()
        }

        If ((Arg0 != 0x05))  // call into original _PTS method
        {
            ZPTS (Arg0)
        }

        If ((0x05 == Arg0))
        {
            If (CondRefOf (\RMCF.XPEE))
            {
                If ((\RMCF.XPEE && CondRefOf (\_SB.PCI0.XHC.PMEE)))
                {
                    \_SB.PCI0.XHC.PMEE = Zero
                }
            }
        }
    }
}

Your DefinitionBlock used "Slav" instead of hieplvip's "hack", but that shouldn't matter, should it.

Also (not worth opening a new issue for this): I saw you removed the Enable [TRIM] for SSD kernel patch. Shouldn't that be active as long as (at least one of) our built-in hard disk(s) is a SSD?

BTW, OC now at 0.6.8, in case you haven't enabled notifications. Massive step ahead. Going to start testing soon, then push a new release :)

[whatnameisit]

If you look at the original _PTS method, now renamed ZPTS, you can see there are methods, there are other things being done.

    Method (ZPTS, 1, NotSerialized)
    {
        If (Arg0)
        {
            ASFS (Arg0)
            \_SB.PCI0.LPCB.EC0.EC0S (Arg0)
            SBDS (Arg0)
            \_SB.TPM.TPTS (Arg0)
            \_SB.PCI0.LPCB.SPTS (Arg0)
            \_SB.PCI0.NPTS (Arg0)
            RPTS (Arg0)
        }
    }

The SSDT I added, which is provided by Dortania, executes the original code and fixes USB problems.

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
        ZPTS (Arg0) // Here this line means execute ZPTS with Arg0 _PTS has been executed with, which means execute original _PTS with Arg0,
        If ((0x05 == Arg0)) // The usual restart fix code.
        {
            \_SB.PCI0.XHC.PMEE = Zero
        }
    }

On the other hand, the one tctien342 provided does not execute the original code.

    Method (_PTS, 1, NotSerialized)  // _PTS: Prepare To Sleep
    {
         if (5 == Arg0)  // Shutdown fix, if enabled
        {
            If (CondRefOf(\RMCF.SHUT)) { If (\RMCF.SHUT) { Return } } // Not defined in any table, so does nothing.
        }
        If (CondRefOf (\RMCF.RMON))  // enable discrete graphics Not defined in any table, so does nothing.
        {
            \RMCF.RMON ()
        }

        If ((Arg0 != 0x05))  // call into original _PTS method only if USB devices aren't connected.
        {
            ZPTS (Arg0)
        }

        If ((0x05 == Arg0)) // Fix USB restart issues and do not call into original _PTS method.
        {
            If (CondRefOf (\RMCF.XPEE))
            {
                If ((\RMCF.XPEE && CondRefOf (\_SB.PCI0.XHC.PMEE)))
                {
                    \_SB.PCI0.XHC.PMEE = Zero
                }
            }
        }
    }

Most of the times this SSDT does not prepare for shutdown and just shuts down, resulting in faster sleep. I can assume this is bad for your laptop. I'll see if I have time to update OC today. If not, tomorrow :)

[LeeBinder]

Thanks for the explanations. So you're saying this part

{
        If (CondRefOf(\RMCF.SHUT)) { If (\RMCF.SHUT) { Return } } // Not defined in any table, so does nothing.
}
        If (CondRefOf (\RMCF.RMON))  // enable discrete graphics Not defined in any table, so does nothing.
{
        \RMCF.RMON ()
}

can safely be deleted? -> resulting SSDT:

click to expand

```javascript DefinitionBlock ("", "SSDT", 2, "hack", "pts", 0x00000000) { External (_SB_.PCI0.XHC_.PMEE, FieldUnitObj) External (RMCF.XPEE, IntObj) External (ZPTS, MethodObj) // 1 Arguments Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep { If ((Arg0 != 0x05)) { ZPTS (Arg0) } If ((0x05 == Arg0)) { If (CondRefOf (\RMCF.XPEE)) { If ((\RMCF.XPEE && CondRefOf (\_SB.PCI0.XHC.PMEE))) { \_SB.PCI0.XHC.PMEE = Zero } } } } } ```

Most of the times this SSDT does not prepare for shutdown and just shuts down, resulting in faster sleep

so this PTS SSDT is influencing both kinds of "shutdown": the "real" shutdown aka power-off, and the pre-sleep preparation phase - correct?

Would it make sense and have any benefits to merge Dortania's SSDT into tctien342's so the original code does get executed? Or would that simply leave me with Dortania's SSDT?

If it did make sense, how would the resulting SSDT's code I can try here look like? I have no idea so I'm asking you.

PS: maybe this slipped your attention, so excuse if I ask again: I saw you removed the Enable [TRIM] for SSD kernel patch. Shouldn't that be active as long as (at least one of) our built-in hard disk(s) is a SSD?

[whatnameisit]

can safely be deleted?

You can look into the ACPI space and see if any OEM or injected tables define RMCF IntObjs. From what I know, RehabMan is the author of that code. https://github.com/RehabMan/OS-X-Clover-Laptop-Config/blob/master/hotpatch/SSDT-RMCF.dsl If there are RMCF objects can you post the content here? I don't think there are anywhere though.

Would it make sense and have any benefits to merge Dortania's SSDT into tctien342's so the original code does get executed? Or would that simply leave me with Dortania's SSDT?

You would want to delete tctien342's SSDT, but use Dortania's SSDT and added contents and have users debug it because dGPU needs to be turned on at sleep and off at wake.

And about trim, it did slip my mind when I last replied. It's option to turn on or off the trim support for SATA SSDs. It's also necessary if you want hibernation. I'm not using hibernation, and I can't tell the difference with it on and off, so I'm not using it.

[LeeBinder]

If there are RMCF objects can you post the content here? I don't think there are anywhere though.

nothing via ioreg. Via patchmatic: nothing in DSDT; only occurrences in SSDT-18-PNLF.aml, but you know those:

    External (RMCF.BKLT, IntObj)
    External (RMCF.FBTP, IntObj)
    External (RMCF.GRAN, IntObj)
    External (RMCF.LEVW, IntObj)
    External (RMCF.LMAX, IntObj)

You would want to delete tctien342's SSDT, but use Dortania's SSDT and added contents

I admit I'm rather unclear what exact content to add. If you can shake a merged SSDT out of your sleeve or easily pull it out of your magic .asl hat ;) - fine. If it's too complicated even for you, don't bother.

dGPU needs to be turned on at sleep and off at wake

that's what If (CondRefOf (\RMCF.RMON)) // enable discrete graphics indicates (I need to admit this line made me frown because it seems counter-intuitive)

and have users debug it

hmm I doubt anyone would volunteer. Also tctien did have a VivoBook with dGPU so I'm fairly confident his SSDT is working in that regard. Also: wouldn't SSDT-RP01_PEGP.aml and -wegnoegpu take care of that on a deeper level?

Obviously this code and tctien's _PTS SSDT don't do any harm on my non-dGPU VivoBook but in contrast are an issue-resolver, so I doubt it would do any harm on a dGPU VivoBook?

Have you tried it yet and if so, do you get faster shutdowns?

(on a side note, I've ordered the Fenvi card - expected to be here in two weeks. My IT gut sense tells me there is a good chance once I've gotten rid of the Lenovo FRU, I might have quick shutdowns even with Dortania's PTS SSDT..)

[LeeBinder]

oops, trim: from what I understand, macOS performs it in the background so it's not possible directly/ openly to tell the difference with it on and off. The hardware guru here in town said my first hackintosh's SSD most likely died prematurely because I didn't have trim enabled for OS X, so I'll re-enable it in the upcoming release.

[whatnameisit]

What I'm going to write here would require a little knowledge in ACPI.

PNLF: RehabMan took part in writing AppleBacklightFixup.kext and that's where those RMCF came from I think.

Added contents, turn off dGPU, -wegnoegpu, dGPU turn on at sleep and off at wake: The traditional method to disable dGPU and cut its power was via SSDT. Now there's -wegnoegpu which only disables dGPU and not the power: https://dortania.github.io/Getting-Started-With-ACPI/Laptops/laptop-disable.html Then there's this: https://www.tonymacx86.com/threads/guide-disabling-discrete-graphics-in-dual-gpu-laptops.163772/ This is what I meant by added contents. RMCF.RMON was the way to turn on dGPU at shutdown/sleep for RehabMan. He would have defined RMON for his own laptop in other SSDT. If something is not defined it can't be used. Hence defining RMON elsewhere and using it in _PTS and declaring it External. But there's no RMON in tctien342's or your hackintosh. So make dGPU turn on at sleep with _PTS and off at wake with _WAK. You could use hints. The corresponding OFF can be found in SSDT-RP01_PEGP.aml.

Trim: thanks for bringing that up. I looked up and trim does extend SSD lifespan by not processing and just discarding files that are not needed. You don't have to write the kernel patch for OpenCore. There's ThirdPartyDrives in Kernel/Quirks.

Shutdown speed: I have not tested shutdown with tctien342's SSDT and I won't. I've said the reasons not to use that SSDT. It's similar to not turning on trim support. Doesn't seem to cause harm but it does.

[LeeBinder]

@whatnameisit just real quick 'cause I just have a minute: got it working thanks to your tenacity 👍 - more later :)

[LeeBinder]

allright, here we go

But there's no RMON in tctien342's or your hackintosh.

Isn't Method RMON defined by this code in SSDT-RP01_PEGP.aml

 Method (RMON, 0, NotSerialized)
        {
            If (CondRefOf (\_SB.PCI0.RP01.PEGP._ON))
            {
                \_SB.PCI0.RP01.PEGP._ON ()
            }
        }

and isn't that enough for those with dGPU as long as they have SSDT-RP01_PEGP.aml + tctien's original SSDT-PTSWAK.aml (for both, sleep and wake) + -wegnoegpu enabled?

SSDT-PTSWAK.dsl - click to expand

```javascript DefinitionBlock ("", "SSDT", 2, "hack", "ptswak", 0x00000000) { External (_SB_.PCI0.XHC_.PMEE, FieldUnitObj) External (_SI_._SST, MethodObj) // 1 Arguments External (RMCF.RMOF, MethodObj) // 0 Arguments External (RMCF.RMON, MethodObj) // 0 Arguments External (RMCF.SHUT, IntObj) External (RMCF.SSTF, IntObj) External (RMCF.XPEE, IntObj) External (ZPTS, MethodObj) // 1 Arguments External (ZWAK, MethodObj) // 1 Arguments Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep { If ((0x05 == Arg0)) { If (CondRefOf (\RMCF.SHUT)) { If (\RMCF.SHUT) { Return (Zero) } } } If (CondRefOf (\RMCF.RMON)) { \RMCF.RMON () } If ((Arg0 != 0x05)) { ZPTS (Arg0) } If ((0x05 == Arg0)) { If (CondRefOf (\RMCF.XPEE)) { If ((\RMCF.XPEE && CondRefOf (\_SB.PCI0.XHC.PMEE))) { \_SB.PCI0.XHC.PMEE = Zero } } } } Method (_WAK, 1, NotSerialized) // _WAK: Wake { If (((Arg0 < One) || (Arg0 > 0x05))) { Arg0 = 0x03 } Local0 = ZWAK (Arg0) If (CondRefOf (\RMCF.RMOF)) { \RMCF.RMOF () } If (CondRefOf (\RMCF.SSTF)) { If (\RMCF.SSTF) { If (((0x03 == Arg0) && CondRefOf (\_SI._SST))) { \_SI._SST (One) } } } Return (Local0) } } ```

In case you're not sufficiently happy with this: what would your code suggestion for a SSDT-PTS-dGPU looke like - what would it be?

For me, the code I posted before, streamlined as much as feasible for me accdg. to your suggestions, eventually IS working fine now - after NVRAM reset .. (dah..):

SSDT-PTS-BuxB - click to expand

```javascript DefinitionBlock ("", "SSDT", 2, "hack", "pts", 0x00000000) { External (_SB_.PCI0.XHC_.PMEE, FieldUnitObj) External (RMCF.XPEE, IntObj) External (ZPTS, MethodObj) // 1 Arguments Method (_PTS, 1, NotSerialized) // _PTS: Prepare To Sleep { If ((Arg0 != 0x05)) { ZPTS (Arg0) } If ((0x05 == Arg0)) { If (CondRefOf (\RMCF.XPEE)) { If ((\RMCF.XPEE && CondRefOf (\_SB.PCI0.XHC.PMEE))) { \_SB.PCI0.XHC.PMEE = Zero } } } } } ```

cleared of any instances of RMCF.RMON and RMCF.SHUT.

With my (however limited) understanding of ACPI I dare say I'm happy with what I dubbed SSDT-PTS-BuxB and don't see any obvious reason how that code could cause any harm, esp. since it's working, in contrast to the Dortania SSDT.

[whatnameisit]

Isn't Method RMON defined by this code in SSDT-RP01_PEGP.aml

Apparently it is XD I asked you if you have it in your configuration before and you only posted the contents in PNLF so I assumed there wasn't RMON.

don't see any obvious reason how that code could cause any harm, esp. since it's working, in contrast to the Dortania SSDT.

Things I posted before have the answers to your questions. like this:

Most of the times this SSDT does not prepare for shutdown and just shuts down, resulting in faster sleep. I can assume this is bad for your laptop.

and this for turning on and off dGPU at sleep and wake: https://www.tonymacx86.com/threads/guide-disabling-discrete-graphics-in-dual-gpu-laptops.163772/

[whatnameisit]

I've had a busy week. I'll see if I can write the SSDT tonight or tomorrow.

[whatnameisit]

ACPI tables from hieplpvip's Zenbook repo: SSDT-RP01_PEGP.dsl

    Device(RMCF)
    {
        Name(_ADR, 0)   // do not remove
        Method(RMOF) { If (CondRefOf(\_SB.PCI0.RP01.PEGP._OFF)) { \_SB.PCI0.RP01.PEGP._OFF() } }
        Method(RMON) { If (CondRefOf(\_SB.PCI0.RP01.PEGP._ON)) { \_SB.PCI0.RP01.PEGP._ON() } }
        Method(HGOF, 1) { If (CondRefOf(\_SB.PCI0.HGOF)) { \_SB.PCI0.HGOF(Arg0) } }
    }

The methods in this SSDT are not prefixed _ which means they will not be executed by themselves unless called from other methods. So SSDT-RP01_PEGP.aml by itself won't do anything. Let's see what the above code means. RMCF.RMOF: Turn off dGPU. We can guess by the prefixed method _OFF. It still has to be executed from _PTS on sleep. RMCF.RMON: Turn on dGPU. We can guess by the prefixed method _ON. It still has to be executed from _WAK on wake. RMCF.HGOF: Have to look at what _SB.PCI0.HGOF does in OEM ACPI, or what did hieplpvip do with it?

HGOF: Googling HGOF you can see it's related to turning off fan on NVidia Optimus laptops. Grepping HGOF in hieplpvip's repo, SSDT-HACK.dsl mentions RMCF.HGOF and the comment says it's for turning off dGPU fan.

    Scope(_SB.PCI0.LPCB.EC0)
    {
        OperationRegion(RME3, EmbeddedControl, 0x00, 0xFF)
        Method(_REG, 2)
        {
            XREG(Arg0, Arg1) // call original _REG, now renamed XREG
            If (3 == Arg0 && 1 == Arg1) // EC ready?
            {
                 If (CondRefOf(\RMCF.HGOF)) { \RMCF.HGOF(1) } // turn dedicated Nvidia fan off
            }
        }
    }

So turn off dGPU fan. The grep result is that _SB.PCI0.HGOF is mentioned in SSDT-7.aml to SSDT-10.aml. Open them up and find the method is defined in SSDT-8.aml. We can see it uses embedded controller to do its job. So as per RehabMan's guide that EC needs to be ready before anything related to EC is executed by checking Arg0=3 and Arg1=1 in _REG and hieplpvip did it right.

Let's look at SSDT-PTSWAK.dsl also from hieplpvip's repo:

    Method(_PTS, 1)
    {
        if (5 == Arg0)
        {
            // Shutdown fix, if enabled
            If (CondRefOf(\RMCF.SHUT)) { If (\RMCF.SHUT) { Return } }
        }

        // enable discrete graphics
        If (CondRefOf(\RMCF.RMON)) { \RMCF.RMON() }

        // call into original _PTS method
        If (LNotEqual(Arg0,5)) { ZPTS(Arg0) }

        If (5 == Arg0)
        {
            // XHC.PMEE fix, if enabled
            External(\_SB.PCI0.XHC.PMEE, FieldUnitObj)
            If (CondRefOf(\RMCF.XPEE)) { If (\RMCF.XPEE && CondRefOf(\_SB.PCI0.XHC.PMEE)) { \_SB.PCI0.XHC.PMEE = 0 } }
        }
    }
    Method(_WAK, 1)
    {
        // Take care of bug regarding Arg0 in certain versions of OS X...
        // (starting at 10.8.5, confirmed fixed 10.10.2)
        If (Arg0 < 1 || Arg0 > 5) { Arg0 = 3 }

        // call into original _WAK method
        Local0 = ZWAK(Arg0)

        // disable discrete graphics
        If (CondRefOf(\RMCF.RMOF)) { \RMCF.RMOF() }

        If (CondRefOf(\RMCF.SSTF))
        {
            If (\RMCF.SSTF)
            {
                // call _SI._SST to indicate system "working"
                // for more info, read ACPI specification
                External(\_SI._SST, MethodObj)
                If (3 == Arg0 && CondRefOf(\_SI._SST)) { \_SI._SST(1) }
            }
        }

        // return value from original _WAK
        Return (Local0)
    }

It's good that RMCF.RMON is executed on sleep and RMOF on wake. But RMCF.SHUT, XPEE, and SSTF are not defined in this repo. These RehabMan's Custom Functions can be made to work if you do define SHUT, XPEE, and SSTF. RehabMan's repo: SHUT: Has to do with SLPE. Outdated / not needed. XPEE: Whether to fix USB or not. Well, we have to fix it or the laptop will wake up. Get rid of XPEE check. SSTF: Has to do with indicating the system is working. _SI._SST is not defined in OEM ACPI and therefore is not needed.

Cleaning up gives us this:

    Method(_PTS, 1)
    {        
        // enable discrete graphics
        If (CondRefOf(\RMCF.RMON)) { \RMCF.RMON() }

        // call into original _PTS method
        If (LNotEqual(Arg0,5)) { ZPTS(Arg0) }

        If (5 == Arg0)
        {
            External(\_SB.PCI0.XHC.PMEE, FieldUnitObj)
            \_SB.PCI0.XHC.PMEE = 0 
        }
    }
    Method(_WAK, 1)
    {
        // call into original _WAK method
        Local0 = ZWAK(Arg0)

        // disable discrete graphics
        If (CondRefOf(\RMCF.RMOF)) { \RMCF.RMOF() }

        // return value from original _WAK
        Return (Local0)
    }

Now I'm still wondering why did hieplpvip leave out _PTS contents to not prepare for sleep/shutdown and just sleep/shutdown? Outdate patch. It's Shutdown Fix V2 in RehabMan's MaciASL. There's no explanation on why it must be used. RehabMan did not use it himself though. You can see that he made newly defined _PTS execute the original ZPTS without condition, so he did not apply Shutdown Fix V2 in his hotpatch. Others used the Shutdown Fix V2. Why? They probably had problems with sleep/shutdown and tried to ignore sleep/shutdown procedure defined by the OEM. Maybe hieplpvip made a typo.

Anyways, don't ignore that procedure:

    Method(_PTS, 1)
    {        
        // enable discrete graphics
        If (CondRefOf(\RMCF.RMON)) { \RMCF.RMON() }

        // call into original _PTS method
        ZPTS(Arg0)

        If (5 == Arg0)
        {
            External(\_SB.PCI0.XHC.PMEE, FieldUnitObj)
            \_SB.PCI0.XHC.PMEE = 0 
        }
    }

That's all the information. Since you support patches for Optimus NVidia laptops, let's rearrange the ACPI so it makes the most sense. There's no way to insert contents into a method that's already defined. Why I say is that if you re-define _PTS and leave _WAK as is for non-Optimus laptops, you can't insert RMON and RMOF codes into _PTS and _WAK for Optimus laptops. Either you have to define different _PTS and _WAK for non-Optimus and Optimus meaning different sets of SSDTs or you have to write conditions. For the former, two PTSWAK SSDTs plus inject SSDT-RP01_PEGP.aml or don't inject. For the latter, one giant SSDT-PTSWAK-RP01_PEGP.aml. Let's go with the latter because that's what I want and the conditions are already written. Bring together cleaned up _PTS and _WAK, patched _REG, and RMCFs.

DefinitionBlock ("", "SSDT", 2, "hack", "SHSLWAK", 0)
{
    External (ZPTS, MethodObj)
    External (ZWAK, MethodObj)
    Method(_PTS, 1)
    {        
        // execute RMON
        \RMCF.RMON()

        // call into original _PTS method
        ZPTS(Arg0)

        If (5 == Arg0)
        {
            External(\_SB.PCI0.XHC.PMEE, FieldUnitObj)
            \_SB.PCI0.XHC.PMEE = 0 
        }
    }
    Method(_WAK, 1)
    {
        // call into original _WAK method
        Local0 = ZWAK(Arg0)

        // execute RMOF
        \RMCF.RMOF()

        // return value from original _WAK
        Return (Local0)
    }
    External(_SB.PCI0.RP01.PEGP, DeviceObj)
    External(_SB.PCI0.RP01.PEGP._OFF, MethodObj)
    External(_SB.PCI0.RP01.PEGP._ON, MethodObj)
    External(_SB.PCI0.HGOF, MethodObj)
    Device(RMCF)
    {
        Name(_ADR, 0)   // do not remove
        // if _OFF exists, execute it
        Method(RMOF) { If (CondRefOf(\_SB.PCI0.RP01.PEGP._OFF)) { \_SB.PCI0.RP01.PEGP._OFF() } }
        // if _ON exists, execute it
        Method(RMON) { If (CondRefOf(\_SB.PCI0.RP01.PEGP._ON)) { \_SB.PCI0.RP01.PEGP._ON() } }
        // if OEM HGOF exists, execute it
        Method(HGOF, 1) { If (CondRefOf(\_SB.PCI0.HGOF)) { \_SB.PCI0.HGOF(Arg0) } }
    }
    External(_SB.PCI0.LPCB.EC0, DeviceObj)
    External(_SB.PCI0.LPCB.EC0.XREG, MethodObj)
    External(RMCF.HGOF, MethodObj)
    Scope(_SB.PCI0.LPCB.EC0)
    {
        OperationRegion(RME3, EmbeddedControl, 0x00, 0xFF)
        Method(_REG, 2)
        {
            XREG(Arg0, Arg1) // call original _REG, now renamed XREG
            If (3 == Arg0 && 1 == Arg1) // EC ready?
            {
                 \RMCF.HGOF(1) // execute RMCF.HGOF
            }
        }
    }
}

And let's borrow _REG to XREG from hieplpvip's repo. It's for Clover.

                <dict>
                    <key>Comment</key>
                    <string>rename _REG to XREG in EC0</string>
                    <key>Find</key>
                    <data>X1JFRwKgCw==</data>
                    <key>Replace</key>
                    <data>WFJFRwKgCw==</data>
                </dict>

I don't think I can be any clearer. This is as far as I go.

[LeeBinder]

wow - just got back late at nite and find your gift here before catching some sleep - amazing. Thank you so much for diving in that deep after a full week and even explain every step!

I will test tomorrow nite, and report back. You can sure enjoy a more than well deserved week-end 🥇

[whatnameisit]

There are couple more things to be done.

1. RMCF is an intermediate device that intercepts methods. But it executes them anyways. It's not really needed so just cut straight to the actual methods that turn devices on and off.
2. You need to make the patch OS-specific or the code will break Optimus laptop on non-Darwin.
3. _WAK needs to be renamed to ZWAK for the wake patch to work.

I'll leave it up to you. These are very simple if you follow Dortania's examples.

[LeeBinder]

I'll leave it up to you. These are very simple if you follow Dortania's examples.

I'll do my best. I feel a bit sick right now so I might need a few days to get back on track. A few questions already in advance:

There are couple more things to be done.

1. RMCF is an intermediate device that intercepts methods. But it executes them anyways. It's not really needed so just cut straight to the actual methods that turn devices on and off.

I searched dortania.github.io for RMCF but there is only 1 result and it does not apply here. Is there any code I need to add or change in regards to RMCF?

2. You need to make the patch OS-specific or the code will break Optimus laptop on non-Darwin.

With "patch" do you mean the _REG to XREG patch from hieplpvip's repo, or the SSDT?

If SSDT: in Clover I'd say that's easy because ACPI/patched only applies to macOS anyway. From what I read, OC does not offer such an easy way like Clover (wondering why can be left aside here). Are you alluding to inserting something like

 If (_OSI ("Darwin"))
                {
                    Return (0x0F)
                }
                Else
                {
                    Return (Zero)
                }

placing at the very top of the SSDT, replacing Return (0x0F) with your SSDT's functional content?

3. _WAK needs to be renamed to ZWAK for the wake patch to work.

Simply/ only by re-adding this from tctien legacy config.plist?:

<dict>
    <key>Find</key>
    <data>X1dBSwE=</data>
    <key>Replace</key>
    <data>WldBSwE=</data>
    <key>Disabled</key>
    <false/>
    <key>Comment</key>
    <string>change Method(_WAK,1,N) to ZWAK, pair with SSDT-PTSWAK.aml</string>
</dict>

If this additional patch is indeed all that's needed, even though your new SSDT is unified for users with and without dGPU, do I stand correct from reading your explanations that only users with Nvidia Optimus dGPU VivoBooks should actively ENable this patch for them, but that it should remain DISabled for UHD 620 only users?

[EDIT]: jsassu20/OpenCore-HotPatching-Guide differentiates between:

_WAK to ZWAK(1,N) ->

 Method (_WAK, 1, NotSerialized)  /* _WAK: Wake */
  {

which is what tctien mentioned, and _WAK to ZWAK(1,S): ->

Method (_WAK, 1, Serialized)  /* _WAK: Wake */
  {

vs. in your SSDT Method(_WAK, 1)

Just thought I'd mention in case it's of any importance.

[whatnameisit]

Please read through Dortania's examples. That's what I meant by follow the examples. There's gotta be a first in learning. Please try to understand everything I've written, both the code itself and the comments in it and the reasons behind. I may be harsh, but if you don't know hotpatching, just drop NVidia support and stick to my _PTS patch. And why not Google Serialized and NotSerialized to see if it's of any importance and why not check the original definition of _PTS and _WAK to see what you have to choose between Serialized and NotSerialized?

[LeeBinder]

I wish I had more time and energy to do just that because it does fascinate me. With my new job and my limited health right now it's unfortunately out-of-reach for me :( . In addition the harsh lockdown measures here are really starting to wear me down and take an additional toll.

So that your work does not hang shortly before completion, in an effort to try continue tctien's legacy to serve users with NVidiadGPUs , what I'd do then is file a request in the DSDT/ SSDT forum section, hoping someone with sufficient background knows to carry out your instructions without a steep learning curve.

Please just let me know two things with simple yes or no answers, @whatnameisit:

1. am I on the right track with If (_OSI ("Darwin")) to make the patch OS-specific?
2. is the patch change Method(_WAK,1,N) to ZWAK I quoted above correct?

[whatnameisit]

1. I re-read what you said and the answer is yes.
2. If you are asking the patch is correct with what it's meant to do, then I'd say decompile the DSDT's hex codes with iasl which you can find in RehabMan's hotpatch guide because I won't do it myself. If you are asking the patch would actually be applied, then I wouldn't know unless I decompiled the DSDT and checked the new SSDT. But it's been in the commit history the whole time so if you can't trust it, I would say neither can I. I also said check the original _WAK definition to see if it's Serialized and NotSerialized in my previous reply.

I've started from Dortania's Getting started with ACPI first page and found things about the usage of If (_OSI ("Darwin")) in 10 minutes. I read how to disable laptop dGPU in 5 minutes and to come up with how to execute the code in the simplest way without going through RMCF I would give about 10 minutes. I would fire up the laptop and use patchmatic or MaciASL to see currently applied ACPI tables and look up original definition of _REG, _PTS, _WAK in 5 minutes. Please consider doing what I said in my previous reply. It's not really time consuming. Asking the same thing multiple times because you wouldn't do the actual thing yourself and going against the answer and explanation I gave is really tiring me out. Like just because you think you have no problem with discarding the original _PTS when I said it would hurt with reasons. I said no in my first reply and no again in my third reply. You ended up with

and isn't that enough for those with dGPU as long as they have SSDT-RP01_PEGP.aml + tctien's original SSDT-PTSWAK.aml (for both, sleep and wake) + -wegnoegpu enabled?

That's a third. Did you ask your tech expert if your SSD did really die from not enabling trim three times? It'd be a double standard if you didn't.

[whatnameisit]

Even though I said I won't do it, here's the complete work. Look into the file and copy the binary patch to config.plist. SSDT-PTSWAK-RP01_PEGP.zip This really is the last time I help you until you give yourself enough time, skills, and reasons to own a hackintosh. Well at that time, you won't need my help at all because you would be an expert in hackintosh.

[LeeBinder]

Who would've thought.. No matter what, I do like your bone-dry humor. Started to test right now but have to continue tomorrow. Can let you know then.

[whatnameisit]

I'm not trying to be funny. Please take it seriously.