Tahoe - Intel UDH 630 - dual monitor problems

[verdazil]

7 hours ago, deeveedee said:

@verdazil Since you know more about lspcon, you may want to suggest a lspcon test strategy.

Determining whether LSPCON support is required is simple. If the framebuffer specification specifies the required connector as having an DP output, but the motherboard has an HDMI port, then enabling LSPCON support is mandatory.

Depending on the parameters of the monitor and video cable, the settings are selected in accordance with the manual:

https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#lspcon-driver-support-to-enable-displayport-to-hdmi-20-output-on-igpu

 

P. S. Your strategy of trying possible combinations of settings is the only correct one. No other method produces reliable results, including the vaunted Hackintool.

[deeveedee]

@fermento Based on your test results:

• 4 - no boot: do not swap con1 and con2 indices (swap only their pipes), do not change con2 busid

• 5 - flickering: do not swap con1 and con2 pipes (swap only their indices), do not change con2 busid

• 6 - no boot: do not swap con1 and con2 indices and pipes (still change con2 busid)

• 7 - flickering: change con2 type to HDMI

• 8 - flickering: Enable lspcon on all ports

I think we can draw the following conclusions:

• Changing the busid of con2 is not necessary
• swapping the pipes of con1 and con2 is not necessary
• configuring ports for lspcon is not necessary
• changing con2 type to HDMI is not necessary

I think this means that we can further simplify your config.plist DeviceProperties (which may help to get us closer to a solution).  The attached config.plist named config-test1-9.plist is simplified to reflect these observations.

 

The attached config.plists named config-test1-10.plist, config-test1-11.plist, config-test1-12.plist and config-test1-13.plist may help to isolate the reason why swapping the con1 and con2 indices is necessary.

 

Please test the attached config.plists and report results.  You're doing great!   Thank you.

 

EDIT: @verdazil We are in agreement.  I only use Hackintool to confirm the logical connector (con0, con1, con2) connections to displays as I have done in this thread. I don't use Hackintool for any other framebuffer patching operations (although it does have plenty of other useful tools which is why I'm a Hackintool donator).  As you have pointed out, we can inspect IORegistry to determine the same.  This shouldn't be a surprise, since Hackintool gets its information from IOReg.  When guiding others through this framebuffer patching process, I find it easier to instruct them to use Hackintool for confirming display connections than guiding them through IOReg.  It's a personal preference.

 

The attached config.plists are as follows (all use config-test1-5 as the starting baseline unless otherwise stated):

Spoiler

• config-test1-9.plist: do not swap con1 and con2 pipes, do not change con2 busid
• config-test1-10.plist: disable con2 (still assign con1 index = 3)
• config-test1-11.plist: change framebuffer port count to 2 (still assign con1 index = 3)
• config-test1-12.plist: change framebuffer port count to 2, leave con1 index = 2 (unchanged)
• config-test1-13.plist: disable con2, leave con1 index = 2 (unchanged)
• config-test1-14.plist: start with config-test1-8.plist, change framebuffer-conX-preferred-lspcon-mode to 0.  This test should be the final confirmation that lspcon is not relevant to this hack.

 

 

EDIT2: @fermento You are really doing very well.  I appreciate your patience.  I don't give up very easily (maybe you've noticed).  Don't feel pressured to continue.  If you say "stop," we'll stop.  Unfortunately, framebuffer patching can be more of an art than a science (maybe neither).  It's frequently a lot of trial and error in my experience.  I have stories that are more tedious than this hack if that's any consolation. 

 

config-test1-9.plist.zip config-test1-10.plist.zip config-test1-11.plist.zip config-test1-12.plist.zip config-test1-13.plist.zip config-test1-14.plist.zip

Edited December 21, 2025 by deeveedee
Fixed typos

[fermento]

@Asural

• MOD_fermento.plist -> Dell display turns off during boot

 

@deeveedee

• config-test1-9.plist -> Both displays working, flickering during start, both displays turn on after lock screen
• config-test1-10.plist -> Both displays working, flickering during start, both displays turn on after lock screen
• config-test1-11.plist -> Both displays working, flickering during start, both displays turn on after lock screen
• config-test1-12.plist -> macOS does not boot, picture attached
• config-test1-13.plist -> macOS does not boot, picture attached
• config-test1-14.plist -> Both displays working, flickering during start, both displays turn on after lock screen

 

Reset NVRAM on each iteration

 

Why macOS needs to turn off the second display during boot? On Windows, for example, this does NOT happen.

 

