WhatEverGreen Support Topic

[deeveedee]

@SavageAUS You are very welcome.

[kocoman]

to fix the iosurface compression hang on skylake using kbl or skl is nop this 

ok call       __ZN18IGTelemetryManager16prepareTelemetryEj ; IGTelemetryManager::prepareTelemetry(unsigned int)

trigger the hang 10.15.0 ok but 10.15.1 hangs. could use 10.15 kext or nop the above.. but no idea how to inject the patch in newer osx

 

does anyone know how to make patch or extract dyld cache back to kext to apply for big sur and up? thx

[joevt]

On 11/21/2022 at 11:00 PM, kocoman said:

to fix the iosurface compression hang on skylake using kbl or skl is nop this 

ok call       __ZN18IGTelemetryManager16prepareTelemetryEj ; IGTelemetryManager::prepareTelemetry(unsigned int)

trigger the hang 10.15.0 ok but 10.15.1 hangs. could use 10.15 kext or nop the above.. but no idea how to inject the patch in newer osx

 

does anyone know how to make patch or extract dyld cache back to kext to apply for big sur and up? thx

I think kext patches work the same as usual.

 

For user space patches, you can check my fork of Lilu/WhateverGreen. The dpd (displaypolicyd) and cdf (CoreDisplay.framework) patches have user-space patches that I've updated for Big Sur, Monterey, Ventura. CoreDisplay.framework is inside the dyld cache.

 

If you use my fork of WhateverGreen, then you need to use my fork of Lilu and recompile all other Lilu-based kexts that you use.

 

Another option is to make your own user patching code like what other Lilu-based kexts do. Other Lilu-based kexts each have their own code for user space patches for recent macOS versions. RestrictEvents.kext is one such example. Check the list of kexts that OCLP installs for possible other examples.

 

They all work by patching _cs_validate_page or _cs_validate_range depending on the macOS version.

 

One strange thing that might happen with user patches is that other processes may read the file that is being patched and the read result will also contain the patch. For example, a Finder copy of the patched file might result in the copy having the patch even though a patch should only exist in memory. Basically, the _cs_validate_page or _cs_validate_range overrides need to check the current process to make sure the patch is only applied for the intended process. In the case of CoreDisplay.framework, we want the patch to only be applied for the WindowServer process.

 

[kocoman]

13 minutes ago, joevt said:

I think kext patches work the same as usual.

 

For user space patches, you can check my fork of Lilu/WhateverGreen. The dpd (displaypolicyd) and cdf (CoreDisplay.framework) patches have user-space patches that I've updated for Big Sur, Monterey, Ventura. CoreDisplay.framework is inside the dyld cache.

 

If you use my fork of WhateverGreen, then you need to use my fork of Lilu and recompile all other Lilu-based kexts that you use.

 

Another option is to make your own user patching code like what other Lilu-based kexts do. Other Lilu-based kexts each have their own code for user space patches for recent macOS versions. RestrictEvents.kext is one such example. Check the list of kexts that OCLP installs for possible other examples.

 

They all work by patching _cs_validate_page or _cs_validate_range depending on the macOS version.

 

One strange thing that might happen with user patches is that other processes may read the file that is being patched and the read result will also contain the patch. For example, a Finder copy of the patched file might result in the copy having the patch even though a patch should only exist in memory. Basically, the _cs_validate_page or _cs_validate_range overrides need to check the current process to make sure the patch is only applied for the intended process. In the case of CoreDisplay.framework, we want the patch to only be applied for the WindowServer process.

 

I am still trying to extract the appleintelkblgraphics.kext using ?  dyld_shared_cache_util-dyld-733.8.zip

 

then I can find what bytes to patch? the problem is with catlina, even if I patch with int3/nop, for some reason the optimization is making the code wrong and the next code is not seen as nop instead some wierd code that crashes..

I have to use register write pc `$pc+5` in lldb once I reach the int3.. anyway I think it will take longer to put something up.. the acid001 people is very hard to let me put this patch into their branch as a flag..

 

I wanted to share the rtl8111 patched with iokdp but I doubt the acid001 will intergrate it because my code works but messy but u have to be on a LAN only (no WAN), else the debugger disconnects I think because of some 255.255.255.255 broadcast that mess up the udp timing etc

 

anyway I will post something here if I make some progress, now looking for rootless.h..

 

 

