Contribute
Register

[Guide] Intel Framebuffer patching using WhateverGreen

Can I increase the memory up to 96MB or more?
how to do it?

If you don't want to calculate manually you can use Intel FB-Patcher. For Mojave you have to generate the framebuffer binary using WhateverGreen's -igfxdump boot flag and File->Open it in FB-Patcher.
 
Compile Lilu + WhateverGreen
Download WhateverGreen. Make sure you place the debug version of Lilu into the root of WhateverGreen before you compile. Install Lilu and WhateverGreen kext's into the usual place. Compile WhateverGreen as debug if you want to view debug output.

Would this compile the latest WhateverGreen, 1.2.1? If so, what version of debug Lilu should I use? 1.2.5? Or I need to compile the Lilu 1.2.6 first?

Thanks.
 
Would this compile the latest WhateverGreen, 1.2.1? If so, what version of debug Lilu should I use? 1.2.5? Or I need to compile the Lilu 1.2.6 first?

I do not keep up with the official releases. Personally I use my build_lilu.sh script to download and compile the latest.
 
Do you leave this entry in KextsToPatch:Disable minStolenSize less or equal fStolenMemorySize assertion, 10.14 ??

If I blocking it, wasn't started OSX
 
I have one more problem.
My Laptop has Built-in display 2736x1824
Screenshot 2018-08-01 at 20.37.01.png

but in System Preferences / Display -> default for display is only 1368x914, which is half of the native size.
Screenshot 2018-08-01 at 20.35.16.png

Is it possible to change it somehow?
 
Last edited:
which is half of the native size.

It is per Apple design.
The best result is with an "effective" resolution that is 1/2 native.

Custom resolutions can be created with a display override, selected with RDM.
 
@headkaze

I still have the issue with my external monitor not supporting 4K resolution despite the enable-hdmi20 property. Unfortunately, my laptop does not allow DVMT-prealloc settings or UEFI changes due to BIOS restrictions and I am forced to use the stolen etc. properties. I did take a look at the source code for the CoreDisplay patch, but wanted to verify it is actually being applied.
The dump below is from the syslog, but it isn't clear (to me) if the patch is being correctly applied. Does this look correct to you?
Code:
2018-08-03 09:15:48.021283-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) requesting proc_exec_switch_task patch

2018-08-03 09:15:48.021290-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) firing hook from procExecSwitchTask

2018-08-03 09:15:48.021296-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) patch for /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox in 7FFF36BDB000 7FFF36F94000

2018-08-03 09:15:48.021305-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) 1/1 found BF 69 6D 72

2018-08-03 09:15:48.021320-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) obtained write permssions

2018-08-03 09:15:48.021351-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) restored write permssions

2018-08-03 09:15:48.021356-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) done reading patches for 59F87

2018-08-03 09:15:48.021368-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) patch for /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox in 7FFF36BDB000 7FFF36F94000

2018-08-03 09:15:48.021376-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) 1/1 found BF 69 6D 72

2018-08-03 09:15:48.021381-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) obtained write permssions

2018-08-03 09:15:48.021386-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) restored write permssions

2018-08-03 09:15:48.021390-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) done reading patches for 59FDC

2018-08-03 09:15:48.021395-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) patch for /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay in 7FFF2A128000 7FFF2A210000

2018-08-03 09:15:48.021404-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) 1/1 found BB 1 0 0

2018-08-03 09:15:48.021421-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) obtained write permssions

2018-08-03 09:15:48.021460-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) restored write permssions

2018-08-03 09:15:48.021465-0400  localhost kernel[0]: (kernel) Lilu:    user @ (DBG) done reading patches for 148CC

2018-08-03 09:15:48.410251-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:48.410256-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.driver.AGDCBacklightControl

2018-08-03 09:15:48.444846-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:48.444852-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.driver.X86PlatformShim

2018-08-03 09:15:48.446797-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:48.446804-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.driver.AGPM

2018-08-03 09:15:48.448323-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:48.448329-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.driver.ApplePlatformEnabler

2018-08-03 09:15:48.677343-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:48.677347-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.kext.triggers

2018-08-03 09:15:48.678139-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:48.678142-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.filesystems.autofs

2018-08-03 09:15:49.048764-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading

2018-08-03 09:15:49.048767-0400  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) last kext is <private> and its name is com.apple.driver.AudioAUUC

2018-08-03 09:15:49.106567-0400  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) failed to obtain display mode

2018-08-03 09:15:49.106578-0400  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) failed to obtain display mode

2018-08-03 09:15:49.112426-0400  localhost kernel[0]: (kernel) WhateverGreen:    igfx @ (DBG) computeLaneCount: bpp = 30, available = 10

2018-08-03 09:15:49.169247-0400  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 1: -2147479549:0 11520:0:32

2018-08-03 09:15:49.169251-0400  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 0:2880:1620

2018-08-03 09:15:49.169254-0400  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) this display has different mode

2018-08-03 09:15:49.194552-0400  localhost kernel[0]: (kernel) WhateverGreen:    igfx @ (DBG) computeLaneCount: bpp = 30, available = 10

2018-08-03 09:15:49.312370-0400  localhost kernel[0]: (kernel) WhateverGreen:    igfx @ (DBG) computeLaneCount: bpp = 30, available = 10
 
Not works on Xiaomi Notebook Pro (7mb 620HD) but on my MSI (5600HD) works perfectly although with Lag when starting the system
Hi, it works in my latest commit. Thank you for your guide.
 
Unfortunately, my laptop does not allow DVMT-prealloc settings or UEFI changes due to BIOS restrictions and I am forced to use the stolen etc. properties.

Please take a look here and here. The first guide shows how to get the Setup IFR extracted for your BIOS and then the latter shows how to use Clover's UEFI Shell with GRUB to set a value via setup_var. Make sure you use the correct BIOS binary that matches the one currently flashed on your machine and be careful!
 
Please take a look here and here. The first guide shows how to get the Setup IFR extracted for your BIOS and then the latter shows how to use Clover's UEFI Shell with GRUB to set a value via setup_var. Make sure you use the correct BIOS binary that matches the one currently flashed on your machine and be careful!

I've been down that path, and get an (0000008) error when using setup_var. I've seen other reports of error (00001a), but assume that this means the BIOS is preventing any UEFI updates. I couldn't find any reference to setup_var result codes that would help troubleshoot further.
 
Back
Top