If you don't give up yet, neither will I 🤓

 

Edited December 22, 2025 by fermento

[deeveedee]

@fermento Thank you for testing!  I have two more tests that I'd like you to perform below (which I describe after I explain your test results).

 

Your test results are as follows:

• config-test1-9.plist: both displays working, flickering during start, both displays work after Lock Screen (do not swap con1 and con2 pipes, do not change con2 busid)
• config-test1-10.plist: both displays working, flickering during start, both displays work after Lock Screen (disable con2 (still assign con1 index = 3) )
• config-test1-11.plist: both displays working, flickering during start, both displays work after Lock Screen (change framebuffer port count to 2 (still assign con1 index = 3) )
• config-test1-12.plist: doesn't boot (change framebuffer port count to 2, leave con1 index = 2 (unchanged) )
• config-test1-13.plist: doesn't boot (disable con2, leave con1 index = 2 (unchanged) )
• config-test1-14.plist: both displays working, flickering during start, both displays work after Lock Screen  (start with config-test1-8.plist, change framebuffer-conX-preferred-lspcon-mode to 0.  This test should be the final confirmation that lspcon is not relevant to this hack )

 

-9 is not a surprising result, since this is essentially a repeat of test -5.  Test -14 is not surprising, since we already suspected that lspcon was not relevant to this hack.  What is very interesting is that both displays "work" simply by changing con1 index to 3 while eliminating con2.  I think that the test case that we want to focus on for further testing is test -11 (a simpler version of -10) which reduces the port count to 2.  

 

config-test1-11.plist configures your graphics ports as follows:

connector	index	type	display

con0		1	DP	DP (Gigabyte)
con1		3	HDMI	DVI-D (Dell)

Port Count: 2

 

Now that we have these very simple DeviceProperties that reliably produce "working" displays, we can focus on fixing the flickering/delay at boot.  I need to think about this before I recommend next steps and I invite others to offer suggestions.  I have guesses that I don't want to state until I give this more thought.

 

Could you please test the following with config-test1-11.plist and report results:

• Disconnect the Gigabyte (DP) display and boot macOS.  Does macOS boot normally (without delay) or does the Dell display flicker?
• Disconnect the Dell (DVI-D) display and boot macOS.  Does macOS boot normally (without delay) or does the Gigabyte display flicker?

 

Thank you again for patiently testing.  This is fascinating to me, because I have never seen a case where frame patching required swapping connector indices.  I would never have guessed this as a necessary patching strategy.  If anyone know how this index swapping was determined, I'd love to hear the explanation and I'd love to congratulate the person who thought of this.  Very interesting.

 

EDIT: @fermento  I just noticed that you reported test results for MOD_fermento.plist -> Dell display turns off during boot.  What do you mean by "Dell display turns off during boot"?  Does the display turn on after booting (before login screen).   Is macOS booting normally except for the fact that the Dell display is off during boot?  Which config.plist produces results that you prefer: MOD_fermento.plist or config-test1-11.plist?  Note that it is normal during macOS boot for one display to be "black" while the other display shows boot progress.  Thank you.

Edited December 22, 2025 by deeveedee

[Asural]

3 hours ago, fermento said:

 

• MOD_fermento.plist -> Dell display turns off during boot

If you say "The Dell monitor won't display until the desktop appears on the M27Q monitor," then the display behavior is correct and is the same on an actual Mac.
Just to confirm, you're running the display test with SMBIOS = iMac20,2, right?
 

Regarding the z490 index 2, it seems to be Thunderbolt 3 (USB type-C), but it does not seem to be supported by WEG.
 

Edited December 22, 2025 by Asural

[Asural]

47 minutes ago, eSaF said:

@Asural I take it by your mirth response  you agree I am correct??!!

Yes, of course.
I should have checked to make sure everyone had their "auto-login" feature set.
I refrained from commenting because I remembered how many years it had been since I last heard of Startup Chime.

[Asural]

51 minutes ago, eSaF said:

Fresh from the world of Hackintosh, is it possible to turn off the Boot Chime on a real Mac?

I am loathed to start poking around this machine apart from installing a 2TB Drive from the 512MB within.

 

