HD4000 driver hack for custom VRAM size

[Macbookprodude]

Just get a 2015 MacBook Pro - I tried that hack on my 2012 under Catalina and the OS almost destroyed it

 

[David Alejandro Rachè]

I am trying this on my late 2012 rmbp with hd4000 still no results.

 

[Macbookprodude]

Dude, Its not even worth it. But, what you need to do is de-activate the SIP and then it should work. I stopped doing it because it dodesn't really give a boost in performance, which is why I jumped ship and went with the 2015 MacBook Pro - while I still have the 2012 MacBook Pro, its being used as a server to host my OS 9 machines for development purposes and web browser engine creation. Yeah, I am trying to modernize OS 9 for 21st century. But, still the HD 3000 and HD 4000 hacks don't really do anything, and Catalina will act funny with it.

 

[CuchoM]

I am trying this on my late 2012 rmbp with hd4000 still no results.

sudo perl -pi -e 's|\x00.{1}\x10\x07\x00\x00\x10\x07|\x00\x??\x10\x07\x00\x00\x10\x07|g' ~/Desktop/AppleIntelFramebufferCapri.kext/Contents/MacOS/AppleIntelFramebufferCapri

change ?? to 80 works fine macOS 11.5 - 2GB Vram

Change the ?? with the number bellow to set the desired amount of VRAM:


10 = 256MB of RAM
18 = 384MB of RAM
20 = 512MB of RAM
30 = 768MB of RAM
40 = 1024MB of RAM
80 = 2048MB of RAM

1. copy AppleIntelFramebufferCapri.kext to the desktop and make a backup of it
2. run the script in the terminal (dont forget to fill in the ??)

 

[CuchoM]

Thanks @jackluke with 4GB playing 4K video in YouTube on Safary

 

[CuchoM]

For Catalina you need to do exactly this:

- boot with CMD+R , from recovery environment open terminal and type: csrutil disable ; reboot

- boot normal on Catalina, open terminal and copy paste one line at once:

sudo -s

mount -uw /

cd /System/Library/Extensions/AppleIntelFramebufferCapri.kext/Contents/MacOS

perl -pi -e 's|\x00.{1}\x10\x07\x00\x00\x10\x07|\x00\xFF\x10\x07\x00\x00\x10\x07|g' AppleIntelFramebufferCapri

chmod -R 755 /S*/L*/E*

chown -R 0:0 /S*/L*/E*

kextcache -i /

(this takes some minutes to complete)

reboot

After any macOS update you have to repeat because apple copies again the stock kext.

Do you have any idea how to make this at macOS Monterey ? I tried and it does not work

 

[justperry]

Do you have any idea how to make this at macOS Monterey ? I tried and it does not work

You need to specify why it does not work, ie, what happens, do you get any errors, like

volume could not be mounted: Permission denied
mount: / failed with 66

Just saying it does not work isn't enough.

 

[jackluke]

Do you have any idea how to make this at macOS Monterey ? I tried and it does not work

Essentially the same method you used on BigSur, the driver is the same, anyway to simplify a bit the steps on Monterey you could try this: BigSurmountsrw2.app.zip

launch and select your Monterey System, then don't click yet "Rebuild KC" and don't close the window, but instead open terminal and type (copy paste):

cd /System/Volumes/Update/mnt1/System/Library/Extensions/AppleIntelFramebufferCapri.kext/Contents/MacOS

sudo perl -pi -e 's|\x00.{1}\x10\x07\x00\x00\x10\x07|\x00\xFF\x10\x07\x00\x00\x10\x07|g' AppleIntelFramebufferCapri

then return to the windowed app and click "Rebuild KC" at reboot it should work.

 

[Macbookprodude]

Does this work on a 2015 MacBook Pro ?

 

[justperry]

Does this work on a 2015 MacBook Pro ?

Does yours have a HD4000...here's the answer....

 

[justperry]

Thanks @jackluke with 4GB playing 4K video in YouTube on Safary

It makes no difference, jerky with or without (Default) 4 GB RAM

 

[Macbookprodude]

Does yours have a HD4000...here's the answer....

View attachment 1808344

It has an Intel Iris.. so I guess its a no, but when i HAD a 2012 and tried this hack I saw no real benefit.

 

[CuchoM]

You need to specify why it does not work, ie, what happens, do you get any errors, like

volume could not be mounted: Permission denied
mount: / failed with 66

Just saying it does not work isn't enough.

It does not show any error message , even I've make it on BS11.5 that works on Monterey does not show up VRAM memory. I am now reinstalling Monterey with OCLP 0.2.4 and see if it works

Tested and works

 

[ikir]

It makes no difference, jerky with or without (Default) 4 GB RAM


View attachment 1808486

In Open Core? Is it possible to use this hack on Open Core?

 

[ikir]

It does not show any error message , even I've make it on BS11.5 that works on Monterey does not show up VRAM memory. I am now reinstalling Monterey with OCLP 0.2.4 and see if it works

Tested and works

Can you tell me how you done this with OCLP? I have an old MBP 2012 with HD 4000 and I want to try increase memory since the machine has 16GB of RAM. I know the performance are the same but for some old games apps it could be nice to have 2GB or 4GB.

 

[deeveedee]

@ikir if You perform "kextstat -a | grep -i capri" on your OCLP-patched Mac, do you see the AppleIntelFramebufferCapri.kext?

 

[ikir]

@ikir if You perform "kextstat -a | grep -i capri" on your OCLP-patched Mac, do you see the AppleIntelFramebufferCapri.kext?

trying later today

yes i see it! It is seems to be located in root library extensions.

I’ve tried to edit it but on Ventura I’m not sure how to rebuild kext cache

 