while patching the kernel to force enable iokdp with rtl8111 it nops fine.. not sure why the graphics driver does not 

 

even for the hd4000 panic assert i could patch but I found a easier way to use vbios instead.. now with skylake I can't do that.. but I haven't follow the kernel collections stuff .. was working on tianocore/coreboot

Edited November 23, 2022 by kocoman

[joevt]

Kexts don't contain code in Ventura. I think you can get the code by looking at the kext from the KDK?

 https://developer.apple.com/download/all/?q=kernel debug kit

 

[Slice]

19 hours ago, joevt said:

 

 

For user space patches, you can check my fork of Lilu/WhateverGreen. The dpd (displaypolicyd) and cdf (CoreDisplay.framework) patches have user-space patches that I've updated for Big Sur, Monterey, Ventura. CoreDisplay.framework is inside the dyld cache.

 

If you use my fork of WhateverGreen, then you need to use my fork of Lilu and recompile all other Lilu-based kexts that you use.

 

Where can I get your version of Lilu and WhateverGreen? I can't compile it from sources in Mojave because undefined names. Probably they defined in Ventura.

Can you upload your Release?

Is it true that your Lilu is for Ventura only?

[joevt]

10 hours ago, Slice said:

Where can I get your version of Lilu and WhateverGreen? I can't compile it from sources in Mojave because undefined names. Probably they defined in Ventura.

Can you upload your Release?

Is it true that your Lilu is for Ventura only?

On GitHub: joevt/Lilu, joevt/WhateverGreen, joevt/MacKernelSDK.

Get all three projects.

symlink MacKernelSDK into Lilu.

Build Lilu.

symlink Lilu.kext into WhateverGreen (and any other Lilu-based kexts you want to build).

Build WhateverGreen.

 https://forums.macrumors.com/threads/intel-graphics-and-5120x1440-testing-in-big-sur.2244174/post-31389965

 

My Lilu/WhateverGreen should work with every version of macOS (or at least every version of macOS that the upstream should work with) but I haven't tested every version.

 

My Forks are slightly behind the upstream so maybe you might want to merge the upstream.

 

I build using Xcode.app on Monterey. Since they use MacKernelSDK, it should build on other recent macOS versions?

 

[Slice]

3 hours ago, joevt said:

On GitHub: joevt/Lilu, joevt/WhateverGreen, joevt/MacKernelSDK.

Get all three projects.

symlink MacKernelSDK into Lilu.

Build Lilu.

symlink Lilu.kext into WhateverGreen (and any other Lilu-based kexts you want to build).

Build WhateverGreen.

 https://forums.macrumors.com/threads/intel-graphics-and-5120x1440-testing-in-big-sur.2244174/post-31389965

 

My Lilu/WhateverGreen should work with every version of macOS (or at least every version of macOS that the upstream should work with) but I haven't tested every version.

 

My Forks are slightly behind the upstream so maybe you might want to merge the upstream.

 

I build using Xcode.app on Monterey. Since they use MacKernelSDK, it should build on other recent macOS versions?

 

 

[joevt]

It builds for me in Mojave 10.14.6 (18G9323). Xcode Version 11.3 (11C29).

 

You should check the symlinks to make sure they are pointing correctly at their targets.

 

In the Lilu folder, right click MacKernelSDK and select "Show Original". It should select the joevt-MacKernelSDK folder that you cloned.

 

If you need to redo a symlink, then first delete it from the directory before executing the ln command.

 

In the project settings, Library Search Paths (double click it or select and press enter) under the Lilu target level should contain these three paths:

$(inherited)
$(PROJECT_DIR)/$(PROJECT_NAME)$(LOCAL_LIBRARY_DIR)
$(PROJECT_DIR)/MacKernelSDK/Library/universal
 

And there should also be KERNEL_EXTENSION_HEADER_SEARCH_PATHS (Debug, Release, Sanitize) under the Lilu project level:

$(PROJECT_DIR)/MacKernelSDK/Headers

 

And KERNEL_FRAMEWORK_HEADERS (Debug, Release, Sanitize) under the Lilu project level:

$(PROJECT_DIR)/MacKernelSDK/Headers

 

[Slice]

1 hour ago, joevt said:

It builds for me in Mojave 10.14.6 (18G9323). Xcode Version 11.3 (11C29).

 

