[Guide] Razer Blade 15 (2018) Detailed Install Guide High Sierra 10.13.6 (17G2208-17G5019)

[tane123]

So I'm booting using opencore on my razer blade 15. Trouble is I cant get my trackpad to work? I followed stonevils guide for trackpad patching and gpio patching but mo luck? Any idea why @Mr.Crab ? I'm using Catalina and everything is working besides the trackpad and GPU of course. The kexts I've used are voodooi2c and voodooi2chid. My dsdt patches were done using patchmatic. Could that be a problem?

 

[Mr.Crab]

So I'm booting using opencore on my razer blade 15. Trouble is I cant get my trackpad to work? I followed stonevils guide for trackpad patching and gpio patching but mo luck? Any idea why @Mr.Crab ? I'm using Catalina and everything is working besides the trackpad and GPU of course. The kexts I've used are voodooi2c and voodooi2chid. My dsdt patches were done using patchmatic. Could that be a problem?

You've used latest EFI from my GitHub repo? If so you shouldn't have to do any patching, trackpad should just work. Then if you want to do GPIO pinning that's another story.

 

[tane123]

@Mr.Crab You efi works perfectly thank you! The only problem I have is that right clicking doesn't work. Also do you know how to check if GPIO pining was applied successfully? I done it using a ddst patch and you efi but unsure if it has applied properly

 

[Mr.Crab]

@Mr.Crab You efi works perfectly thank you! The only problem I have is that right clicking doesn't work. Also do you know how to check if GPIO pining was applied successfully? I done it using a ddst patch and you efi but unsure if it has applied properly

Right click should work, check trackpad settings in system prefs on how exactly it should.
In OC you have to include every .aml file via config.plist.
To check if pinning is applied I don’t remember how, should be somewhere on page 50, or page 90 or page 120, on this thread

 

[veterantroller]

@Mr.Crab You efi works perfectly thank you! The only problem I have is that right clicking doesn't work. Also do you know how to check if GPIO pining was applied successfully? I done it using a ddst patch and you efi but unsure if it has applied properly

Check out the guide by @stonevil on Github. He goes step by step on how to do it. On a similar note @Mr.Crab, @takki how exactly do you guys dump all the DSDT and SSDT files while using OpenCore? it used to be very simple using Clover but now I can't do it.

 

[Mr.Crab]

Check out the guide by @stonevil on Github. He goes step by step on how to do it. On a similar note @Mr.Crab, @takki how exactly do you guys dump all the DSDT and SSDT files while using OpenCore? it used to be very simple using Clover but now I can't do it.

The dump thing is a bit cumbersome at the moment, so I have another usb with just clover on it and dump with that.

 

[Mr.Crab]

Turned Thunderbolt back on in UEFI settings and the trick with apple-logo-sleep worked DD
Now I finally have it at 144hz, niceeeeeeeeeeee.
Still a workaround though, has to be another way.

 

[Mr.Crab]

Guys, I finally fixed it. I debugged my DSDT using RehabMans OS-X-ACPI-Debug and it all came down to one faulty method. Just deleting the contents solves the issue completely and I can now finally use sleep without the gpu going crazy afterwards. Also opening the lid now brings up the login screen immediately instead of having to close and open it again. So might be interesting for you guys as well @vettz500 and @Mr.Crab .

This is the method that needs patching:

Method (RTEC, 0, NotSerialized)
{
    Store (YEAR, Local0)
    Store (FBC (Local0), RTYR)
    Store (MON, Local0)
    Store (FBC (Local0), RTMH)
    Store (DAY, Local0)
    Store (FBC (Local0), RTDY)
    Store (HOR, Local0)
    Store (FBC (Local0), RTHR)
    Store (MIN, Local0)
    Store (FBC (Local0), RTME)
}

Just deleting the contents of the method is probably not the most elegant solution but I couldn't figure out how to make it work otherwise. The Problem is that the variable Local0 will always be undefined. Since you have a different version of the blade and don't experience this problem this could look different for you. If it does please let me know, maybe there is a way to fix it properly.

If you just want it gone, you can use this static patch:

into method label RTEC replace_content begin
\n
end;

If you want to fix the problem with having to open the lid twice after sleep and this doesn't help, I can walk you through how to debug your dsdt. For me it was because _WAK was not executed fully because it errored out in RTEC and I'm sure it's something similar for you guys.

Cheers!

So when I now use this sleep trick to get 144hz, I've noticed that dGPU is waking up after sleep immediately (fans start spinning and doesn't stop no matter what, while when it's turned off they are idle when doing nothing on cpu).
You're saying this patch helped you to beat that thing right? Keep dGPU off even after sleep. So I've couple of questions:
1) which dsdt is that you are patching?
2) please explain how to debug acpi with that tool

 

[takki]

Turned Thunderbolt back on in UEFI settings and the trick with apple-logo-sleep worked DD
Now I finally have it at 144hz, niceeeeeeeeeeee.
Still a workaround though, has to be another way.

Nice! Yeah it's a very hacky solution to the problem but at least it works haha

So when I now use this sleep trick to get 144hz, I've noticed that dGPU is waking up after sleep immediately (fans start spinning and doesn't stop no matter what, while when it's turned off they are idle when doing nothing on cpu).
You're saying this patch helped you to beat that thing right? Keep dGPU off even after sleep. So I've couple of questions:
1) which dsdt is that you are patching?
2) please explain how to debug acpi with that tool

I was just patching my main DSDT. It might be the same problem on your end but it might as well be something entirely different. You can try my way and see if it helps.

If you want to debug your DSDT you have to use RehabMan/OS-X-ACPI-Debug. Put the kext in Clover and then the easiest way is to add

http://raw.github.com/RehabMan/OS-X-ACPI-Debug/master

as a source in MaciASL (Settings -> Sources). You should now have new patches available if you click the Patch button. Apply "Add DSDT Debug Methods" to your DSDT. If you want to also debug an SSDT, you'll have to apply "Add SSDT Debug Extern Declarations" to every SSDT you want add print statements to. Don't forget to remove all that stuff when you are done!

So since your problem connected to waking up, _WAK is a good place to start. You can patch your DSDT with "Instrument _WAK/_PTS" and go from there. Just put debug statements as you go.

\RMDT.PUSH("Text to print")

prints text to the system.log, more options are available in the repository but that should do it. If _WAK executes correctly, you'll see "_WAK enter" and "_WAK leave" in the output. If there are errors you won't see the leave part.

You can see the output by using this command in terminal:

log show --predicate "processID == 0" --start $(date "+%Y-%m-%d") --debug | grep ACPIDebug

 

[Mr.Crab]

Nice! Yeah it's a very hacky solution to the problem but at least it works haha



I was just patching my main DSDT. It might be the same problem on your end but it might as well be something entirely different. You can try my way and see if it helps.

If you want to debug your DSDT you have to use RehabMan/OS-X-ACPI-Debug. Put the kext in Clover and then the easiest way is to add

http://raw.github.com/RehabMan/OS-X-ACPI-Debug/master

as a source in MaciASL (Settings -> Sources). You should now have new patches available if you click the Patch button. Apply "Add DSDT Debug Methods" to your DSDT. If you want to also debug an SSDT, you'll have to apply "Add SSDT Debug Extern Declarations" to every SSDT you want add print statements to. Don't forget to remove all that stuff when you are done!

So since your problem connected to waking up, _WAK is a good place to start. You can patch your DSDT with "Instrument _WAK/_PTS" and go from there. Just put debug statements as you go.

\RMDT.PUSH("Text to print")

prints text to the system.log, more options are available in the repository but that should do it. If _WAK executes correctly, you'll see "_WAK enter" and "_WAK leave" in the output. If there are errors you won't see the leave part.

You can see the output by using this command in terminal:

log show --predicate "processID == 0" --start $(date "+%Y-%m-%d") --debug | grep ACPIDebug

Nice, will debug all the **** out of my acpi tomorrow THX!