Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
HD4000 driver hack for custom VRAM size
- Thread starter kpkp
- Start date
- Sort by reaction score
Ok, thanks. I will try tomorrow.
edit: I tried, but it has no effect. The VRAM is always to 1536 MB after reboot.
Last edited:
@sinbad21 This is where I'm at a loss without an HD4000 Mac. I can't help any further without being able to test myself. Look at "kextstat -a" to confirm the Identifier for your OpenCore patch (confirm that the Identifier is com.apple.driver.AppleIntelFramebufferCapri). I think you have a good start with what you've learned.
EDIT: If you don't want to take the time to figure out your own kernel patch, you may be able to use Acidanthera's WhateverGreen.kext to patch HD4000 VRAM. Look at this to learn more. You would inject WhateverGreen.kext and specify DeviceProperty "framebuffer-unifiedmem" in your OpenCore config.plist to tell WhateverGreen to increase VRAM to 2048.
EDIT2: @sinbad21 I did a quick search and found other references that recommend patching VRAM with value 0x80000000 (not 0xFF000000). You may want to experiment with the following patch instead:
Find: <0000100700001007>
Identifier: com.apple.driver.AppleIntelFramebufferCapri
Mask: <FF00FFFFFFFFFFFF>
Replace: <0080100700001007>
The alternative as I said before would be to use WhateverGreen with the following DeviceProperties:
framebuffer-patch-enable 1
framebuffer-unifiedmem <00000080> (Little Endian representation of 0x80000000)
EDIT: If you don't want to take the time to figure out your own kernel patch, you may be able to use Acidanthera's WhateverGreen.kext to patch HD4000 VRAM. Look at this to learn more. You would inject WhateverGreen.kext and specify DeviceProperty "framebuffer-unifiedmem" in your OpenCore config.plist to tell WhateverGreen to increase VRAM to 2048.
EDIT2: @sinbad21 I did a quick search and found other references that recommend patching VRAM with value 0x80000000 (not 0xFF000000). You may want to experiment with the following patch instead:
Find: <0000100700001007>
Identifier: com.apple.driver.AppleIntelFramebufferCapri
Mask: <FF00FFFFFFFFFFFF>
Replace: <0080100700001007>
The alternative as I said before would be to use WhateverGreen with the following DeviceProperties:
framebuffer-patch-enable 1
framebuffer-unifiedmem <00000080> (Little Endian representation of 0x80000000)
Last edited:
It's surely very interesting but I don't need to patch this driver, I was doing this as an exercise. I don't really want to invest in OC that I don't really need, not having a hackintosh.
As far as the mask is concerned, the mask with FF works, because with the method I indicated in post #194 the memory was indeed increased.
In any case it allowed me to learn things, and I thank you for it. I still think that OC and OCLP are two different things, even if OCLP uses OC it adds so many layers that what works with OC may interfere with OCLP.
As far as the mask is concerned, the mask with FF works, because with the method I indicated in post #194 the memory was indeed increased.
In any case it allowed me to learn things, and I thank you for it. I still think that OC and OCLP are two different things, even if OCLP uses OC it adds so many layers that what works with OC may interfere with OCLP.
I come back to the subject. I tried to patch the extension with the value x'80' instead of x'FF' in the config.plist that is in the OC folder of the EFI on which I boot, but it doesn't work better.
When I look with a hexadecimal editor at the content of /Library/Extensions/AppleIntelFramebufferCapri.kext/Contents/MacOS/AppleIntelFramebufferCapri, I see that nothing has been replaced.
So I wonder how OpenCore works: when you patch an identifier in config.plist, when is this element patched? At the time of the boot? And is the replacement done physically in the extension that is in /Library/Extensions, or elsewhere, in a cache or something else? In short, I don't understand how it should work.
My purpose here as I explained is not to apply this change to the memory of the HD4000, I leave it to others, @ikir for example, to test the solution with WhateverGreen.
But I would like to know how the patch principle works. OpenCore's documentation is not very explicit on the subject.
Thanks for your investigation. I concluded the same. I should try with a older macOS to understand if the issue is OpenCore or not. I don’t know if I will try anymore, I forced myself to give up last weekend.
@sinbad21 OC does not patch the kext on disk. If you don't want to patch the kernel in memory, then you should continue to manually edit your kext on disk.
If you want help with OC, please post your OC config.plist (not the OCLP config.plist, but the OC config.plist in your boot disk's EFI) so I can review. Without your actual config.plist, I have no way of knowing whether you are correctly applying the kernel patch.
Also, run 'kextstat -a | grep -i capri' in terminal and post a screen shot of the result.
If you want help with OC, please post your OC config.plist (not the OCLP config.plist, but the OC config.plist in your boot disk's EFI) so I can review. Without your actual config.plist, I have no way of knowing whether you are correctly applying the kernel patch.
Also, run 'kextstat -a | grep -i capri' in terminal and post a screen shot of the result.
Last edited:
Hi,
Thank you for your help.
Code:
kextstat -a | grep -i capri
Executing: /usr/bin/kmutil showloaded --arch-info
No variant specified, falling back to release
140 0 0xffffff7f983c5000 0x49000 0x49000 x86_64 com.apple.driver.AppleIntelFramebufferCapri (16.0.4) FE00DDEF-CD76-371C-A6A5-D6959A096099 <139 132 131 16 15 9 8 7 6 3 1>@sinbad21 You did a great job on your patch. I see nothing wrong with the patch itself, but the ocvalidate utility (included with each release of OpenCore) finds the following error in your patch:
I'm not sure if this error in the comment would prevent OC from applying the patch, but please remove the illegal character from your comment and try again. I have edited your config.plist and attached it.
I'm not sure if this error in the comment would prevent OC from applying the patch, but please remove the illegal character from your comment and try again. I have edited your config.plist and attached it.
Unfortunately, it doesn't change anything. It's incomprehensible to me, if there is no syntax error, if the search mask is good, why doesn't it work? Is it because this AppleIntelFramebufferCapri extension is not natively part of macOS Ventura and has been artificially added by OCLP in /library/Extensions/? Mystery.
@sinbad21 You've been incredibly patient. I appreciate your willingness to experiment and can't ask for more. This is a mystery to me, too. I'm doing some research to learn more about kernel patching. I'll be back when I know more.
@sinbad21 Would you be willing to try WhateverGreen.kext? We would try this just to confirm that we can patch the kernel that has been modified by OCLP. If you are willing to continue this experiment, I would need the Device Path of your HD4000 graphics in order to make the mods to your config.plist. There are multiple ways to obtain the HD4000 Device Path. One easy way to obtain the HD4000 Device Path is to use Hackintool. Run Hackintool, click on the PCIe icon in the Hackintool menu bar (top of the Hackintool window), find the HD4000 in your PCIe device list, right-click on the HD4000 device listing and Copy Device Path. The Device Path will look something like PciRoot(0x0)/Pci(0x2,0x0). If you provide the HD4000 Device Path, I'll provide the modified config.plist that you can try.
@sinbad21 Would you be willing to try WhateverGreen.kext? We would try this just to confirm that we can patch the kernel that has been modified by OCLP. If you are willing to continue this experiment, I would need the Device Path of your HD4000 graphics in order to make the mods to your config.plist. There are multiple ways to obtain the HD4000 Device Path. One easy way to obtain the HD4000 Device Path is to use Hackintool. Run Hackintool, click on the PCIe icon in the Hackintool menu bar (top of the Hackintool window), find the HD4000 in your PCIe device list, right-click on the HD4000 device listing and Copy Device Path. The Device Path will look something like PciRoot(0x0)/Pci(0x2,0x0). If you provide the HD4000 Device Path, I'll provide the modified config.plist that you can try.
Last edited:
@sinbad21 I have attached a draft version of the new config.plist. You can edit this new config.plist to make sure that it includes the correct Device Path for your HD4000. After you make sure that the attached config.plist has the correct HD4000 Device Path (see more below), copy it to your EFI to replace your original config.plist. Then copy WhateverGreen.kext version 1.6.4 from here and place it in your EFI/OC/Kexts folder.
In the attached config.plist, make sure that the HD4000 Device Path (highlighted below) is correct. You can find the correct HD4000 Device Path using Hackintool as I explained previously.
The attached config.plist includes the following changes:
In the attached config.plist, make sure that the HD4000 Device Path (highlighted below) is correct. You can find the correct HD4000 Device Path using Hackintool as I explained previously.
The attached config.plist includes the following changes:
- Disabled the Kernel Patch (Kernel > Patch > Item 6)
- Added HD4000 Device Property (DeviceProperties > Add shown above)
- Added Kernel injection of WhateverGreen.kext:
Success! The new vram size is 2048.
It also works with x'FF' value in framebuffer-unifiedmem : 4080 MB.
If I want to put back the default value (1536 MB), what value should I put in framebuffer-unifiedmem ?
edit: I found it. Set the value to x'60', or keep '80' and disable the patch by setting 0 into framebuffer-patch-enable.
It also works with x'FF' value in framebuffer-unifiedmem : 4080 MB.
If I want to put back the default value (1536 MB), what value should I put in framebuffer-unifiedmem ?
edit: I found it. Set the value to x'60', or keep '80' and disable the patch by setting 0 into framebuffer-patch-enable.
Last edited:
@sinbad21 Congratulations! I still need to figure out why the original kernel patch didn't work. Now, whenever you upgrade Ventura (e.g., upgrade from 13.2.1 to 13.3), you can apply OCLP Post-Install patches without having to modify AppleIntelFramebufferCapri.kext. If you modify your EFI (e.g., you use a new version of OCLP to generate a new EFI), you will need to add WhateverGreen.kext to your EFI/OC/Kexts folder and make the config.plist mods that I provided.
When I figure out why the original kernel patch didn't work, I'll report back. If you figure it out, please report as well.
When I figure out why the original kernel patch didn't work, I'll report back. If you figure it out, please report as well.
@sinbad21 I'm wondering if a minor change to the kernel patch will fix it. Do you mind testing the attached config.plist? The attached config.plist includes the original kernel patch without the mask and with a revised "Find" as follows:
Find: <0060100700001007>
Identifier: com.apple.driver.AppleIntelFramebufferCapri
Mask: <>
Replace: <0080100700001007>
You can leave WhateverGreen.kext in EFI/OC/Kexts during this test. The attached config.plist doesn't inject WhateverGreen.kext, so the kext will simply be ignored.
Find: <0060100700001007>
Identifier: com.apple.driver.AppleIntelFramebufferCapri
Mask: <>
Replace: <0080100700001007>
You can leave WhateverGreen.kext in EFI/OC/Kexts during this test. The attached config.plist doesn't inject WhateverGreen.kext, so the kext will simply be ignored.
Last edited:
Okay, I will report if I find something new. I shall upgrade to 13.3 only if the OCLP team can resolve the problems with the 13.3 concerning my machine (presently the machines with HD4000 can't boot on 13.3 after patch).
The patch 0060 towards 0080 doesn't work.🤔
@sinbad21 I'm not sure why the kernel patch doesn't work. I think it should. From what I've learned, something changed in macOS Monterey (and subsequent macOS versions) that made graphics kernel patches more "tricky" (thus necessitating WhateverGreen.kext). I still think the OC kernel patch should work, but that may just be naive optimism.
@deeveedee Yes, everything seems to be getting trickier and trickier with new versions of macOS, especially with Ventura. All I can say is that the Capri kext patch doesn't work with either Monterey or Ventura. And we don't know why.
@sinbad21 I just learned from an expert in another forum that graphics can no longer be patched with OpenCore kernel patches. The graphics kexts are now handled differently by macOS. Using the method documented here, WhateverGreen.kext and DeviceProperties are the correct approach if performing graphics kernel patches with Open Core. Sometimes, learning lessons the hard way is the best way to learn. Neither of us will forget.
Ok, thanks! I found something about another kext, which seems to be similar.
Failure with com.apple.iokit.IONDRVSupport patching · Issue #1244 · acidanthera/bugtracker
Except from debug log 19:213 00:012 OC: Prelinked injection VoodooPS2Controller.kext\Contents\PlugIns\VoodooPS2Keyboard.kext (Keyboard) - Success 19:283 00:069 OCAK: Local relocs 1716 on FFFFFF8004...
github.com
Happily WhateverGreen is an excellent solution.