Jump to content

HDMI issue on SKL laptop spoofed as KBL with macOS Sonoma

Francesco Guagnano

By Francesco Guagnano,
in Intel

 Share
83 posts in this topic

Recommended Posts

deeveedee
deeveedee
Posted
Posted (edited)

@Francesco Guagnano Did aben's suggestion to add disable-agdc help? I just read here that adding disable-agdc did not help.   It looks like here that you are able to boot Sonoma, but you have only the external display.  Is that true?  Would you say that so far, this is your best config.plist?

Edited by deeveedee
Link to comment
Share on other sites
Francesco Guagnano
Francesco Guagnano
Posted
  • Author
Posted
22 minutes ago, cankiulascmnfye said:

Try the other device IDs (convert them to Little Endian first!)

 

Native supported DevIDs:

  • 0x1916 = 00001619 (current)
  • 0x191E = 00001E19
  • 0x1926 =  00002619 and so on
  • 0x1927
  • 0x1912
  • 0x1932
  • 0x1902
  • 0x1917
  • 0x193B
  • 0x191B

 

Don't add any random framebuffer patches from other systems blindly to your config! Understand the priniple behind it.

I will try all of them. Thanks.

5 minutes ago, deeveedee said:

@Francesco Guagnano Did aben's suggestion to add disable-agdc help?  It looks like here you said that after adding disable-agdc, you are able to boot Sonoma, but you have only the external display.  Is that true?

The disable-agdc did not help me. What works with or without that property is to patch the con0 but in this case only ext display works.

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
12 minutes ago, Francesco Guagnano said:

The disable-agdc did not help me. What works with or without that property is to patch the con0 but in this case only ext display works.

 

Ok.  So far, is this config.plist that you posted here (with con0 modified) the config.plist that is working best for you in Sonoma?

 

EDIT: If so, what happens when you patch both con0 and con1 as HDMI (see attachment)?

config.plist.zip

Edited by deeveedee
Link to comment
Share on other sites
Francesco Guagnano
Francesco Guagnano
Posted
  • Author
Posted
9 minutes ago, deeveedee said:

 

Ok.  So far, is this config.plist that you posted here (with con0 modified) the config.plist that is working best for you in Sonoma?

 

EDIT: If so, what happens when you patch both con0 and con1 as HDMI (see attachment)?

config.plist.zip 1.71 kB · 0 downloads

I have the issue if I patch both connectors.

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
29 minutes ago, Francesco Guagnano said:

I have the issue if I patch both connectors.

A very interesting problem.  I think you are very close with the config.plist that you posted here.  If you don't patch any connectors, does your internal display work?

 

EDIT: This is my preferred Intel frame buffer patching reference.  It seems to me that you know what you are doing.  Have you tried testing other Kabylake mobile frame buffers (e.g., 0x591B0000) while leaving your device-id as 0x5916?

 

EDIT2: I was looking back through my Kabylake patching notes.  When I was experimenting with different frame buffers, I found it helpful to add boot-arg -disablegfxfirmware until I found a working frame buffer.  Do not include rps-control or other firmware boot-args/DeviceProperties until you find the working frame buffer.

 

Edited by deeveedee
Link to comment
Share on other sites
Francesco Guagnano
Francesco Guagnano
Posted
  • Author
Posted
1 hour ago, deeveedee said:

A very interesting problem.  I think you are very close with the config.plist that you posted here.  If you don't patch any connectors, does your internal display work?

 

EDIT: This is my preferred Intel frame buffer patching reference.  It seems to me that you know what you are doing.  Have you tried testing other Kabylake mobile frame buffers (e.g., 0x591B0000) while leaving your device-id as 0x5916?

 

EDIT2: I was looking back through my Kabylake patching notes.  When I was experimenting with different frame buffers, I found it helpful to add boot-arg -disablegfxfirmware until I found a working frame buffer.  Do not include rps-control or other firmware boot-args/DeviceProperties until you find the working frame buffer.

 

If I don't patch any connectors, the internal display works perfectly.

I tried 0x591B0000 and the current one without any success. I will try others.

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
32 minutes ago, Francesco Guagnano said:

If I don't patch any connectors, the internal display works perfectly.

I tried 0x591B0000 and the current one without any success. I will try others.

Ok - I think you are very close.  Keep boot-arg -disablegfxfirmware while you are testing different frame buffers.

 

EDIT: Also, when you boot Sonoma with working internal display, could you please post your IORegistry extracted with IORegistryExplorer 2.1 (attached)? Thank you.

 

EDIT2: Also, aben's recommendation here to include disable-agdc may be helpful while you are testing different frame buffers.

