• Become a Premium Member for $25/year with no ads to improve your community experience. Upgrade to Pro Account for faster response and no wait times!

GUIDE How to Enable Intel Skylake Graphics (Intel HD Graphics 515, 520, 530, 540, 550 and 580) on macOS Sonoma and Later

I'm grateful for your replies to my questions, as always, thank you again. As for DVMT, I checked my bios and don't see any options. I will check again but I haven't seen anything. Since it's an AIO they may have decided to bake in those values and not expose them in BIOS. It certainly not obvious.

You mentioned checking whether the display is connected to IGPU or Nvidia; could you please point me to information that would allow me to confirm that? I've been on a search for motherboard schematics and other diagrams, hoping to figure out something like that.

The SKL CPU I have is a 6700T; it seems less common, and perhaps there is some additional configuration necessary.

I have another idea or two. First I was thinking of using VNC viewer after enabling share screen, so that even with the so-called correct ID and no native display I could blindly enter my password, and land on the desktop, at which point I could connect via VNC and perhaps look around. Doing that might allow OCLP to decide that it needs to do something with root patching.

The second idea relates to OCLP. When I build the EFI using the tool I see additional kext files, resources, etc, that I do not have in my EFI. So I was thinking about merging the so-called missing files and folders into my EFI, and updating my plist for the kext files. Essentially I am trying to get OCLP to acknowledge its existence on the system and similarly acknowledge that root patching has not occurred, and that it should do something. When I check the library folder there are simply the three EFI files like soft raid present. Even with that OCLP doesn't think it needs to do anything. I'm currently not running any device ID at all, only the AAPL value.

I'll read up on EDID, thank you for the tip. One additional thing, is that this is a dual boot setup, where I have Windows 10 running on a different partition. I have full access there for to anything in Windows, including device manager information. I've dug around in there looking for things, but I think it's a less common approach.
 
I'm grateful for your replies to my questions, as always, thank you again. As for DVMT, I checked my bios and don't see any options. I will check again but I haven't seen anything. Since it's an AIO they may have decided to bake in those values and not expose them in BIOS. It certainly not obvious.
It could be possible.

You mentioned checking whether the display is connected to IGPU or Nvidia; could you please point me to information that would allow me to confirm that? I've been on a search for motherboard schematics and other diagrams, hoping to figure out something like that.
Already linked it but will do that again.


The SKL CPU I have is a 6700T; it seems less common, and perhaps there is some additional configuration necessary.
Yes, the T CPUs are low TDP and no, there is not much to configure as the CPU is supported.

I have another idea or two. First I was thinking of using VNC viewer after enabling share screen, so that even with the so-called correct ID and no native display I could blindly enter my password, and land on the desktop, at which point I could connect via VNC and perhaps look around. Doing that might allow OCLP to decide that it needs to do something with root patching.
Yes, this is good idea!

The second idea relates to OCLP. When I build the EFI using the tool I see additional kext files, resources, etc, that I do not have in my EFI. So I was thinking about merging the so-called missing files and folders into my EFI, and updating my plist for the kext files. Essentially I am trying to get OCLP to acknowledge its existence on the system and similarly acknowledge that root patching has not occurred, and that it should do something. When I check the library folder there are simply the three EFI files like soft raid present. Even with that OCLP doesn't think it needs to do anything. I'm currently not running any device ID at all, only the AAPL value.
The steps are quite simple. Let's say for a SKL Desktop or Mobile CPU, one needs to have a correct EFI with the SKL device properties (framebuffer) and should be able to boot without any problems. As there are no SKL kexts present on macOS Sonoma and later, it will boot without any problems if the EFI is build correctly. Once the system is booted, make the necessary changes like disabling SIP, disabling Secure Boot to allow root patching. Reboot, and then just connect the system to interent, download and install OCLP and then run the root patching. Reboot when prompted and you should have the Graphics acceleration now. Of course, if you see a black/blank screen, the problem lies with the framebuffer patching. Also, not to forget some system may have a different panel which could be problematic and further adjustments might be necessary such as patching EDID or tuning the framebuffer patching.

