[help]black screen when uhd630 run with internal screen

[RehabMan]

Compiled and used 1.2.4 WEG, still the 3 Minutes black screen isn't fixed for me.
Seems like it only fixes it on razer blades.

You should attach PR files for verification.

 

[neocoma504]

We haven't released WEG with the fix yet but you can compile it yourself from here.

I've also written a little guide on how I got the brightness slider working with this here.

Hi @headkaze

I made some works this week-end and i have to thank you and @Fraxul a lot for having this patch working! Right now, everything seems good to me. Thanks also to @RehabMan for his help on this long story.

To be more precise about the steps done:
-First i didn't understand the patch was only active in your own fork of Whatevergreen for now. So i updated Lilu and Whatevergreen from usual github, without luck obviously.
-I then patched DSDT.aml with "Brightness Fix (ACPI 100)", replaced DD02 by DD1F and realised i had to add external opcodes to avoid compile errors (But i didn't had your step by step message at this moment). No change of course.
-I finally realised that you had the patch in your own whatevergeen fork. Compiled and got it working right after (no more black screen and brightness slider). But min-max values of the slider were not very large.
-As @RehabMan was suggesting it could work with SSDT-PNLF, i decided to give it a try. So put back my DSDT.aml (without "Brightness Fix (ACPI 100)" patch), SSDT-PNLF.aml, and AppleBacklightInjector.kext (in L-E because i previously had it working better here although all my other kexts are in Clover). And it still works (no Black screen, brightness slider)! And min-max value of the slider are way larger (i am able to dim way more than previously).
-I saw your message from today with the step by step about DSDT patching, and i understand you have an additional line in the patch regarding the full values for brightness (i don't remember this line when i patched mine). So i guess this way you are getting full brightness values too. But then this means both methods would work for me (DSDT patching or SSDT-PNLF). What do you think would be better?

Attached is a dump of my PR files and kexts used, if you want to have a look.

 

[RehabMan]

-As @RehabMan was suggesting it could work with SSDT-PNLF, i decided to give it a try. So put back my DSDT.aml (without "Brightness Fix (ACPI 100)" patch), SSDT-PNLF.aml, and AppleBacklightInjector.kext (in L-E because i previously had it working better here although all my other kexts are in Clover). And it still works (no Black screen, brightness slider)! And min-max value of the slider are way larger (i am able to dim way more than previously).

This is good news... it means that likely the only "feature" of SSDT-PNLF.aml that is not right yet, is the feature where it adjusts the backlight level to match the new LMAX... If your system booted with half brightness, like some BIOS can have such a setting, that after the adjustment to the new LMAX (0xffff), the brightness would still stay at half (instead of something less, as no doubt the new LMAX of 0xffff is larger than the previous max set by BIOS).

But a note about your files... AppleBacklightInjector and the associated KextsToPatch entry for AppleBacklight are now deprecated/replaced by AppleBacklightFixup.kext.

 

[headkaze]

Also i tried again to use AptioMemoryFix (on my High Sierra install). And i realised that it seems to work in some way, as my brightness value, audio level, etc... are kept upon reboot. The only problem i have is that the laptop can't shutdown correctly.

My laptop is back in action so I spoke to vit about this as I think that the shutdown issue was potentially what caused my ssd to overheat and die. So I wanted to fix this before doing any more testing on the black screen issue.

So vit explained to me why AptioMemoryFix is causing the shutdown issue and it's quite a complicated problem. But I have a solution and some other things to try if you're interested.

The first thing is AptioMemoryFix works with EmuVariableUEFI so remove OsxAptioFixDrv1 and use AptioMemoryFix + EmuVariableUEFI instead.

If you get the following error message when rebooting:

Error allocating 0x1165e pages at 0x000000000fce4000 alloc type 2
Couldn't allocate runtime area
Error loading kernel cache (0x9)

You may need to add the slide=0 boot arg.

vit also suggested some things to try with AptioMemoryFix that would mean we can do without EmuVariableUEFI. These things require a custom compiled version of AptioMemoryFix. If you're interested in helping me test (and anyone else with this issue) I can compile a series of files so we can share the results and hopefully come up with a workable solution.

 

[RehabMan]

vit also suggested some things to try with AptioMemoryFix that would mean we can do without EmuVariableUEFI. These things require a custom compiled version of AptioMemoryFix. If you're interested in helping me test (and anyone else with this issue) I can compile a series of files so we can share the results and hopefully come up with a workable solution.

Can you link to this discussion? Thanks.

 

[parasthakur37]

My laptop is back in action so I spoke to vit about this as I think that the shutdown issue was potentially what caused my ssd to overheat and die. So I wanted to fix this before doing any more testing on the black screen issue.

So vit explained to me why AptioMemoryFix is causing the shutdown issue and it's quite a complicated problem. But I have a solution and some other things to try if you're interested.

The first thing is AptioMemoryFix works with EmuVariableUEFI so remove OsxAptioFixDrv1 and use AptioMemoryFix + EmuVariableUEFI instead.

If you get the following error message when rebooting:

Error allocating 0x1165e pages at 0x000000000fce4000 alloc type 2
Couldn't allocate runtime area
Error loading kernel cache (0x9)

You may need to add the slide=0 boot arg.

vit also suggested some things to try with AptioMemoryFix that would mean we can do without EmuVariableUEFI. These things require a custom compiled version of AptioMemoryFix. If you're interested in helping me test (and anyone else with this issue) I can compile a series of files so we can share the results and hopefully come up with a workable solution.

Okay, so I probably didn't have the shutdown issue but when I really got mojave to work with UHD630, the only thing left was functional sleep/wake.
So after a lot of testing various variables, the thing that fixed sleep for me was using EmuVariableUEFI, before, I was only using AptioMemoryFix. But then when I used EmuVariableUEFI with AptioMemoryFix, it fixed sleep for me.

So two days ago I deleted AptioMemoryFix and only used EmuVariableUEFI, to my surprise, the system did boot up. So yes EmuVariableUEFI did work on its own, for me(this was without WhateverGreen.kext and wrap/freq).

Here's where I reported the whole incident with EmuVariableUEFI-64.

 

[headkaze]

Can you link to this discussion? Thanks.

There is a link to insanely mac but I don't think I can post it here. But how vit explained it to me is the following:

boot.efi implements KASLR (see wiki) support for macOS kernel. To do so on real macs it performs physical memory defragmentation, and moves all the physical UEFI Runtime Services data to the beginning of the physical RAM address space.

Afterwards it knows that certain physical addresses are free to use, and allocates the kernel and kexts at a random offset (which can be specified via slide, 0~255) multiplied by KASLR granularity.

On APTIO we cannot let boot.efi defragment the UEFI Runtime Services, as it breaks NVRAM and results in SMM code overwriting & corrupting kernel memory (great stuff) on every attempt to read or write an NVRAM variable.

So we have to write hacks to avoid relocating Runtime Services pages and speculate on which KASLR offsets can be used by macOS.

APTIFIX_MAX_RT_RELOC_NUM is an array of how many Runtime Services relocations we can prevent from happening: if some are missed, then boot.efi relocates them and we get SMM code corrupting our memory again. Normally 64 was enough, but I wondered whether your APTIO needs more.

APTIOFIX_SPECULATED_KERNEL_SIZE is pretty much that. We speculate that the kernel is N megabytes large, and test whether the address area is available for the use.

If not all offsets are valid, we pick a random offset among the valid ones, and pass it to boot.efi implicitly.

Unfortunately I tried re-compiling AptioMemoryFix with APTIFIX_MAX_RT_RELOC_NUM set to 256 and my laptop would still not shutdown. So it doesn't appear to fix the issue.

I have not had the chance to try setting APTIOFIX_SPECULATED_KERNEL_SIZE to a higher value yet but apparently that would potentially only fix the boot issue and not the shutdown issue AFAIK.

 

[Quipper]

Hello, i have an similar problem with my coffee lake laptop. Actually i use AptioMemoryFix with EmuVariableUEFI. Restart, shutdown and sleep are working for me. My problem is that sometimes my laptop wont boot. It hangs in different stages of boot. Rare but also present after clover is starting mojave a kernel panic appears. Also after a successful boot my audio is not working sometimes. All relevant kext and patches are loaded and in working state but no sound from speaker. I have to reboot a few times to get working. slide=0 is set too. I would like to help test.

 

[neocoma504]

My laptop is back in action so I spoke to vit about this as I think that the shutdown issue was potentially what caused my ssd to overheat and die. So I wanted to fix this before doing any more testing on the black screen issue.

So vit explained to me why AptioMemoryFix is causing the shutdown issue and it's quite a complicated problem. But I have a solution and some other things to try if you're interested.

The first thing is AptioMemoryFix works with EmuVariableUEFI so remove OsxAptioFixDrv1 and use AptioMemoryFix + EmuVariableUEFI instead.

Hi @headkaze !

Sorry again for the late reply. Very busy and this laptop is my main work machine so i cannot take any risk in the middle of a project..

Anyway since my post #232 (see debug files if needed), the laptop was running great under macOS meaning
-No Shutdown/Reboot issue with OsxAptioFixDrv1 + EmuVariableUEFI
-Full Backlight control (i was still using AppleBacklightInjector.kext in L/E + linked KextToPatch in Clover)
-Full UHD630 acceleration
-External screen working thru TB3
-Never 3 mins Black Screen at boot (which seems strange as it seems that other people still have the issue right?)
-I was on Mojave 10.14.0 (18A389) previously updated from Mojave Beta.

But i was still using some old stuffs and i wanted to update a little so here are my trials made today :

-Updated Clover from r4700 to r4741 (in order to update to Mojave 10.14.1). Seems good

-Updated to Mojave 10.14.1 First issue unsolved, I got back an issue i've had previously. When i use an external screen with Thunderbolt 3 the internal screen stays black with quick line glitches appearing sometimes. I can see the backlight is on so it's not the known 3 min issue. And it's something i sometimes had under high sierra and Mojave betas. But i didn't have it at all under 10.14.0 and i have this issue always with 10.14.1! So basically impossible to use internal screen when TB3 screen is plugged.
I tried to update Whatevergreen + Lilu, tried different WEG boot arguments (-wegnoegpu -igfxnohdmi) without more success. As i really need this station working, i ultimately went back to my Mojave 10.14.0 backup. No idea on this issue. Anybody as this same kind of thing?

-I tried again AptioMemoryFix as you mentioned by keeping EmuVariableUEFI and adding slide=0 boot arg. It works indeed! Thanks for the info! It seems a bit faster at boot and shutdown than with OsxAptioFixDrv1. Values like Backlight or sound level are kept well upon reboot. Only Sleep issue is that if i have the external screen connected, the laptop goes fine to sleep. But when it wakes up, the internal screen stays black. I also had this behavior with OsxAptioFixDrv1 so it is certainly not linked but i was hoping to solve it this way...

-As suggested by @RehabMan, i replaced old AppleBacklightInjector.kext + corresponding KextToPatch by newer AppleBacklightFixup.kext. No issue, the backlight is working fine, with full values and brightness slider. Thanks also!

-Then i tried to update Whatevergreen + Lilu + AppleALC to last release version. Unfortunately this brings back the 3 min black screen at boot for me. I still don't understand why i don't have this issue with the version i use of Whatevergreen (you can found it in my debug files). So i return to this version for now. I don't know if i can help some way to find the reason it works with my laptop without 3 mins black screen (or did you find a solution in your WEG fork trials?).

So basically things are working fine for me now but i can't update to 10.14.1 nor to latest Lilu+WEG without having issues... Not very future proof..

 

[headkaze]

When i use an external screen with Thunderbolt 3 the internal screen stays black with quick line glitches appearing sometimes. I can see the backlight is on so it's not the known 3 min issue.

Yes I have this issue also. The way I work around it is to boot without the external screen attached and then once booted attach it and you can still use the internal screen as normal.

Unfortunately this brings back the 3 min black screen at boot for me. I still don't understand why i don't have this issue with the version i use of Whatevergreen (you can found it in my debug files). So i return to this version for now. I don't know if i can help some way to find the reason it works with my laptop without 3 mins black screen (or did you find a solution in your WEG fork trials?).

Yes there is a solution but you have to use my custom version of WEG (with the igfxcflbklt=wrap boot flag) for now. My boot SSD died but I have it back now so I'm going to do more testing and hopefully come up with something for an official release.