IORegistryExplorer.zip

Edited by deeveedee
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@Francesco Guagnano Sorry to keep adding advice, but I found this commit (to Intel HD patching docs) which suggests adding AAPL,GfxYTile which you'll see that I include here.  

 

In summary, while you are experimenting with different frame buffers (keeping device-id 0x5916), include the following boot-args / DeviceProperties:

  • AAPL,GfxYTile = 0x01 (DeviceProperties)
  • -disablegfxfirmware (boot-arg)
  • disable-agdc = 0x01 (DeviceProperty)

 

Note that the commit says that the AAPL,GfxYTile property is for macOS 10.14, but it can't hurt to include it for all of your testing.

Edited by deeveedee
Link to comment
Share on other sites
Francesco Guagnano
Francesco Guagnano
Posted
  • Author
Posted (edited)

@cankiulascmnfye I tried every SKL device-id but the graphic acceleration does not work.

@deeveedee I tried every model KBL frame buffer but the topic issue persists. Should I test the desktop ones as well?

Anyway I attach my IORegistryExplorer log.

MacBook Pro.ioreg.zip

Edited by Francesco Guagnano
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted
2 minutes ago, Francesco Guagnano said:

Anyway I attach my IORegistryExplorer log

 

I am unable to open your IOReg.  Did you create it with the IORegistryExplorer 2.1 that I provided here?

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@Francesco Guagnano  Take a look at your IOReg explorer dump.  Assuming that you have dumped this when your internal display was working, what do you notice about the properties of Framebuffer0 and Framebuffer1?  Which one is the boot display?

 

Based on this dump, is it possible that your internal display is not con0 and is instead con1?  Could you please post the config.plist that was active when you collected  your posted IOReg dump?  Could you also please confirm that you have only one Open Core EFI in your hack?  Thank you.

 

EDIT: If your internal display is con1, could your HDMI port be something other than con1 (maybe it is con0 or possibly con2)?

 

EDIT2: What happens if you patch con1 as LVDS and con0 as HDMI?

 

EDIT3: If patching con1 as LVDS and con0 as HDMI does not work, I think you need to revisit your conX mapping and make sure that you have associated the physical graphics ports with the correct logical conX connectors.  You may be able to find the conX connector associated with the HDMI port by booting Sonoma without the HDMI port connected to your external display (with the working internal display) and then connecting and disconnecting the HDMI port with IORegExplorer open.  You may be able to see activity on one of the conX connectors while you connect and disconnect HDMI.

 

Grazie per la vostra pazienza

Edited by deeveedee
Link to comment
Share on other sites
Francesco Guagnano
Francesco Guagnano
Posted
  • Author
Posted
24 minutes ago, deeveedee said:

@Francesco Guagnano  Take a look at your IOReg explorer dump.  Assuming that you have dumped this when your internal display was working, what do you notice about the properties of Framebuffer0 and Framebuffer1?  Which one is the boot display?

 

Based on this dump, is it possible that your internal display is not con0 and is instead con1?  Could you please post the config.plist that was active when you collected  your posted IOReg dump?  Could you also please confirm that you have only one Open Core EFI in your hack?  Thank you.

 

EDIT: If your internal display is con1, could your HDMI port be something other than con1 (maybe it is con0 or possibly con2)?

 

EDIT2: What happens if you patch con1 as LVDS and con0 as HDMI?

 

EDIT3: If patching con1 as LVDS and con0 as HDMI does not work, I think you need to revisit your conX mapping and make sure that you have associated the physical graphics ports with the correct logical conX connectors.  You may be able to find the conX connector associated with the HDMI port by booting Sonoma without the HDMI port connected to your external display (with the working internal display) and then connecting and disconnecting the HDMI port with IORegExplorer open.  You may be able to see activity on one of the conX connectors while you connect and disconnect HDMI.

 

Grazie per la vostra pazienza

@deeveedee

The boot display is the internal one Framebuffer0.

I'm sure that the internal display is the con0 because the hackintool recognaize it and the con1 is the HDMI.

The config.plist that I used is the repo one.

I confirm that I have only one Open Core EFI.

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted
3 hours ago, Francesco Guagnano said:

@deeveedee @cankiulascmnfye

Maybe I have good news. If I attach the HDMI cable after system boot, everything works perfectly using my repo config.plist.

That is good news! Please post your IOReg 2.1 dump with both displays working.  There have been others who reported similar problem (display works only if plugged in after booting). I'm not sure how it was solved.

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@Francesco Guagnano

 

Your Framebuffer patch specifies the following

 

01 05 0900 0008 0000 8701 0000

  • Index 01
  • BusID 05
  • Pipe 09
  • Type 0800
  • Flags 0187