I'll read up on EDID, thank you for the tip. One additional thing, is that this is a dual boot setup, where I have Windows 10 running on a different partition. I have full access there for to anything in Windows, including device manager information. I've dug around in there looking for things, but I think it's a less common approach.
Sounds great :)
 
Thank you, I hadn't seen the port checking link; my display is connected to the IGPU. I've been thinking about this relative to the computer being an AIO and decided to track down the monitor part. It's information is here. It's been bothering me that eDP hasn't been considered (in my case), as it would be (in my view) the most direct way to connect to the IGPU. All the framebuffers / AAPL ID's I've tried were all using DP or HDMI connectors. I want to go back to WEG's info and see if there are any SKL AAPL ID's using eDP.... it might mean something in my system.

I have presumed that an invalid ID would have the OS fallback to VESA mode... thus my display "works" with the invalid ID. I will confirm this as I can with the vesa boot arg as you suggest.

This may be another rabbit hole for me to explore.

As for OCLP, I'm running Monterey, so I've assumed that SKL kexts should be available. I think SIP and secure boot are disabled, but will check again.
 
I'm in the GUI thanks to your boot arg with the SKL AAPL ID 00001219. This feels like huge progress 🤣. I want to follow up with the other things you've mentioned and will report back later.
 
I've managed to disable SIP and secure boot, and OCLP won't apply any patches. I was hopeful. Maybe the boot arg way of having ID 00001219 'work' disables patching; I don't know.

Hackintool shows this information for the peripherals (attached).
 

Attachments

  • SIP AND SECUREBOOT STATUS.png
    SIP AND SECUREBOOT STATUS.png
    70.4 KB · Views: 2
  • Screen Shot 2025-05-09 at 4.23.25 PM.png
    Screen Shot 2025-05-09 at 4.23.25 PM.png
    25.8 KB · Views: 0
Last edited:
Thank you, I hadn't seen the port checking link; my display is connected to the IGPU. I've been thinking about this relative to the computer being an AIO and decided to track down the monitor part. It's information is here. It's been bothering me that eDP hasn't been considered (in my case), as it would be (in my view) the most direct way to connect to the IGPU. All the framebuffers / AAPL ID's I've tried were all using DP or HDMI connectors. I want to go back to WEG's info and see if there are any SKL AAPL ID's using eDP.... it might mean something in my system.
eDP has some problems and may need to address the issue. Had a few cases like Samsung where the eDP would just not output display despite of patching framebuffer correctly. It was Ivy Bridge/Haswell Laptop.

I have presumed that an invalid ID would have the OS fallback to VESA mode... thus my display "works" with the invalid ID. I will confirm this as I can with the vesa boot arg as you suggest.
That's right!

As for OCLP, I'm running Monterey, so I've assumed that SKL kexts should be available. I think SIP and secure boot are disabled, but will check again.
Oh, well. So, that's the reason why OCLP does not detect any patches. As the kexts are already present if you're sure you've installed Monterey, then there should be no need of the root patching.
 
I'm in the GUI thanks to your boot arg with the SKL AAPL ID 00001219. This feels like huge progress 🤣. I want to follow up with the other things you've mentioned and will report back later.
In VESA mode?
 
I've managed to disable SIP and secure boot, and OCLP won't apply any patches. I was hopeful. Maybe the boot arg way of having ID 00001219 'work' disables patching; I don't know.
It won't apply because the Monterey already has SKL Graphics kexts.
 
eDP has some problems and may need to address the issue. Had a few cases like Samsung where the eDP would just not output display despite of patching framebuffer correctly. It was Ivy Bridge/Haswell Laptop.


That's right!


Oh, well. So, that's the reason why OCLP does not detect any patches. As the kexts are already present if you're sure you've installed Monterey, then there should be no need of the root patching.
Great, just need to connect the IGPU kexts to the device, I suppose.
 

Forum statistics

Threads
1,994
Messages
18,680
Members
28,488
Latest member
al3x5