Jump to content
211 posts in this topic

Recommended Posts

@deeveedee, I consulted with AI. How would you comment on AI's responses?

 

My question:
Is it possible that my Gigabyte Z490 VISION G rev 1.1 simply cannot operate its HDMI port (which internally uses DP → HDMI via LSPCON) under macOS, even though it works correctly under Windows and Linux?

 

Answer:
Yes. This situation has been reported specifically with the Gigabyte Z490 VISION G rev 1.1.
The board does contain an LSPCON chip, but on revision 1.1 it behaves differently compared to rev 1.0.

Windows and Linux drivers:

  • detect the MegaChips/Parade LSPCON automatically

  • initialize it without user involvement

macOS, however:

  • does not initialize LSPCON by itself

  • depends on firmware/BIOS providing the correct initialization

On revision 1.1, the LSPCON may not enter the required operating mode unless initialized by an OS driver that explicitly supports it. macOS lacks this support.

Your symptoms match this exactly:

  • HDMI works in UEFI

  • HDMI disappears the moment AppleFramebuffer loads

  • correct connector patches / BusIDs / LSPCON settings make no difference

This happens when macOS is unable to perform DP→HDMI link training because the LSPCON firmware on the motherboard does not expose the expected behavior.

In other words:

On Z490 VISION G rev 1.1, HDMI via UHD630 may be effectively non-functional under macOS, while working normally in Windows and Linux.

  • Like 1
1 hour ago, verdazil said:

In other words:

On Z490 VISION G rev 1.1, HDMI via UHD630 may be effectively non-functional under macOS, while working normally in Windows and Linux.

There are some questions, such as "Why does it work fine on the Sequoia but not on the Tahoe?" and "Why does it work fine on the iMac19,2 but not on the Macmini8,1?", but it seems that WEG has a solution.
 

  • Like 1
6 hours ago, Asural said:

According to the OpenCore specification, if required information is undefined, it is unclear what will be set (it always results in the worst value).
framebuffer-conX-enable, framebuffer-conX-index, and framebuffer-conX-busid are required information, and WEG should not be left to its own devices.
I recommend setting all of con0, con1, and con2.

 

This is incorrect for iGPU frame buffers.  The framebuffer is defined by AAPL,ig-platform-id, which in this case is 3e9b0007.   The definition of framebuffer 3e9b0007 (shown here) is:

ID: 3E9B0007, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00801302
TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes)
Model name: Intel UHD Graphics 630
Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP
[3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x000003C7 - ConnectorDP
01050900 00040000 C7030000
02040A00 00040000 C7030000
03060800 00040000 C7030000

If a framebuffer property is not specified in the config.plist DeviceProperties, it remains as specified in the framebuffer definition.  For example, the con0 index defined for framebuffer 3e9b0007 is 1.  If DeviceProperties do not specify framebuffer-con0-index, it remains 1.  It is not necessary to re-define DeviceProperties that are already specified in the framebuffer definition, unless those properties are to be changed.  Note that WEG will auto-correct DP->HDMI connections for digital sound unless property "disable-hdmi-patches = 1" is specified.

 

If a specification does state what you described, it is wrong.

 

 

4 hours ago, Asural said:

There are some questions, such as "Why does it work fine on the Sequoia but not on the Tahoe?" and "Why does it work fine on the iMac19,2 but not on the Macmini8,1?", but it seems that WEG has a solution.
 

 

With config.plist here (config-test1.plist), the display behavior is the same in Sequoia and Tahoe.  As far as I know, we have not yet tested SMBIOS models MacMini8,1 and iMac19,2.  I think that testing MacMini8,1 is a good idea, since macMini8,1 has only Intel iGPU (no dGPU).  Note that testing SMBIOS MacMini8,1 may require disabling AGDC (DeviceProperty disable-agdc=1) and for Tahoe, will require boot-arg -no_compat_check)

 

6 hours ago, Asural said:

