Jump to content

HDMI issue on SKL laptop spoofed as KBL with macOS Sonoma


Francesco Guagnano
 Share

83 posts in this topic

Recommended Posts

Hi everyone,

 

I'm having an issue about HDMI on my laptop after upgrade to Sonoma.

I spoofed SKL as KBL setting the right device properties in my config.list and when I plug the HDMI cable at the startup after the apple logo progress I'm having the green screen on my external monitor for a few seconds and then the external monitor starts to lag while the internal display is completely black.

I can fix only if I try to set the sleep mode.

Here you are my EFI https://github.com/ciccio-90/Lenovo_V110-15ISK_Hackintosh_OpenCore_macOS_Sonoma/tree/main/EFI

Who can help me?

Thanks in advance!

F.

Link to comment
Share on other sites

  • 2 weeks later...

@Francesco Guagnano

 

Hmmm… Try this:

  • Backup your current EFI folder on a FAT32 formatted USB flash drive so you can boot from it if something goes wrong
  • Disable the kaby lake iGPU spoof. Instead use: AAPL,ig-platform-id 00001619
  • Disable the device-id as well!
  • Add RestrictEvents.kext
  • Add boot-arg revpatch=sbvmm --> Allows booting with unsupported SMBIOS
  • Optional: Add boot-arg -igfxvesa --> disables iGPU graphics acceleration (just in case the screen does not turn on after 1st reboot)
  • Change SMBIOS to MacBookPro13,1
  • Reboot
  • Download OpenCore Legacy Patcher
  • Apply Post-Install Root Patches for the iGPU. It re-installs the following Skylake drivers that have been removed from macOS 13+:
    • AppleIntelSKLGraphics.kext
    • AppleIntelSKLGraphicsFramebuffer.kext
    • AppleIntelSKLGraphicsGLDriver.bundle
    • AppleIntelSKLGraphicsMTLDriver.bundle
    • AppleIntelSKLGraphicsVADriver.bundle
    • AppleIntelSKLGraphicsVAME.bundle
    • AppleIntelGraphicsShared.bundle
  • Delete -igfxvesa boot-arg again.
  • Save your config and reboot. After that the iGPU should work as expected again.

 

Let me know if this works.

Edited by cankiulascmnfye
  • Like 1
Link to comment
Share on other sites

Config is looking good so far.

 

But: Disable the following entries in the Framebuffer patch (put # in front of them)

  • device-id – This is only required for the HD 510 but your CPU has an Intel HD 520 which is natively supported by macOS
  • framebuffer-con1-alldata – since this data is from another AAPL…
  • framebuffer-con1-enable – same

I don't see any errors in the boot log. When does the error happen? After the Apple Logo has appeared?

 

PS: You can revert root patches by booting into safe mode (hold shift and presse enter in boot menu )and running the patcher again.

 

Edited by cankiulascmnfye
  • Like 1
Link to comment
Share on other sites

Experiment with it. There are 2 options:

  1. Try to make the iGPU acceleratio work with the Skylake SMBIOS (Experiment with data from Whatevergreen's Intel HD FAQ)
  2. Switch to Kaby Lake SMBIOS (MBP14,1) and use a Kaby Lake device-id. Then modify the framebuffer-patch so it works with your external display: https://github.com/5T33Z0/OC-Little-Translated/tree/main/11_Graphics/iGPU/Framebuffer_Patching
  • Like 1
Link to comment
Share on other sites

Fun Fact: Kaby Lake, Amber Lake, Coffee Lake, Whiskey Lake and Comet Lake platforms (including Skylake) are pretty much similar in architecture, and as such have always been part of the Kaby Lake Graphics Stack in macOS - which also explains why it’s pretty easy/straightforward for Skylake platforms to leverage off the KBL Graphics Stack with just a simple spoof on Ventura and above (as opposed to Broadwell or Haswell platforms that require heavy-handed root patching to try and maintain compatibility with the newer Metal API feature-set).

With that being said: there’s NO need to break root volume seal, weaken system security and re-install SKL’s iGPU binaries just to try and alleviate the above reported issue; not really the sanest approach, to be honest (at least on hacks).

Also, one of the many logical reasons why most OCLP patches are developed towards supporting real Apple hardware: as there’s a ton of Apple-specific variables under the hood that requires maintaining parity with genuine Apple firmwares (to restore proper support for DRM, Apple GuC.. to name a few) - attempting such undocumented/unofficial approaches on hacks is most likely to introduce more issues, if anything. (Just goes to show that the OCLP team does indeed have meaningful reason to not entertain providing support for such high-level patches on hacks, as they’re NOT developed to be used on non-Apple hardware!)

@Francesco Guagnano Kindly ditch the OCLP route and revert to your system's original state. To resolve the problem with HDMI handshake, you'll need to disable Apple Graphics Device Control (AGDC) as it's causing conflicts when spoofing SMBIOS/Board-ID on non-native macOS versions.

To disable, inject the following property under iGPU device properties:

disable-agdc     DATA      01000000
  • Like 2
Link to comment
Share on other sites

3 hours ago, aben said:

(Just goes to show that the OCLP team does indeed have meaningful reason to not entertain providing support for such high-level patches on hacks, as they’re NOT developed to be used on non-Apple hardware!)

 

Well, let's hope this works.

 

However, I believe the only meaningful reason why OCLP is not promoted nor supported on Hackintoshes is not technical at all – it's a legal issue. Because the patcher actually manupilates the root volume, which makes it not vanilla any more for one and secondly, the patcher contains files lifted from previous macOS versions which are distributed with the patcher. These 2 facts alone would be enough for a DMCA takedown.

Edited by cankiulascmnfye
Link to comment
Share on other sites

@aben unfortunately

disable-agdc     DATA      01000000

does not work.

I attached the only configuration that works for now.

In this configuration I replaced the internal display connector with the HDMI one in the following way:

<key>framebuffer-con0-enable</key>
<data>
AQAAAA==
</data>
<key>framebuffer-con0-alldata</key>
<data>
AQUJAAAIAACHAQAA
</data>

The downside of this approach is that the external monitor works but the internal one doesn't work anymore.

Do you suggest something else?

config.plist

Link to comment
Share on other sites

Yeah, well you probably turned the external monitor into the primary display by using this data for con0. But you need to use is for con1. Con0 is for the internal display (as explained in my framebuffer patching guide I linked to earlier which I wrote specifically for the case of connecting external monitors to laptops).

  • Like 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...