You should check the symlinks to make sure they are pointing correctly at their targets.

 

In the Lilu folder, right click MacKernelSDK and select "Show Original". It should select the joevt-MacKernelSDK folder that you cloned.

 

If you need to redo a symlink, then first delete it from the directory before executing the ln command.

 

In the project settings, Library Search Paths (double click it or select and press enter) under the Lilu target level should contain these three paths:

$(inherited)
$(PROJECT_DIR)/$(PROJECT_NAME)$(LOCAL_LIBRARY_DIR)
$(PROJECT_DIR)/MacKernelSDK/Library/universal
 

And there should also be KERNEL_EXTENSION_HEADER_SEARCH_PATHS (Debug, Release, Sanitize) under the Lilu project level:

$(PROJECT_DIR)/MacKernelSDK/Headers

 

And KERNEL_FRAMEWORK_HEADERS (Debug, Release, Sanitize) under the Lilu project level:

$(PROJECT_DIR)/MacKernelSDK/Headers

 

Thanks for the details. I will check at evening and inform you about success.

You say "ln" command not "ln -s"?

 

PS. The Xcode for Ventura is useless. It can't compile kexts. I think it is only for iPhone now.

[joevt]

36 minutes ago, Slice said:

Thanks for the details. I will check at evening and inform you about success.

You say "ln" command not "ln -s"?

 

PS. The Xcode for Ventura is useless. It can't compile kexts. I think it is only for iPhone now.

I meant "ln -s" since we are creating symbolic links to directories. Symbolic links can also be used to link to files or directories on another volume.

 

Hard links only work for files and only on the same volume.

 

I'm installing Xcode in Ventura to see if it works (version 14.1).

Edited November 25, 2022 by joevt

[Slice]

Yes, there was wrong link. I corrected it and now I have other fatal error

[Slice]

While original Lilu build succeeded. Version 1.6.3.

[Slice]

1 hour ago, Slice said:

Yes, there was wrong link. I corrected it and now I have other fatal error

This is because of commit ea2c8842e7dcebdb624cc0062df49c4531b75c14

[Slice]

On 11/24/2022 at 6:43 PM, joevt said:

 

symlink MacKernelSDK into Lilu.

Build Lilu.

symlink Lilu.kext into WhateverGreen (and any other Lilu-based kexts you want to build).

Build WhateverGreen.

 

Then I have new error

Where it is proposed to be?

[Slice]

1 hour ago, Slice said:

Then I have new error

Where it is proposed to be?

OK, it is in MacKernelSDK.

Now I have successful compilation both kexts.

To compile the Lilu I had to revert those commit.

[joevt]

Thanks for checking. I fixed it by adding a commit to https://github.com/joevt/MacKernelSDK

 

I was able to build successfully in Ventura with Xcode 14.1

 

These are a minimum set of steps (you can change ~/Programming/KextProjects to wherever you like) :

#======================================
# Check this setting in Xcode
# Xcode -> Settings -> Locations -> Derived Data -> Relative ; DerivedData
# otherwise you need to fix the Lilu.kext symbolic link to point to the build location of Lilu.kext.

#======================================
# Get MacKernelSDK project

mkdir -p ~/Programming/KextProjects/MacKernelSDK
cd ~/Programming/KextProjects/MacKernelSDK
git clone https://github.com/joevt/MacKernelSDK joevt-MacKernelSDK
cd ~/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK

#======================================
# Get and build Lilu project

mkdir -p ~/Programming/KextProjects/Lilu
cd ~/Programming/KextProjects/Lilu
git clone https://github.com/joevt/Lilu.git joevt-Lilu
cd ~/Programming/KextProjects/Lilu/joevt-Lilu
[[ -d MacKernelSDK ]] && rm MacKernelSDK
ln -s ~/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK MacKernelSDK
open -a "Xcode.app" Lilu.xcodeproj
# Build Lilu in Xcode

#======================================
# Get and build WhateverGreen project

mkdir -p ~/Programming/KextProjects/WhateverGreen
cd ~/Programming/KextProjects/WhateverGreen
git clone https://github.com/joevt/WhateverGreen.git joevt-WhateverGreen
cd ~/Programming/KextProjects/WhateverGreen/joevt-WhateverGreen
[[ -d Lilu.kext ]] && rm Lilu.kext
ln -s ~/Programming/KextProjects/Lilu/joevt-Lilu/DerivedData/Lilu/Build/Products/Debug/Lilu.kext Lilu.kext
[[ -d MacKernelSDK ]] && rm MacKernelSDK
ln -s ~/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK MacKernelSDK
open -a "Xcode.app" WhateverGreen.xcodeproj
# Build WhateverGreen in Xcode

