[BUG] Black screen 3 minutes after booting, CoffeeLake UHD 630

[Amandeep]

The only difference is that the lowest brightness level on his machine is "black screen".

You are right. My lowest brightness is black screen. When the screen lights up and I use backlight buttons or the brightness bar to lower the brightness it comes to black screen at lowest brightness. This means that the Framebuffer resets the value to the lowest possible and then forces it to remain there or maybe it wants to come back on but can't.

 

[RehabMan]

Relevant news:

https://www.tonymacx86.com/threads/...a-10-13-6-success.256954/page-21#post-1825634

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.

 

[headkaze]

Relevant news:

Wow a month old patch. I just tried it with the latest WEG and it actually works!

Couple of issues though. Brightness slider is now borked. Also the patch is complicated and likely to break in future updates. So I think it can be simplified and then merged with official WEG. I'll keep you all posted and many thanks to @Fraxul for a working solution.

 

[Fraxul]

Wow a month old patch. I just tried it with the latest WEG and it actually works!

Couple of issues though. Brightness slider is now borked. Also the patch is complicated and likely to break in future updates. So I think it can be simplified and then merged with official WEG. I'll keep you all posted and many thanks to @Fraxul for a working solution.

Yeah, the patch definitely isn't optimal from a maintenance perspective -- the instruction sequences could easily change in a future release.

The much simpler way to patch this that I tried first was just to hook AppleIntelFramebufferController::WriteRegister32, have it ignore the BXT_BLC_PWM_FREQ1 writes, and rescale the BXT_BLC_PWM_DUTY1 writes to match the system BXT_BLC_PWM_FREQ1 value. That approach worked, but it caused weird issues when later kexts would load and use Lilu to patch other stuff. Combining AppleALC and the WriteRegister32 patch in particular was a 100% reproducible kernel panic. Maybe caused by Lilu writing to its trampoline region while another thread is executing code out of there? Not sure, but I decided to look for a different strategy after debugging that for a while.

This approach is way more stable -- I've been running it for a month with no problems.

 

[headkaze]

Yeah, the patch definitely isn't optimal from a maintenance perspective -- the instruction sequences could easily change in a future release.

My mistake your patch does work with brightness slider. Like you suggested I patched my ACPI using the "Brightness Fix (ACPI 100)" patch (I also had to rename DD02 to DD1F).

So I contacted vit about this patch and he asked me to see if I could make it a bit safer. So I spent some time going over it and making some changes. So I've managed to make a patch that doesn't require the 4 find/replace patches. Do you mind testing it for me?

My commit is:
https://github.com/headkaze/WhateverGreen/commit/3a3f1d8010e34e175e6efd8d9cc6b3bc0b1c1fa4

You need to add a -cflbkltfix boot flag for it to patch (as this will be needed for an official release). no longer necessary.

 

[Fraxul]

My mistake your patch does work with brightness slider. Like you suggested I patched my ACPI using the "Brightness Fix (ACPI 100)" patch (I also had to rename DD02 to DD1F).

So I contacted vit about this patch and he asked me to see if I could make it a bit safer. So I spent some time going over it and making some changes. So I've managed to make a patch that doesn't require the 4 find/replace patches. Do you mind testing it for me?

My commit is:
https://github.com/headkaze/WhateverGreen/commit/3a3f1d8010e34e175e6efd8d9cc6b3bc0b1c1fa4

You need to add a -cflbkltfix boot flag for it to patch (as this will be needed for an official release).

I can't test it right now, but it does look safer -- no instruction patches, and you don't route any high-call-frequency functions. My only concern would be whether you'd get any backlight flicker from allowing the original hwSetBacklight to write an incorrect value to the register (truncated due to multiplication overflow) before you write the correct value in the override function.

You should definitely also include comments about what the patch is doing and why it's necessary. My patch was like 50% comments for a reason, and it's not because finding this bug was quick and easy...

 

[Austere.J]

My commit is:
https://github.com/headkaze/WhateverGreen/commit/3a3f1d8010e34e175e6efd8d9cc6b3bc0b1c1fa4

You need to add a -cflbkltfix boot flag for it to patch (as this will be needed for an official release).

So we don't need to patch LightUpEDP now?

 

[headkaze]

I can't test it right now, but it does look safer -- no instruction patches, and you don't route any high-call-frequency functions. My only concern would be whether you'd get any backlight flicker from allowing the original hwSetBacklight to write an incorrect value to the register (truncated due to multiplication overflow) before you write the correct value in the override function.

You should definitely also include comments about what the patch is doing and why it's necessary. My patch was like 50% comments for a reason, and it's not because finding this bug was quick and easy...

Yes it does flicker a bit. Actually I think I can improve that with hwSetBacklight at least by not calling the original function.

I will be adding comments and any changes necessary before the merge with master.

Also can you think of a way we can do without this:

uint32_t *p_fbc_pwm_freq = reinterpret_cast<uint32_t*>(reinterpret_cast<uint8_t*>(that) + 0x2b44);

Would be nice to not have to read that offset directly.

 

[headkaze]

So we don't need to patch LightUpEDP now?

I'm not sure. I need help testing it some more.

 

[Fraxul]

Yes it does flicker a bit. Actually I think I can improve that with hwSetBacklight at least by not calling the original function.

I will be adding comments and any changes necessary before the merge with master.

Also can you think of a way we can do without this:

uint32_t *p_fbc_pwm_freq = reinterpret_cast<uint32_t*>(reinterpret_cast<uint8_t*>(that) + 0x2b44);

Would be nice to not have to read that offset directly.

Unfortunately not -- there's no accessor for that field.