@fermento I re-read the thread and there doesn't seem to be any mention of connecting a cable from the DP socket on the Gigabyte Z490 to the M27Q, is it a DP to DP connection?

 

See this table.  cable is DP -> DP.  

 

6 hours ago, verdazil said:

On Z490 VISION G rev 1.1, HDMI via UHD630 may be effectively non-functional under macOS, while working normally in Windows and Linux.

 

I thought that fermento did test after adding lspcon properties, but the test results were the same as without the lspcon properties.  I don't know enough about lspcon to say whether that would cause the behavior fermento is observing.  Currently, with the config.plist here (config-test1.plist), displays flicker for a while during boot as shown in this video and then both displays work.  Both displays sleep and wake properly.  The behavior is the same in Sequoia and Tahoe.  @fermento, please correct me if anything that I'm stating is incorrect.

Edited by deeveedee
  • Like 1

@Asural I'm sorry, but I don't understand what you are saying.  framebuffer-con1-busid is not specified in config-test2-corrected.plist.  Can you please explain again?  Thank you.

  • Like 1
1 hour ago, deeveedee said:

@Asural I'm sorry, but I don't understand what you are saying.  framebuffer-con1-busid is not specified in config-test2-corrected.plist.  Can you please explain again?  Thank you.

I think the purpose of config-test2-corrected.plist is to reverse the settings of con2 and con3 in config-test1.plist.
Since framebuffer-con1-busid is not set in config-test2-corrected.plist, the setting value of 3E9B0007 remains as 4, but shouldn't it be set to 1, the con3 setting value in config-test1.plist?
 

  • Like 1
  • Thanks 1

@Asural I think I understand what you mean - sorry I didn't understand the first time.  Yes - I was only trying to restore the original settings for con1 and con2 index and pipe.  We did also test with setting framebuffer-con1-busid = 1 (not shown in this thread), but that did not change the need to swap con1 and con2.

 

EDIT: @Asural is the attached config.plist what you mean?

config-test1-3.plist.zip

Edited by deeveedee
  • Like 2

Hey, thanks all for the feedback. I was planing to try with SMBIOS for MacMini8,1 next. Do you agree?

 

Actually, I tried just replacing the Generic on PlatformInfo but I'm not able to boot. Is that the correct way to change the SMBIOS?

IMG_2241.jpg

Edited by fermento
Fix typo

@fermento With SMBIOS MacMini8,1, you need to add boot-arg -no_compat_check to boot Tahoe.  You can either add the boot-arg or test with Sequoia. If you're still stuck, please post your updated config.plist for review.  You will also need to add boot-arg igfxagdc=0 to enable multiple displays on macMini8,1.

50 minutes ago, fermento said:

Hey, thanks all for the feedback. I was planing to try with SMBIOS for MacMini8,1 next. Do you agree?

 

Actually, I tried just replacing the Generic on PlatformInfo but I'm not able to boot. Is that the correct way to change the SMBIOS?

I believe the SMBIOS=Macmini8,1 setting is directed at me; it's not supported on the Tahoe.
Please try swapping the con1 and con2 settings using the revised and attached config-test1-3.plist to see if that resolves the issue.

 

Also, could you attach an IORegistryExplorer file with a stable display?
I can't open the ioreg file someone else attached with my IORegistryExplorer 2.1, but I'm sure someone who can open it will be able to tell me the connection status.
 

3 hours ago, deeveedee said:

@fermento With SMBIOS MacMini8,1, you need to add boot-arg -no_compat_check to boot Tahoe.  You can either add the boot-arg or test with Sequoia. If you're still stuck, please post your updated config.plist for review.  You will also need to add boot-arg igfxagdc=0 to enable multiple displays on macMini8,1.

 

macOS Tahoe booted but Dell display turns off on boot.