#======================================
# Repeat WhateverGreen steps for any other Lilu-based kexts that you want to use with Clover or OpenCore.

#======================================

 

[Slice]

On 11/26/2022 at 10:18 AM, joevt said:

Thanks for checking. I fixed it by adding a commit to https://github.com/joevt/MacKernelSDK

 

I was able to build successfully in Ventura with Xcode 14.1

 

These are a minimum set of steps (you can change ~/Programming/KextProjects to wherever you like) :

#======================================
# Check this setting in Xcode
# Xcode -> Settings -> Locations -> Derived Data -> Relative ; DerivedData
# otherwise you need to fix the Lilu.kext symbolic link to point to the build location of Lilu.kext.

#======================================
# Get MacKernelSDK project

mkdir -p ~/Programming/KextProjects/MacKernelSDK
cd ~/Programming/KextProjects/MacKernelSDK
git clone https://github.com/joevt/MacKernelSDK joevt-MacKernelSDK
cd ~/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK

#======================================
# Get and build Lilu project

mkdir -p ~/Programming/KextProjects/Lilu
cd ~/Programming/KextProjects/Lilu
git clone https://github.com/joevt/Lilu.git joevt-Lilu
cd ~/Programming/KextProjects/Lilu/joevt-Lilu
[[ -d MacKernelSDK ]] && rm MacKernelSDK
ln -s ~/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK MacKernelSDK
open -a "Xcode.app" Lilu.xcodeproj
# Build Lilu in Xcode

#======================================
# Get and build WhateverGreen project

mkdir -p ~/Programming/KextProjects/WhateverGreen
cd ~/Programming/KextProjects/WhateverGreen
git clone https://github.com/joevt/WhateverGreen.git joevt-WhateverGreen
cd ~/Programming/KextProjects/WhateverGreen/joevt-WhateverGreen
[[ -d Lilu.kext ]] && rm Lilu.kext
ln -s ~/Programming/KextProjects/Lilu/joevt-Lilu/DerivedData/Lilu/Build/Products/Debug/Lilu.kext Lilu.kext
[[ -d MacKernelSDK ]] && rm MacKernelSDK
ln -s ~/Programming/KextProjects/MacKernelSDK/joevt-MacKernelSDK MacKernelSDK
open -a "Xcode.app" WhateverGreen.xcodeproj
# Build WhateverGreen in Xcode

#======================================
# Repeat WhateverGreen steps for any other Lilu-based kexts that you want to use with Clover or OpenCore.

#======================================

 

Thanks for the fix.

I made "git stash" to exclude my changes and then "git pull" to accept your changes.

Now Lilu-DEBUG is compiled successfully but not release.

This variable is used only for DEBUG build  so should be excluded by

#ifdef DEBUG

#endif 

[Slice]

On 11/26/2022 at 10:18 AM, joevt said:

Thanks for checking. I fixed it by adding a commit to https://github.com/joevt/MacKernelSDK

 

I was able to build successfully in Ventura with Xcode 14.1

 

These are a minimum set of steps (you can change ~/Programming/KextProjects to wherever you like) :

 

Big thanks for the instructions and tips! Now I am able to compile also VoodooHDA in Xcode 14.1 with MacKernelSDK. Thanks also to Acidantera for this.

[SavageAUS]

Do we need a different framebuffer in Ventura 13.2 with coffeelake? I’ve recently made no changes to my config, just haven’t used macOS for about 2 weeks and now I boot to a black loading screen with Apple logo. I can VNC into my desktop so I know it is booting just not reaching the desktop on my laptops screen.
I7-9750H and UHD 630. It is definitely graphics related. I have the latest WEG and I have posted my config on the prerelease page page for Ventura 13.2.
Please help.


Sent from my iPhone using Tapatalk

[kocoman]

On 11/23/2022 at 1:21 AM, joevt said:

I think kext patches work the same as usual.

 