[deeveedee]

Search the web for rebuild kext cache macos and you'll find lots of posts. If you want a tool that does it for you, look at Hackintool. I would suggest following JackLuke's post here and then debugging from there.

EDIT: Once you confirm that the kext patch works for you, you should be able to replace your manually edited kext with a kernel patch in OpenCore's config.plist (what I had stated in the other thread). JackLuke is in a better position to confirm this than I am, since I don't have a Mac with HD4000. If you are able to create a kernel patch in OpenCore's config.plist (a kernel patch that performs the hex replacement specified by JackLuke), you won't need to keep performing the manual kext patch each time your perform an upgrade that requires reapplication of OCLP post-install patches.

 

[sinbad21]

Search the web for rebuild kext cache macos and you'll find lots of posts. If you want a tool that does it for you, look at Hackintool. I would suggest following JackLuke's post here and then debugging from there.

EDIT: Once you confirm that the kext patch works for you, you should be able to replace your manually edited kext with a kernel patch in OpenCore's config.plist (what I had stated in the other thread). JackLuke is in a better position to confirm this than I am, since I don't have a Mac with HD4000. If you are able to create a kernel patch in OpenCore's config.plist (a kernel patch that performs the hex replacement specified by JackLuke), you won't need to keep performing the manual kext patch each time your perform an upgrade that requires reapplication of OCLP post-install patches.

I tried a slightly different method, which also works:

- Build a first time the binary, a payloads.dmg is generated. Trash it.
- Uncompress Universal-Binaries.zip which is in payloads folder, then trash it.
- Look for the kext to patch, patch it.
- Compress Universal-Binaries folder, then trash the folder.
- Build the binary again. A new payloads.dmg is generated, which contains the patched kext.

 

[deeveedee]

If the proposed kext patch does what you expect, then my recommendation would be to implement the patch as a kernel patch in OpenCore's config.plist. Doing so eliminates the need to manually patch the kext (or payloads.dmg) so you don't need to manually re-create the kext/dmg each time you apply OCLP post-install patches for a new version of OCLP. I haven't studied the patch and I don't have an HD4000 to test, so you'll need to review this and adjust as needed, but the basic method is as follows:

If replacing hex sequence 00 ?? 10 07 00 00 10 07 with 00 FF 10 07 00 00 10 07 in kext AppleIntelFramebufferCapri (where ?? is wildcard)

Find: <0000100700001007>
Identifier: com.apple.driver.AppleIntelFramebufferCapri
Mask: <FF00FFFFFFFFFFFF>
Replace: <00FF100700001007>

 

[sinbad21]

If the proposed kext patch does what you expect, then my recommendation would be to implement the patch as a kernel patch in OpenCore's config.plist. Doing so eliminates the need to manually patch the kext (or payloads.dmg) so you don't need to manually re-create the kext/dmg each time you apply OCLP post-install patches for a new version of OCLP. I haven't studied the patch and I don't have an HD4000 to test, so you'll need to review this and adjust as needed, but the basic method is as follows:

If replacing hex sequence 00 ?? 10 07 00 00 10 07 with 00 FF 10 07 00 00 10 07 in kext AppleIntelFramebufferCapri (where ?? is wildcard)

Find: <0000100700001007>
Identifier: com.apple.driver.AppleIntelFramebufferCapri
Mask: <FF00FFFFFFFFFFFF>
Replace: <00FF100700001007>

Yes, it would be easier, but I don’t know Python, and presently there is no mention of AppleIntelFramebufferCapri in config.plist.

My method is more « OCLP for dummies », no need to code anything.

 

[deeveedee]

@sinbad21 You need to re-read my post and learn more about the OpenCore config.plist. No python. No coding. No reason to expect any current mention of AppleIntelFramebufferCapri in config.plist. You must be thinking of something else. My solution is a pure OpenCore solution. With legacy Macs that are now using OpenCore, we should be leveraging the additional benefits of OpenCore. Do a web search for OpenCore Kernel patching.

EDIT: For those who do not need an OpenCore EFI and who are only using OCLP's post-install patches, your solution is certainly an option. For those who now have an OpenCore EFI to boot their legacy Mac, utilizing the OpenCore config.plist to implement the kernel patch just makes sense.

 

[sinbad21]

@sinbad21 You need to re-read my post and learn more about the OpenCore config.plist. No python. No coding. No reason to expect any current mention of AppleIntelFramebufferCapri in config.plist. You must be thinking of something else. My solution is a pure OpenCore solution. With legacy Macs that are now using OpenCore, we should be leveraging the additional benefits of OpenCore. Do a web search for OpenCore Kernel patching.

EDIT: For those who do not need an OpenCore EFI and who are only using OCLP's post-install patches, your solution is certainly an option. For those who now have an OpenCore EFI to boot their legacy Mac, utilizing the OpenCore config.plist to implement the kernel patch just makes sense.

Okay, I understand better. I thought you were talking about the config.plist that is in the OCLP source folder, but you are thinking of the config.plist of the EFI OC folder.

I guess you're thinking of a patch in the style of item 5 of this window.

 

[deeveedee]

@sinbad21 Yes. I did a quick search of the AppleIntelFramebufferCapri binary and found multiple instances of the "Find" hex sequence, so you will want to specify Count = 0 in the kernel patch (allow the patch to revise all instances of the hex sequence). This is different from Count = 1 in the example you cited.

 

[sinbad21]

@sinbad21 Yes. I did a quick search of the AppleIntelFramebufferCapri binary and found multiple instances of the "Find" hex sequence, so you will want to specify Count = 0 in the kernel patch (allow the patch to revise all instances of the hex sequence). This is different from Count = 1 in the example you cited.

Something like that: