Contribute
Register

Razer Blade 15 - High Sierra 10.13.6 - Success(-)

Status
Not open for further replies.
I think you understand what I meant. It was a general statement, mostly geared towards patching the DSDT and the one single SSDT that we've been referencing the past few reply's to try and fix the 3 minute black screen bug.

I don't think you have any reason to patch any SSDTs, except for disabling a secondary GPU (if you have one).

Your profile has no laptop hardware details. Please fix as per FAQ:
https://www.tonymacx86.com/threads/faq-read-first-laptop-frequent-questions.164990/
 
Well, that's certainly unexpected. Neither the WEG or SSDT patches touch anything related to the trackpad or sleep/wake.

If you have no brightness control, either something went wrong when you applied the SSDT patch, or maybe you have another SSDT that's adding more stuff into \_SB_.PCI0.GFX0 and overwriting it.

The BXT_BLC_PWM_FREQ1 register on your machine is set the same as on mine, and the patch is loaded, so at least that's working as expected.

I would probably re-dump a fresh copy of the SSDT and reapply your patches. I had a lot of trouble when bringing up this machine with stale DSDT and SSDTs causing weird hardware issues. Any BIOS config or hardware changes cause the OperationRegion values in the DSDT and some of the SSDTs to shift around -- if you're using one with old values, random things will stop working.


So I dumped a fresh copy of my DSDT and SSDT's re-patched my DSDT and my trackpad works again! So good news there. I tried your patch again with a fresh SSDT-2-SaSsdt and it still doesn't work. It no longer randomly goes to sleep every 60 seconds, but I have no brightness control and I made sure that there were no other SSDT's overriding that one. Also what's weird is, if I copy and paste the patch code that you posted a few posts back I get a long list of errors when trying to compile, but if I copy and paste the code from the dsl file you posted, the patch works, it's odd.

We seem to have 2 different ways of making brightness control work, mine is using the generic PNLF SSDT, you're using your own SSDT-2-SaSsdt. But I'm really curious as to why I can't get mine to work the way you have yours set up. If I try to use your patched Whatevergreen.kext with the PNLF SSDT I use, it either Kernel Panics on boot or boots to full black screen and brightness never turns on.
 
I've also been working on a Razer Blade 15 (2018), and I found a workaround for the backlight going dark at boot. I wrote a patch for WhateverGreen to fix it. You can try it out here: https://github.com/Fraxul/WhateverGreen/releases/tag/1.2.1-a9d24be3

There's more information about how the patch works in the commit: https://github.com/Fraxul/WhateverGreen/commit/a9d24be3e478e18337d2c19a6d5dfe7b29bd88b0

This will only work / do anything if you're on 10.13.6-17G2208 and are using the native Coffee Lake framebuffer (tested with platform-id 3e9b0000).

I haven't upgraded this machine to Mojave yet -- still waiting on the release of Mojave-compatible Nvidia web drivers -- so I'm unable to test/update for later versions.

Do you have the Nvidia card working with 17G2208? If you do, I'd like to know how you made that happen. I can't get it work at all with 17G2208, even with a patched version of the Nvidia Web Drivers. I usually have it disabled, but even if I remove the patch to disable the card, the laptop doesn't see the Nvidia card and it never works. This isn't a big deal/priority for me as I rarely ever use the HDMI out, but it would be nice to know that it's working.
 
SSDT Patch is for disabling my secondary GPU (Nvidia)

Would not be with SaSsdt.

and also testing out Fraxul's way of making brightness control work, since his method to do so is by patching the SSDT-2-SaSsdt.

SSDT-PNLF...
 
Would not be with SaSsdt.



SSDT-PNLF...


We've been talking about SaSsdt for the past 2 pages of posts. I know that it's not used for disabling the secondary GPU, that's what 10-OptTabl is for.

As far as SaSsdt goes, I'm trying to understand Fraxul's way, since he was able to get brightness control working using SaSsdt and a patched version of Whatevergreen that also fixes the 3 minute black screen bug on first boot. Right now I'm using SSDT-PNLF for brightness control and it works beautifully and I thank you for the guide to make that happen. But Fraxul offered a way to fix the 3 minute black screen on first boot, so I had to give it a shot to see what happens with it, it didn't work, so now I'm trying to understand how he made this work, since using SaSsdt seems to be out of the norm.
 
so now I'm trying to understand how he made this work, since using SaSsdt seems to be out of the norm.

Probably the reason for it working has nothing to do with the specific patching in SaSsdt.
 
@vettz500 Hey! I have working the bluetooth and the wifi too!
I have just realised that every time pop up the window of user and password (to installing software) it takes few seconds to let me write on the fields of text, the rotation sphere takes appears for a second or two at least, and when I turn on the computer the same, in the login takes a bit until it allows me to write. Do you have this little problem?

As well, there is anyway to turn off the light of the keyboard in osx?

Everything is working super good an stable, fall in love.

Thanks


I know you posted this a while ago but I didn't have this issue until I upgraded to the 17G2208 build of High Sierra. I tracked it down to the Biometrics support in OSX. It's looking for the Biometrics hardware (Fingerprint scanner and what not) that doesn't exist and keeps trying to do so for a few times before it gives up, which is why you get the system lag/beach ball when going to enter in a password.

My guess is everyone running this build will have this laggy password entering issue, so here's the fix that I figured out for it.

Since we don't have any kind of biometrics hardware support on this laptop, the simple fix is to navigate to System-Library-Frameworks and delete the following framework extensions:
BiometricKit.framework
BiometricKitUI.framework
BiometricSupport.framework

I made a backup of them, just incase, but I can't ever see a point where they will be needed. But after you delete them, reboot and you won't have the lagging issue when entering in your password anymore.
 
I know you posted this a while ago but I didn't have this issue until I upgraded to the 17G2208 build of High Sierra. I tracked it down to the Biometrics support in OSX. It's looking for the Biometrics hardware (Fingerprint scanner and what not) that doesn't exist and keeps trying to do so for a few times before it gives up, which is why you get the system lag/beach ball when going to enter in a password.

My guess is everyone running this build will have this laggy password entering issue, so here's the fix that I figured out for it.

Since we don't have any kind of biometrics hardware support on this laptop, the simple fix is to navigate to System-Library-Frameworks and delete the following framework extensions:
BiometricKit.framework
BiometricKitUI.framework
BiometricSupport.framework

I made a backup of them, just incase, but I can't ever see a point where they will be needed. But after you delete them, reboot and you won't have the lagging issue when entering in your password anymore.

Maybe choosing a different SMBIOS is an easier fix.
 
Maybe choosing a different SMBIOS is an easier fix.

True, but I like that the laptop identifies as a 2018 MacBook Pro. I know it's not that big of a deal and that it's stupid/little, but it's preference. Either way works :)
 
Status
Not open for further replies.
Back
Top