For user space patches, you can check my fork of Lilu/WhateverGreen. The dpd (displaypolicyd) and cdf (CoreDisplay.framework) patches have user-space patches that I've updated for Big Sur, Monterey, Ventura. CoreDisplay.framework is inside the dyld cache.

 

If you use my fork of WhateverGreen, then you need to use my fork of Lilu and recompile all other Lilu-based kexts that you use.

 

Another option is to make your own user patching code like what other Lilu-based kexts do. Other Lilu-based kexts each have their own code for user space patches for recent macOS versions. RestrictEvents.kext is one such example. Check the list of kexts that OCLP installs for possible other examples.

 

They all work by patching _cs_validate_page or _cs_validate_range depending on the macOS version.

 

One strange thing that might happen with user patches is that other processes may read the file that is being patched and the read result will also contain the patch. For example, a Finder copy of the patched file might result in the copy having the patch even though a patch should only exist in memory. Basically, the _cs_validate_page or _cs_validate_range overrides need to check the current process to make sure the patch is only applied for the intended process. In the case of CoreDisplay.framework, we want the patch to only be applied for the WindowServer process.

 

the Added disable-telemetry-load to disable iGPU telemetry loading that may cause a freeze during startup on certain laptops such as Chromebooks. https://github.com/acidanthera/WhateverGreen/commit/3c4ceca0d108f7cc03913c377b49304c9ba09f78

John Davis Goldfish64 no idea who he is he made a patch.. will try it on my skylake ventura coreboot/tianocore .. but he should write for coreboot/tianocore machine and fix IOSurface hang also, no idea how to contact him. or firexxx guy (also weg related)

I would take eons for me make the patch.. but thanks to him he made it

I wonder if I can use his patch to patch the hd4000 assert panic on libgfxinit

 

how to whatevergreen disable opengl

I need to fix some green screen in chrome

I have to use metal 

 

chrome://flags/

chrome://gpu

Choose ANGLE graphics backend

Choose the graphics backend for ANGLE. The OpenGL backend is soon to be deprecated on Mac, and may contain driver bugs that are not planned to be fixed. The Metal backend is still experimental, and may contain bugs that are still being worked on. The Metal backend should be more performant, but may still be behind the OpenGL backend until fully released. – Mac

 

also why get green screen and system hang if unplug hdmi? thx

ok to fix the reboot is use PowerTimeoutKernelPanic, then to fix the resolution use mobile framebuffer (if enabled applealc hdmi tv out)

 

how to force metal 2 instead of metal 3 on KBL(skylake spoofed) on ventura

thx

 

ok for the appleintelhd5000graphics bug I am able to use older version of it to stop the windowserver hang, then need chrome with -nogpu else it will hang later on.. need to figure out how to maybe force offline to use my universial-binary.zip for ventura

the bug is not in 12.1 but is in i guess 12.5 and up.. now I put 12.1 to 12.6.1 then ok

 

Edited January 23, 2023 by kocoman

[Baio77]

Hi I have a problem with the integrated screen (3000x2000) of my Thinkpad X1 Tablet I5 8250U.
I would like to know where I can write to get support and understand if the problem is solvable.
Thank you

Send me X1 Tablet.zip

Edited February 4, 2023 by Baio77

[kocoman]

On 2/3/2023 at 7:01 PM, Baio77 said:

Hi I have a problem with the integrated screen (3000x2000) of my Thinkpad X1 Tablet I5 8250U.
I would like to know where I can write to get support and understand if the problem is solvable.
Thank you

Send me X1 Tablet.zip 26.63 MB · 1 download

try older version of osx one by one till u find where the problem started. 

i wish oclp can open back its bugtracker, is there a oclp support thread in insanelymac?

[Slice]

On 2/8/2023 at 1:45 PM, kocoman said:

try older version of osx one by one till u find where the problem started. 

i wish oclp can open back its bugtracker, is there a oclp support thread in insanelymac?

Installing new macOS on unsupported hardware (OCLP patcher and others) 12347 

[deeveedee]

On 2/8/2023 at 5:45 AM, kocoman said:

try older version of osx one by one till u find where the problem started. 

i wish oclp can open back its bugtracker, is there a oclp support thread in insanelymac?

The OP has a KabyLake-R.  Why is OCLP relevant?

 

EDIT: I looked back for some history.  Maybe this response is two separate topics?

Edited February 12, 2023 by deeveedee