The Framebuffer you selected (0x59160000) specifies con1 as Index 0x01, BusID 0x05, Pipe 0x09, Type 0400, Flags 0187, so you are changing the Type.

Spoiler 
ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B
TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00080000 87010000

 

Does your graphics behavior change if you make the following changes (see attached config.plist):

  • Flags = 0x03C7
  • PortCount = 2 / Disable con2
  • disable-agdc = 0x01
  • force-online = 0x01 (replaces your gfxonln=1 boot-arg)
  • force-online-framebuffers = 0x01 (limits force-online to con1)

 

config.plist.zip

 

 

EDIT: if this update config.plist does not work (does not allow you to boot with HDMI connected), please post your new IORegistryExplorer dump with the updated config.plist.  Grazie.

 

EDIT2: @Francesco Guagnano  Does you BIOS configuration have any graphics settings that let you specify the primary display?  If so, is the internal display set as the primary?

Edited by deeveedee
Link to comment
Share on other sites
Francesco Guagnano
Francesco Guagnano
Posted
  • Author
Posted
1 hour ago, deeveedee said:

@Francesco Guagnano

 

Your Framebuffer patch specifies the following

 

01 05 0900 0008 0000 8701 0000

  • Index 01
  • BusID 05
  • Pipe 09
  • Type 0800
  • Flags 0187

The Framebuffer you selected (0x59160000) specifies con1 as Index 0x01, BusID 0x05, Pipe 0x09, Type 0400, Flags 0187, so you are changing the Type.

  Reveal hidden contents 
ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B
TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00080000 87010000

 

Does your graphics behavior change if you make the following changes (see attached config.plist):

  • Flags = 0x03C7
  • PortCount = 2 / Disable con2
  • disable-agdc = 0x01
  • force-online = 0x01 (replaces your gfxonln=1 boot-arg)
  • force-online-framebuffers = 0x01 (limits force-online to con1)

 

config.plist.zip 5.01 kB · 2 downloads

 

 

EDIT: if this update config.plist does not work (does not allow you to boot with HDMI connected), please post your new IORegistryExplorer dump with the updated config.plist.  Grazie.

 

EDIT2: @Francesco Guagnano  Does you BIOS configuration have any graphics settings that let you specify the primary display?  If so, is the internal display set as the primary?

@deeveedee That config does not work as well (I have the known issue). I attach the new IOReg file. In my laptop BIOS there are no graphics settings.

MacBook Pro.ioreg

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted

@Francesco Guagnano I'm guessing that the framebuffer con1 flags are what makes it worse.  To test this theory, could you test the attached config.plist with the flags reset to their 0x59160000 framebuffer defaults (your original values)?  Thank you.

 

 

config.plist.zip

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@Francesco Guagnano I found something that may be related to your issue here.  It looks like you may need to force complete modeset on Skylake.  To do this, I think you will add the following WhateverGreen properties:

  • complete-modeset : <01000000>
  • complete-modeset-framebuffers : <00000000> <00> (applies complete-modeset to your internal display at con0) (I think this is wrong in the bug tracker I linked above)

Try the attached config.plist to see if this works for you.  If it works, there are probably some DeviceProperties that we can remove from your config.plist.

 

EDIT: @Francesco Guagnano I'm reading the WhateverGreen docs which say that completemodeset is for non-builtin monitors. If my attached config.plist doesn't work, try changing complete-modeset-framebuffers to <01000000> <01> and test again.

 

EDIT2j: @Francesco Guagnano I think that my recommendations for the possible values of complete-modeset-framebuffers should be <00> and <01> (not <00000000> and <01000000>).  I'm not sure, because I'm still experimenting on my own hack.

 

 

config.plist.zip

Edited by deeveedee
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)

@Francesco Guagnano Thank you for patiently trying all of the suggestions.  I'm out of ideas.  There are other people with the same black screen problem, so hopefully someone else has suggestions.  I think you are very close, since everything works for you if you boot without HDMI connected and then connect HDMI after macOS is booted.  Good luck.  I'm looking forward to following your progress.

 

EDIT: You may want to install Ventura 13.6.1 and make sure that everything still works with the SMBIOS change (to MBP15,2).

Edited by deeveedee
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted

@Francesco Guagnano and others monitoring this thread.  I found that it is best to "Reset NVRAM" after changing graphics DeviceProperties.   I'm not sure if this would have affected any test results in this thread, but after my experience with DeviceProperties and WhateverGreen.kext, I always "Reset NVRAM" (from OC's extended boot menu) before booting and testing macOS with new graphics DeviceProperites.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...