I did attempt to mount the EFI Partition (if there's such a thing) of the Drive but got a popup saying prohibited or to that effect.

As I declared, coming from the Hack world I am still feeling my way around the unfamiliar roads of a real Mac.

 

Cheers.

Off-topic...
Behind me is a MacPro3,1 that hasn't been turned on in years, and I plug in headphones when I don't want to hear the Boot Chime.
I don't know much about recent Macs, so I think you'd be better off asking a question on APPLE WORLD on Forums.
I don't have high hopes for Apple's future.
 

[deeveedee]

@eSaF Are you reporting "real Mac" observations for multiple displays as is the use case for this thread?

 

EDIT: In other words, what Asural is reporting is the behavior observed on a second display in a dual-display configuration.  Is that also what you are reporting?

Edited December 22, 2025 by deeveedee

[fermento]

11 hours ago, deeveedee said:

@fermento Thank you for testing!  I have two more tests that I'd like you to perform below (which I describe after I explain your test results).

 

Your test results are as follows:

• config-test1-9.plist: both displays working, flickering during start, both displays work after Lock Screen (do not swap con1 and con2 pipes, do not change con2 busid)
• config-test1-10.plist: both displays working, flickering during start, both displays work after Lock Screen (disable con2 (still assign con1 index = 3) )
• config-test1-11.plist: both displays working, flickering during start, both displays work after Lock Screen (change framebuffer port count to 2 (still assign con1 index = 3) )
• config-test1-12.plist: doesn't boot (change framebuffer port count to 2, leave con1 index = 2 (unchanged) )
• config-test1-13.plist: doesn't boot (disable con2, leave con1 index = 2 (unchanged) )
• config-test1-14.plist: both displays working, flickering during start, both displays work after Lock Screen  (start with config-test1-8.plist, change framebuffer-conX-preferred-lspcon-mode to 0.  This test should be the final confirmation that lspcon is not relevant to this hack )

 

-9 is not a surprising result, since this is essentially a repeat of test -5.  Test -14 is not surprising, since we already suspected that lspcon was not relevant to this hack.  What is very interesting is that both displays "work" simply by changing con1 index to 3 while eliminating con2.  I think that the test case that we want to focus on for further testing is test -11 (a simpler version of -10) which reduces the port count to 2.  

 

config-test1-11.plist configures your graphics ports as follows:

connector	index	type	display

con0		1	DP	DP (Gigabyte)
con1		3	HDMI	DVI-D (Dell)

Port Count: 2

 

Now that we have these very simple DeviceProperties that reliably produce "working" displays, we can focus on fixing the flickering/delay at boot.  I need to think about this before I recommend next steps and I invite others to offer suggestions.  I have guesses that I don't want to state until I give this more thought.

 

Could you please test the following with config-test1-11.plist and report results:

• Disconnect the Gigabyte (DP) display and boot macOS.  Does macOS boot normally (without delay) or does the Dell display flicker?
• Disconnect the Dell (DVI-D) display and boot macOS.  Does macOS boot normally (without delay) or does the Gigabyte display flicker?

 

Thank you again for patiently testing.  This is fascinating to me, because I have never seen a case where frame patching required swapping connector indices.  I would never have guessed this as a necessary patching strategy.  If anyone know how this index swapping was determined, I'd love to hear the explanation and I'd love to congratulate the person who thought of this.  Very interesting.

 

EDIT: @fermento  I just noticed that you reported test results for MOD_fermento.plist -> Dell display turns off during boot.  What do you mean by "Dell display turns off during boot"?  Does the display turn on after booting (before login screen).   Is macOS booting normally except for the fact that the Dell display is off during boot?  Which config.plist produces results that you prefer: MOD_fermento.plist or config-test1-11.plist?  Note that it is normal during macOS boot for one display to be "black" while the other display shows boot progress.  Thank you.

 

• Disconnect the Gigabyte (DP) display and boot macOS. The macOS booted normally and the display never flicker ✅
• Disconnect the Dell (DVI-D) display and boot macOS. The macOS booted normally and the display never flicker ✅

 

MOD_fermento.plist: The display turned off during boot and then remained like that, not dual displays.

 

I would like to add more context. During all the tests we did, we have only 3 possible results:

 

• The macOS does not boot
• The macOS boots and is usable but the Dell display turns off during the boot before reaching the login screen and never goes on again (only one display working)
• The macOS boots and is usable but the Dell display goes black for a while (without turns off) and then starts flickering (mostly the Dell but the Gigabyte displays also goes black and go back again for a moment at the end, not actual flickering but like if it is switching or something) until both stabilizes (two displays working)

 

One more information that could be useful and is kind of insane, when I boot only with Gigabyte display connected, once I'm logged in and macOS is fully functional, I plug the Dell displays, both goes black and almost instantly the come back both fully functional, without flickering 🤯 (two displays working)

Edited December 22, 2025 by fermento

[deeveedee]

@fermento the fact that you can boot normally with a single display connected is a very good clue.   Even more encouraging is that you can connect the second display after booting.  That's exactly what I hoped and this means that we should be able to fix this. 

 

Thank you for clarifying the "Dell Display turns off during boot."  This is not a working solution - I thought this was the case but just wanted to be sure.

 

I was reviewing your earlier posts and see that I was missing some of your posts (probably because your posts were delayed by moderator approval).  I'm very interested in your test here with "deeveedee.config.plist" which had displays connected on con0 and con2.  Can you please test the attached config-deeveedee-2.plist and config-deeveedee-3.plist and report the following results:

• Which connectors are in use (e.g., con0/con1 or con0/con2)?
• Do you still experience the delayed boot and flickering?
• Do both displays work after booting?
• Do both displays "wake" after lock screen?

Thank you.  Your recent test results are very encouraging.  I am very optimistic about finding a fully working solution.

 

The attached config.plists are based on deeveedee.config.plist from here with the changes as noted

Spoiler

• config-deeveedee-2.plist: Comment-out suspected unnecessary properties (lspcon, enable-hdmi20, framebuffer-conX-busid), add force-online=1 property
• config-deeveedee-3.plist: start with config-deeveedee-2.plist.  Comment-out con0 properties.

 

config-deeveedee-2.plist.zip config-deeveedee-3.plist.zip

Edited December 22, 2025 by deeveedee

[fermento]

@deeveedee

 

I was not able to boot with the latest 2 configs

[deeveedee]

@fermento Interesting - thank you for testing.  Could you please confirm that the deeveedee.config.plist that you posted here still boots macOS? Please also test attached deeveedee.config-2.plist and deeveedee.config-3.plist.  If any of them boots, please report your usual:

• Which connectors are in use (e.g., con0/con1 or con0/con2)?
• Do you still experience the delayed boot and flickering?
• Do both displays work after booting?
• Do both displays "wake" after lock screen?

Thank you.

 

The attached deeveedee.config-2.plist starts with deeveedee.config.plist and comments-out lspcon properties and enable-hdmi20 (leaving all pipe and busid properties).  It also adds force-online property.

 

The attached deeveedee.config-3.plist starts with deeveedee.config-2.plist and comments-out con0 properties.

 

deeveedee.config-2.plist.zip deeveedee.config-3.plist.zip

Edited December 22, 2025 by deeveedee

[Asural]

@fermento I was only looking at the information in DeviceProperties, and it seems that WEG supports USB Type-C as a DP.
Please add -igfxtypec to boot-arg and try the attached DeviceProperties file with 3Port defined.
 

igfxtypec.plist

[deeveedee]

@Asural Your suggestion to try boot-arg -igfxtypec is interesting.  I haven't seen anything about this in any WhateverGreen documentation.  I only found the boot-arg by searching Whatevergreen source code in WhateverGreen/kern_igfx.cpp.  

 

void IGFX::TypeCCheckDisabler::processKernel(KernelPatcher &patcher, DeviceInfo *info) {
        enabled &= !checkKernelArgument("-igfxtypec");
}

 

How did you learn about the boot-arg?  Do you have any documentation that explains it?  Thank you.

 

EDIT: Based on inspection of the WhateverGreen.kext source, it appears that adding boot-arg -igfxtypec disables TypeCCheckDisabler.  I didn't look at source to learn more.  Note that in my experience, WhateverGreen patches TypeC-connected video in the same way that it patches other framebuffer connectors (without the addition of boot-arg -igfxtypec).

Edited December 23, 2025 by deeveedee

[fermento]

21 hours ago, deeveedee said:

@fermento Interesting - thank you for testing.  Could you please confirm that the deeveedee.config.plist that you posted here still boots macOS? Please also test attached deeveedee.config-2.plist and deeveedee.config-3.plist.  If any of them boots, please report your usual:

• Which connectors are in use (e.g., con0/con1 or con0/con2)?
• Do you still experience the delayed boot and flickering?
• Do both displays work after booting?
• Do both displays "wake" after lock screen?

Thank you.

 

The attached deeveedee.config-2.plist starts with deeveedee.config.plist and comments-out lspcon properties and enable-hdmi20 (leaving all pipe and busid properties).  It also adds force-online property.

 

The attached deeveedee.config-3.plist starts with deeveedee.config-2.plist and comments-out con0 properties.

 

deeveedee.config-2.plist.zip 6.27 kB · 3 downloads deeveedee.config-3.plist.zip 6.27 kB · 2 downloads

 

I experienced same results on both configs.

 

- Delay and flickering during boot

- Both displays work after booting

- Both displays wake after lock screen

 

I forgot to see the connectors, I will do it later

 

@Asural

The second display (Dell) turns off only one display output

[deeveedee]

36 minutes ago, fermento said:

I forgot to see the connectors, I will do it later

 

the purpose of the tests was to find the connectors, so please report when you can.  

 

The test results are as I expected, so no surprises.

 

Thank you!

 

EDIT: Attached is a new config.plist that should be identical to the previously tested deeveedee.config-3.plist.  It is the same config.plist with the commented-out lines removed.  Please test this, because it will be my baseline for some other changes and I want to make sure it is "working."  Please report connector indices with your test results.  Thank you!

deeveedee.config-3-2.plist.zip

Edited December 23, 2025 by deeveedee

[fermento]

Sorry, I forgot to make a note of the connectors. I just arrived in town to spend Christmas, so I won't be near the computer until Saturday. As soon as I get back, I'll do the remaining tests and update the thread.

 

Thank you all very much for your help. We'll talk in a few days.

Edited December 24, 2025 by fermento

[deeveedee]

@fermento No rush.  I'm going to be traveling to visit family for Christmas, so it's most likely that I'll be looking at this again next week. There are many others here who can help as well.  Merry Christmas!  Buon Natale!

[Asural]

17 hours ago, deeveedee said:

 

How did you learn about the boot-arg?  Do you have any documentation that explains it?  Thank you.

 I thought the USB Type-C was interfering with the display, and assumed WEG had done something about it.

A web search for "WEG Type-C" turned up -igfxtypec here, but I couldn't find any details.

 

By the way, the delay and flickering during startup when using multiple monitors with a 10th-generation UHD630 CPU seems to occur with busid = <04000000>,

unrelated to USB Type-C.

 

@fermento   I've attached the corrected file for busid = <02000000>, so please test the display after the Christmas holidays are over.

 

 

I hope you all have a wonderful Christmas!

igfxtypec2.plist

[fermento]

@deeveedee

Here I attach the screenshots for the connectors. I took one with the 2 displays and other with the Dell display disconnected so you can confirm which connecter is which display.

 

@Asural

I tried igfxtypec2 config but the Dell display turns off during boot, only one display working

[Asural]

3 hours ago, fermento said:

 

I tried igfxtypec2 config but the Dell display turns off during boot, only one display working

 Please try changing framebuffer-con2-busid = <04000000> to <01000000> and <02000000> in deeveedee.config-3-2.plist.
 

[Asural]

On 12/16/2025 at 3:38 AM, Max.1974 said:

 

Hi my dear. After months and weeks of work, my final device-properties configuration is working perfectly. USB-C, Thunderbolt, and HDMI video output are all working on my Lenovo T14 ports. I believe this configuration works because, after studying it many times and running several tests, everything is now functioning correctly. 

😃👊🏻

 

I also remember that the patches highlighted in blue in the left column must be followed, not the numbers of each iGPU. The bus ID sequence and port mapping, as well as the HDMI model (DVS / DP etc), must be respected. For each configuration, we need to know our own hardware details

Currently it only seems to work with index=3 busId = 4, but I plan to configure LSPCON.
If it's still not stable, I'd like to try your suggestion to enable USB Type-C. Are there any settings other than USBMap.kext or similar that are required to enable Type-C on the iGPU?
 

ADD:
Isn't -igfxtypec needed in boot-arg?
In your configuration, complete-modeset-framebuffsers = 0x010000000000 = <0000000000000001>, doesn't this mean that complete-modeset is disabled?
 

Edited December 29, 2025 by Asural

[deeveedee]

It appears that we are revisiting settings that have already been tested and determined to be unnecessary - specifically

• lspcon
• -igfxtypec

 

Why are we asking for these to be tested again?

[Max.1974]

I believe that the only settings he needs to test are the Pipe and the Bus ID, and I am not asking him to redo anything—only leaving my hardware as a reference. I have no intention whatsoever of guessing without knowing his IOReg. Although, in this context, the IOReg can produce misleading results due to poorly configured ports. 

 

Unfortunately, in the Hackintosh scenario, two monitors don’t always work properly. I managed to make it work on my wife’s desktop, but it took a lot of effort.

[Thebes Knossos]

UHD 630 + double screen seems a complex subject, I have problems too described in this topic: https://www.insanelymac.com/forum/topic/361471-problem-with-dual-monitors/