@fermento if I understand your test, that's actually good news.  It means that the graphics behavior did change with the SMBIOS change.  Please post the config.plist that you used to test SMBIOS MacMini8,1.  Thank you.  Also, please test config-test1-3.plist from here as recommended by Asural.  Thank you.

@fermento Those test results sound suspicious.  This may sound strange, but I have found that graphics DeviceProperties may need to be tested multiple times before drawing any conclusions.  If you don't mind, please test the following ard report results:

 

  • With config-test1-3.plist, please reboot three times.  Between each boot, clear NVRAM (from the Open Core menu).  After the third reboot, what are the test results?
  • With macmini-config-test1.plist, please reboot three times.  Between each boot, clear NVRAM (from the Open Core menu).  After the third reboot, what are the test results?

 

Your test results may be no different from what you observed before, but I want to make sure.  Thank you.

@fermento I just reviewed your Mac mini-config-test1.plist and am confused.  I think it would be better to start with your working config.plist (config-test1.plist from here) and change only the SMBIOS Model to MacMini8,1.   I apologize if I gave unclear suggestions.

 

EDIT: Now I see what you tested.  Again, my apologies for the confusion.  You were testing config-test1-3.plist from here with the MacMini8,1 SMBIOS.  Testing config-test1-3.plist was a separate suggestion from changing the SMBIOS.  Please test config.plist (config-test1.plist from here) with SMBIOS MacMini8,1.

 

Thank you.

 

EDIT2:   Just to be clear for everyone following this: specifying "framebuffer-con1-busid = 1" does not work.

Edited by deeveedee

Tests with config-test1-3.plist

  1. Dell display turns off during boot
  2. Dell display turns off during boot
  3. Dell display turns off during boot

Tests with macmini-config-test1.plist

 

  1. Dell display turns off during boot
  2. Dell display turns off during boot
  3. Dell display turns off during boot

 

Cleared NVRAM on each iteration

10 minutes ago, deeveedee said:

@fermento I just reviewed your Mac mini-config-test1.plist and am confused.  I think it would be better to start with your working config.plist (config-test1.plist from here) and change only the SMBIOS Model to MacMini8,1.   I apologize if I gave unclear suggestions.

 

EDIT: Now I see what you tested.  Again, my apologies for the confusion.  You were testing config-test1-3.plist from here with the MacMini8,1 SMBIOS.  Testing config-test1-3.plist was a separate suggestion from changing the SMBIOS.  Please test config.plist (config-test1.plist from here) with SMBIOS MacMini8,1.

 

Thank you.

 

EDIT2:   Just to be clear for everyone following this: specifying "framebuffer-con1-busid = 1" does not work.

 

I just saw this, give me a few minutes, I will test config-test1.plist with smbios change

  • Thanks 1

Tests with config-test1-macmini.plist

  1. Displays flickering during initialization
  2. Displays flickering during initialization
  3. Displays flickering during initialization

 

I cleared NVRAM on each iteration.

 

So, dual displays, both displays turns on after lock screen turns off. Only problem, flickering for a minute or more during start.

Edited by fermento
  • Thanks 1

@fermento Thank you for patiently testing.  Your latest test with SMBIOS MacMini8,1 confirms that the display behavior does not change.  I have some other ideas, but I'd like to think about them and do a little research so that I don't waste your time.

 

Hopefully others will have suggestions, too.  Don't give up.  You did a great job.

  • Like 1

@fermento if you still have the patience to test, I'd like to try to understand why swapping the con1 and con2 properties "fixes" your displays - especially since now your displays appear to be connected on con0 and con1.  It feels like we're chasing a moving target (not unusual for framebuffer patching).  Would you mind testing the attached config.plists (sorry, there are a lot of them)? They are based on config-test1.plist with the following changes:

 

The changes listed below are changes from the config-test1.plist baseline.  Each new config.plist starts with config-test1.plist and has only the changes listed.

 

config-test1-4.plist

  • do not swap con1 and con2 indices (swap only their pipes)
  • do not change con2 busid

config-test1-5.plist

  • do not swap con1 and con2 pipes (swap only their indices)
  • do not change con2 busid

config-test1-6.plist

  • do not swap con1 and con2 indices and pipes (still change con2 busid)

config-test1-7.plist

  • change con2 type to HDMI
  • Not sure why I added this test - just curious

config-test1-8.plist

  • Enable lspcon on all ports
  • I don't have experience with lspcon.  I also still don't know which logical connector conX is the HDMI port.  Since I don't know where to start with lspcon, this config.plist enables it on all logical connectors con0, con1 and con2.
  • @verdazil Since you know more about lspcon, you may want to suggest a lspcon test strategy.

 

config-test1-4.plist.zip config-test1-5.plist.zip config-test1-6.plist.zip config-test1-7.plist.zip config-test1-8.plist.zip

Edited by deeveedee
6 hours ago, fermento said:

With config-test1-3.plist Dell displays turns off on boot

I think reversing the settings for con2 and con3 should basically solve the problem.

 

I tried this with a SMBIOS =Macmini8,1, which was experiencing severe screen flickering.
1. Only the con0 monitor was displayed during startup.
2. When the startup bar switched, the con1 monitor glowed black.
3. The desktop appeared on con0.
4. The con0 display went black 3-4 seconds later.
5. The desktop appeared on con0 3-4 seconds after it went black.
6. The desktop appeared on con1 shortly after it appeared on con0.
7. The screen display stabilized.
The problem of con0 and con1 alternating on and off was resolved.

 

In my case, setting SMBIOS to iMac19,X stabilized the display once the desktop appeared, but the problem was with Power Management.
If you don't use the appropriate SMBIOS for your CPU (GPU/iGPU), your CPU temperature will jump to 80°C when idle, making it unattractive to turn on the power in the summer.
This problem doesn't occur if you use a dGPU and configure AGPM, but since the Tahoe doesn't have an internal dGPU, I was trying to figure out how to fix it with an iGPU.

I'm keeping an eye on this thread in case a better solution is found.
 

@deeveedee

 

4 - no boot

5 - flickering

6 - no boot

7 - flickering

8 - flickering

 

I'm starting to lose hope 😩

config-test1-4.jpg

config-test1-6.jpg

 

@Asural

 

47 minutes ago, Asural said:

I think reversing the settings for con2 and con3 should basically solve the problem.

 

I tried this with a SMBIOS =Macmini8,1, which was experiencing severe screen flickering.
1. Only the con0 monitor was displayed during startup.
2. When the startup bar switched, the con1 monitor glowed black.
3. The desktop appeared on con0.
4. The con0 display went black 3-4 seconds later.
5. The desktop appeared on con0 3-4 seconds after it went black.
6. The desktop appeared on con1 shortly after it appeared on con0.
7. The screen display stabilized.
The problem of con0 and con1 alternating on and off was resolved.

 

In my case, setting SMBIOS to iMac19,X stabilized the display once the desktop appeared, but the problem was with Power Management.
If you don't use the appropriate SMBIOS for your CPU (GPU/iGPU), your CPU temperature will jump to 80°C when idle, making it unattractive to turn on the power in the summer.
This problem doesn't occur if you use a dGPU and configure AGPM, but since the Tahoe doesn't have an internal dGPU, I was trying to figure out how to fix it with an iGPU.

I'm keeping an eye on this thread in case a better solution is found.
 

 

So, which are your changes proposals? I can test them.

Edited by fermento
  • Thanks 1
39 minutes ago, fermento said:

@Asural

 

So, which are your changes proposals? I can test them.

What! config-test1-3.plist isn't working?

 

Based on your post in the thread and the attached ioleg information, I've created PciRoot(0x0)/Pci(0x2,0x0) information with con1 and con2 swapped. Replace it with the test config.plot and try it out, being careful not to destroy the working EFI.
 

MOD_fermento.plist

  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...