Tahoe - Intel UDH 630 - dual monitor problems

[Asural]

8 hours ago, deeveedee said:

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?

For LSPCON, the only file downloaded was one with the settings commented out.
I wanted to check how it works when the screen doesn't display when using HDMI.
When I used it, it took 7 seconds for the screen to change and 3 seconds for it to go dark and then display, but the delay was just 15 seconds for the change and 10 seconds for it to go dark and then display.

As for -igfxtypec, I'm wondering if the USB Type-C is interfering with the display.
I think the problem should be resolved not just by adding it to boot-arg, but by making the settings required for USB Type-C operation and checking their operation.
 

3 hours ago, Max.1974 said:

 

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.

Thank you very much for the explanation.
Regarding complete-modeset, I tried complete-modeset-framebuffsers = <0000000000000001> and <03020100> on my HP400G5SFF, but there was no change.
Perhaps it's a setting for SkyLake?
 

16 minutes ago, Thebes Knossos said:

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/

I'll read the thread later.
The only solution I know of for this situation is this post, and the solution report is below.
 

[Asural]

I've attached the DeviceProperties file I planned to test.

 

I also tested complete-modeset-framebuffsers with <0000000000000001>.
As for framebuffer-con2-preferred-lspcon-mode, I believe the motherboard uses HDMI 2.0, but if it's a monitor setting, I'll also need to test with <00000000>.
 

LSPCON_1.plist

[deeveedee]

In my experience, the key to a working multi-monitor hack is patience with exhaustive testing of candidate framebuffers (AAPL,ig-platform-id) while varying busid.  Testing different framebuffers may be required because FrameBuffer Flags vary and are important to multi-display operation.  Also, the connector flags are important.  If mobile framebuffers are tested on a desktop, then the connector indices need to be changed from 0,1,2 -> 1,2,3.

 

The reason that we see threads in this forum that have not achieved working multi-display configurations is that it is very hard to test the numerous permutations and combinations of framebufers, busids, connector flags while documenting all test results.  The other challenge is that it is very hard to test the numerous permutations and combinations with lots of "cooks in the kitchen."

 

All of my Intel iGPU hacks have flawless multi-monitor operation which sometimes required many hours of tedious experimentation.  

 

We have already tested lpscon with preferred modes 0 and 1.   We have someone here (fermento) who has the patience and persistence to experiment as needed.  Let's not waste his time.

 

[Max.1974]

7 hours ago, Asural said:

Thank you very much for the explanation.
Regarding complete-modeset, I tried complete-modeset-framebuffsers = <0000000000000001> and <03020100> on my HP400G5SFF, but there was no change.
Perhaps it's a setting for SkyLake?

Yes, the same procedure works on the HD 620 and also on the UHDs, so Skylake is the most functional among them all. There are issues with the Lilu kext, but the developer has already done far more than Microsoft did with Windows on the same machine  

Another tip I can give is to look for the same plist on GitHub from candidate users who did things differently in their EFIs; that’s how I managed to reach a solid base for my hardware—by researching other EFIs on GitHub. 

Like @miliuco github page:

 

https://github.com/perez987/Intel-UHD-630-on-macOS 

[deeveedee]

EDIT: For those following this, I noticed after testing was complete that I misspelled one of the DeviceProperties which may invalidate testing of config-test2-1.plist.  See here.

 

@fermento If it's any consolation, I needed to perform the same tedious framebuffer patching experimentation for my hack documented in this thread.  When I created that thread in May 2020, all documentation at that time stated that graphics adapters (e.g., HDMI -> DVI-D, DP->HDMI and DP->DVI-D) were not supported.  I stubbornly followed a brute-force testing methodology until I found a working solution.  The only way that I found for my DP->DVI-D adapters to work was to use a mobile framebuffer.  Maybe the same is true for your HDMI->DVI-D adapter.

 

The framebuffer that you are currently using (3e9b0007) is a desktop framebuffer as documented here.  Attached is a config.plist that uses mobile framebuffer 3e920000.  Note that in order to use the mobile framebuffer for a desktop, we need to change the connector indices from 0,1,2 -> 1,2,3, we need to change the connector types, we need to change the connector flags and we need to change the busid of con0.  You can imagine just how much trial and error experimentation was required to find this solution, so be glad you're spared that agony

 

Please test the attached config.plist.  The attached config.plist is based on config-1-9.plist, with changes needed for mobile framebuffer 3e920000.   If it "works" but still flickers, try the following 3-connector mobile framebuffers by changing only AAPL,ig-platform-id in the attached config.plist:

• 3EA50009 (specified as <0900A53e> in config.plist DeviceProperties)
• 3E920009 (<0900923e>)
• 3E9B0009 (<09009B3e>)
• 3EA50000 (<0000A53e>)
• 3E000000 (<0000003e>)
• 3E9B0000 (<00009b3e>)
• 3EA50004 (<0400A53e>)
• 3EA50005 (<0500A53e>)
• 3EA60005 (<0500A63e>)

 

These 3-connector framebuffers are the mobile Coffee Lake and Comet Lake framebuffers documented here.

 

If your first test with mobile framebuffer 3e920000 produces any black screens or does not boot, do not test the other framebuffers.  Just report your results. We would need to first fix the config for framebuffer 3e920000 before testing other framebuffers.  If any tests do not boot, you don't need to post your screenshots.

 

Thanks again for your patience.

 

EDIT: Note that years after I found the working frame buffer patching for my DP->DVI-D adapters here, I learned that instead of changing the framebuffer (AAPL,ig-platform-id) and the associated indices, etc., that I could simply change the frame buffer flags.  It is the change in frame buffer flags (resulting from the changed frame buffer) that produced a working result.  I am not proposing experimentation with frame buffer flags at this time, but others may wish to experiment for themselves.

 

config-test2-1.plist.zip

Edited January 1 by deeveedee
Added framebuffer-con0-busid to config-test2-1.plist

[fermento]

On 12/29/2025 at 1:13 AM, Asural said:

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

 

I tested this with the two different values, none of them gave me output on any of the displays, I was not able to reach the login screen.

 

@deeveedee

 

Hi! I tested config-test2-1.plist and I got no output on the Dell display. Only one display working (Gigabyte)

 

@Max.1974

 

I don't know exactly what do you propose me to try. Can you be more explicit please? Thanks

[Max.1974]

Today I can’t do it anymore because it’s already very late here in Brazil, and tomorrow again I’ll be receiving family members, so both the day and the night will be very busy. Later I’ll ask you about your complete hardware, focusing only on the processor and its HDMI, DP, USB-C inputs, etc. We are always trying to guess the Bus IDs or Pipe and flags, but we need to start over from scratch — one thing at a time. If possible, we’ll try, but your old cables may be a problem, as well as your connectors. Talk to you later.👊🏻😎

[Asural]

3 hours ago, fermento said:

 

I tested this with the two different values, none of them gave me output on any of the displays, I was not able to reach the login screen.

 

I don't know exactly what do you propose me to try. Can you be more explicit please? Thanks

What I was hoping for was "only the Dell display is blank"...
I searched for the Gigabyte Z490 BIOS, but only found the ASUS one. It seems there's a setting to enable multi-monitor support for the iGPU,

but does the Gigabyte BIOS have the same setting?

 

I think @Max.1974 has answered my USB Type-C question.
 

53 minutes ago, Max.1974 said:

Today I can’t do it anymore because it’s already very late here in Brazil, and tomorrow again I’ll be receiving family members, so both the day and the night will be very busy. Later I’ll ask you about your complete hardware, focusing only on the processor and its HDMI, DP, USB-C inputs, etc. We are always trying to guess the Bus IDs or Pipe and flags, but we need to start over from scratch — one thing at a time. If possible, we’ll try, but your old cables may be a problem, as well as your connectors. Talk to you later.👊🏻😎

It was my suggestion to enable USB Type-C because it's interfering, but
the monitor flickering issue occurs even on motherboards that have an HDMI connector, even without USB Type-C, so I don't think it will have any effect.
I don't have a USB Type-C test environment myself, so I think that will be a topic for another thread.

 

Thank you for taking the time to explain.
 

ADD: The New Year is a very busy time in Japan too, so I wish everyone a happy new year.

Edited December 31, 2025 by Asural

[deeveedee]

EDIT: For those following this, I noticed after testing was complete that I misspelled one of the DeviceProperties which may invalidate testing of config-test-2-2.plist, config-test-3-1.plist, config-test3-2.plist.  See here.

 

@fermento Thank you for testing.  I am hoping to convert one of the "working"configs (config-test1-9.plist using con0/con1, config-test1-11.plist using con0/con1  or deeveedee.config-3-2.plist using con0/con2) to a "working" mobile framebuffer.

 

Attached are revised config.plists with changes necessary to convert to a mobile framebuffer.  Please test and report results.  You don't need to post screenshots if the hack doesn't boot.  Please report connectors (con0/con1/con2) for each test.  Thank you.

 

The attached config.plists are as follows:

• config-test2-2.plist: config-test2-1.plist with con1 (Dell display) busid changed to 2
• config-test3-1.plist: config-test1-11.plist converted to mobile framebuffer
• config-test3-2.plist: config-test3-1.plist with con1 (Dell Display) busid changed to 2
• deeveedee-config-4-1.plist: deeveedee-config-3-2.plist converted to mobile framebuffer

 

EDIT: Other things to test (please ignore these for now)

• -disablegfxfirmware
• igfxagdc=0
• igfxfw=2
• -igfxhdmidivs

 

config-test2-2.plist.zip config-test3-1.plist.zip config-test3-2.plist.zip deeveedee.config-4-1.plist.zip

Edited January 1 by deeveedee

[Max.1974]

8 hours ago, Asural said:

What I was hoping for was "only the Dell display is blank"...
I searched for the Gigabyte Z490 BIOS, but only found the ASUS one. It seems there's a setting to enable multi-monitor support for the iGPU,

but does the Gigabyte BIOS have the same setting?

 

I think @Max.1974 has answered my USB Type-C question.
 

It was my suggestion to enable USB Type-C because it's interfering, but
the monitor flickering issue occurs even on motherboards that have an HDMI connector, even without USB Type-C, so I don't think it will have any effect.
I don't have a USB Type-C test environment myself, so I think that will be a topic for another thread.

 

Thank you for taking the time to explain.
 

ADD: The New Year is a very busy time in Japan too, so I wish everyone a happy new year.

 

@Asural Tks !!! HAPPY NEW YEAR!!  

 

 

@fermento 

 

Is it possible for you to extract an AIDA64 report and post it here?

If possible, also try using the Hardware Sniffer from OpenCore Simplify to see which kind of Device Properties the app recognizes.

 

AIDA64 report only if you can do it on Windows

 

And please, post here the EFI that OpenCore Simplify prepared; it can be only the plist and the SSDTs

[fermento]

@deeveedee

 

• With config-test2-2, config-test3-1 and config-test3-2 the Dell displays turns off during boot, only one display available
• With deeveedee.config-4-1 both displays work but I have the flickering situation

 

@Max.1974

 

I uploaded aida64 report and hardware-sniffer report. When I try to load the report on OpCore-Simplify I'm getting the following error:

 

"Root - Missing required key 'BIOS'"

 

Also, for more context, both monitor work without any issues on Windows and Linux, so there is no problem on the HDMI to DVI adapter neither the HDMI cable. Neither the display because I also tasted with a Tv connected directly to the HDMI and same flickering happening.

 

Thanks all and happy new year !!

 

AIDA64 Reports.zip Hardware-Sniffer.zip

Edited December 31, 2025 by fermento

[deeveedee]

EDIT: @fermento If you haven't yet tested, please see my note here about a spelling mistake in my DeviceProperties.  If it's not too late, please test deeveedee.config-4-2.plist before testing the suggestions below.  I apologize for my spelling mistake.

 

EDIT2: @fermento Since deeveedee.config-4-1.plist "works" with con1 busid = 0, please test @Max.1974 's  config.plist here first before testing below.

 

@fermento Now that we have a mobile framebuffer configuration that "works," you can try the following:

• test the original deeveedee.config-4-1.plist from my previous post with the addition of boot-arg igfxagdc=0
• test the original deeveedee.config-4-1.plist from my previous post with the addition of boot-arg -disablegfxfirmware
• test the original deeveedee.config-4-1.plist from my previous post with the addition of boot-arg -igfxhdmidivs
• test the original deeveedee.config-4-1.plist from my previous post with the addition of boot-arg igfxfw=2
• test the original deeveedee.config-4-1.plist from my previous post with the addition of boot-args igfxagdc=0 -igfxhdmidivs igfxfw=2

If none of those boot-argument tests eliminate the "flicker," test the original deeveedee.config-4-1.plist from my previous post with each of the following framebuffers (AAPL,ig-platform-id):

• 3EA50009 (specified as <0900A53e> in config.plist DeviceProperties)
• 3E920009 (<0900923e>)
• 3E9B0009 (<09009B3e>)
• 3EA50000 (<0000A53e>)
• 3E000000 (<0000003e>)
• 3E9B0000 (<00009b3e>)
• 3EA50004 (<0400A53e>)
• 3EA50005 (<0500A53e>)
• 3EA60005 (<0500A63e>)

Be sure to carefully change AAPL,ig-platform-id before each new test.  Use the little endian form of the property (e.g., for 3EA50009, use 0900A53e)   Good luck and thanks again for your patience.  it takes a special kind of masochist to tolerate this

 

Happy New Year!

Edited January 1 by deeveedee

[FirstCustomac]

8 minutes ago, Max.1974 said:

Because both monitors are connected to the Intel UHD 630, you must use AAPL,ig-platform-id 00009B3E (active iGPU) and not 07009B3E (headless), since 00009B3E allows the iGPU to generate video for HDMI and DisplayPort while headless mode is only correct when a dedicated GPU provides the display output and the iGPU works only in the background. 

Sorry to point this out but both 0x3E9B0000 (Mobile) and 0x3E9B0007 (Desktop) have 3 connectors with 58MB total stolen memory.

[FirstCustomac]

16 minutes ago, Max.1974 said:

0x3E9B framebuffers are Coffee Lake, while the hardware in question is Comet Lake (UHD 630, device-id 8086:9BC5).

You just said 0x3E9B0007 is for headless and must use 0x3E9B0000. Isn't 0x3E9B0000 also Coffee Lake platform-id? I am confused. So what is the correct platform-id with connectors for Comet Lake?

 

And to my knowledge, WhateverGreen inject 0x9BC80003 (Empty-framebuffer) platform-id for Comet Lake systems by default. To get iGPU to drive a display you would need to manually inject platform-id with connectors. Isn't that right?

Edited December 31, 2025 by FirstCustomac

[FirstCustomac]

10 minutes ago, Max.1974 said:

You are mixing three different things: device-id, platform-id, and headless vs display framebuffers.

 

First, both 0x3E9B0007 and 0x3E9B0000 are Coffee Lake platform-ids.

Neither of them is a Comet Lake platform-id, so they are not the correct choice for Comet Lake systems.

 

Second, headless vs non-headless is not defined by “Coffee Lake vs Comet Lake”, but by the platform-id variant:

Headless framebuffers do not expose display connectors

Display framebuffers expose connectors

 

For Comet Lake, you should not use Coffee Lake framebuffers at all.

 

The correct approach for Comet Lake is:

Keep the native device-id (for example 8086:9BC5 for UHD 630)

Use a Comet Lake platform-id from the 9B3E family

 

Example:

AAPL,ig-platform-id = 00009B3E → Comet Lake with display connectors

AAPL,ig-platform-id = 07009B3E → Comet Lake headless

 

So, to answer your question directly:

 

The correct platform-id with connectors for Comet Lake is 00009B3E.

 

Coffee Lake platform-ids like 0x3E9B0000 or 0x3E9B0007 may appear to work, but they are not generation-correct and often lead to unnecessary framebuffer patching and instability.

 

Check here please: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#hdmi-in-uhd-resolution-with-60fps 

Quick question, what is the difference between 0x3E9B0000 and 00009B3E? According to you 00009B3E  is for Comet Lake and 0x3E9B0000 is for Coffee Lake. Is that correct?

[FirstCustomac]

6 minutes ago, Max.1974 said:

 

Yes, that is correct.

0x3E9B0000 is a Coffee Lake (CFL) platform-id. The 3E9B prefix belongs to Coffee Lake framebuffers.

00009B3E is a Comet Lake (CML) platform-id. The 9B3E prefix belongs to Comet Lake framebuffers.

 

Even though the values look similar, they are not interchangeable.

AAPL,ig-platform-id is interpreted in little-endian, and the prefix defines the generation, not just the byte order.

 

Coffee Lake → 0x3E9Bxxxx

Comet Lake → 0x9B3Exxxx

 

That’s why 00009B3E is the correct platform-id with connectors for Comet Lake, while 0x3E9B0000 remains a Coffee Lake framebuffer.

 

 

That said, in the Hackintosh world not everything is perfect: sometimes a generation-correct platform-id still requires small connector or framebuffer adjustments due to firmware, motherboard routing, or BIOS behavior, which is why real-world testing always matters.

Alright. Well. Happy New Year  Brother! I wish you the BEST!
@deeveedee Happy New Year to you as well. GL!

[deeveedee]

@Max.1974 That was quite a data dump!  Here are a few things to consider:

• There is only ONE desktop framebuffer for Coffee Lake and Comet Lake: 3e9b0007
• The Comet Lake desktop framebuffer recommended by Dortania / Acidanthera is 3e9b0007 as noted here.  Fermento is following standard procedure by using desktop framebuffer 3e9b0007.
• Now that fermento has DeviceProperties here (deeveedee-config-4-1.plist) that work with mobile framebuffers, he can test the mobile framebuffers that I have listed here (which include your so-called "Comet Lake framebuffers")
• Framebuffers are interchangeable (between mobile and desktop, Coffee Lake and Comet Lake) when the individual connectors are patched and when the framebuffer flags are patched.  It is incorrect to say that a specific framebuffer is "only for Coffee Lake" or "only for Comet Lake". 
• While your BIOS upgrade suggestion might change behavior, it does not explain the fact that Windows and Linux have no problem with dual displays.  In my opinion, the current system (without BIOS upgrade) that works perfectly with Windows and Linux should be used to test the suggestions here.  If those suggestions don't work, a BIOS upgrade might be a next step.

 

Happy New Year everyone!

 

EDIT: One more thing: framebuffer-fbmem, framebuffer-stolenmem should NOT be specified when DVMT pre-alloc is properly configured in BIOS.  The only time that these are needed is when BIOS does not permit proper configuration of DVMT.

Edited January 1 by deeveedee

[deeveedee]

@fermento I just noticed that I spelled one of the DeviceProperties wrong in deeveedee.config-4-1.plist.  The property framebufer-con0-busid should be framebuffer-con0-busid, which means that deeveedee.config-4-1.plist is "working" with framebuffer-con0-busid = 0 (unchanged).  I'm surprised by this.  Could you please test the attached config.plist which fixes this misspelling and report your test results?  In your test results please report the connectors (con0/con1 or con0/con2).  Thank you.

 

Thank you.

 

EDIT: I'm embarrassed to say that I had the same property misspelled in config-test2-1, config-test3-1, config-test2-2 and config-test3-2.  I"m sorry to say that the test results for those tests may have been invalidated by my spelling mistake.

deeveedee.config-4-2.plist.zip

Edited January 1 by deeveedee

[deeveedee]

@Max.1974 I only correct the statements that were incorrect.  I am not looking for opportunities to criticize you.  If I were to leave the incorrect statements as-is without correcting them, those reading this thread would be learning the wrong information.

 

EDIT: I think that fermento should test your proposed config.plist.  My intention was not to discourage any testing of your proposed solutions.  In fact, I hope that they work.  I think that your simplified config.plist is very clever and I wish that I had thought of it.  Well done.

Edited January 1 by deeveedee

[FirstCustomac]

Ah.. This was the exact response I was trying to avoid hence stopped dragging it any further.  Why don't we all agree that

3E9B0000 (Mobile) = 00009B3E (Reverse byte order of 3E9B0000)

3E9B0007 (Desktop) = 07009B3E (Reverse byte order of 3E9B0007) Not headless by the way

It's not about Coffee Lake vs Comet Lake. If one says otherwise, I don't know what to say. Again, Happy New Year everyone! Not the time for arguing. 

[Asural]

14 hours ago, Max.1974 said:

 

There is an application (program) for macOS and other operating systems called DisplayLink Manager; it may help with something. I even use it with my Vention Dock Station. Its free. 

 

WebPage: https://www.synaptics.com/products/displaylink-graphics/downloads 

 

This software was recommended, but it didn't work without a device for video streaming.
 

[Asural]

14 hours ago, Max.1974 said:

 

0x3E9B0000 is a Coffee Lake (CFL) platform-id. The 3E9B prefix belongs to Coffee Lake framebuffers.

00009B3E is a Comet Lake (CML) platform-id. The 9B3E prefix belongs to Comet Lake framebuffers.

 AAPL,ig-platform-id = <9B3E0000> does not exist in the list, but does that mean that the busId, pipe, type, and flags of AAPL,ig-platform-id = <3E9B0000> will be patched to the same values?

 

Isn't it saying that "the 3E9B0000 patch should be applied to the busId, pipe, type, and flags of AAPL,ig-platform-id = <9BC50003>"?
  

 

Edited January 1 by Asural

[deeveedee]

@Asural You are correct that  AAPL,ig-platform-id = <9B3E0000> does not exist.  That's about all you can say.  No amount of patching will fix it.

 

39 minutes ago, Asural said:

 Isn't it saying that "the 3E9B0000 patch should be applied to the busId, pipe, type, and flags of AAPL,ig-platform-id = <9BC50003>"?

 

AAPL,ig-platform-id = <9BC50003> is a "headless" desktop framebuffer (no connectors).  No patches need to be applied to it.  I know you know this, but for others, headless framebuffers should not be considered in this thread since the iGPU is being used to drive displays, not a dGPU.

 

39 minutes ago, Asural said:

 

 

I like your expanded framebuffer table.  did you make this yourself or did you find this in documentation?  If you found it somewhere, could you please provide the link to the document?  Thank you.

Edited January 1 by deeveedee

[FirstCustomac]

Expand the spoiler?
 

Spoiler

 

[deeveedee]

51 minutes ago, Max.1974 said:

The value <9B3E0000> shown in the config.plist is not a different platform-id.

It is simply the little-endian Data representation of the logical platform-id 0x3E9B0000 (Coffee Lake), which does exist and is documented by WhateverGreen.

 

Please know that I am not criticizing you by offering this correction: The value <9B3E0000> is little endian representation of 00003E9B which is a Coffee Lake device-id, not a framebuffer.  If we enter <9B3E0000> into Open Core DeviceProperties as a value for AAPL,ig-platform-id, it would be invalid, because it is not a valid framebuffer.

 

I am not trying to be mean or to attack you.  What you are saying is incorrect.  This stuff is confusing enough when it is stated correctly.  Adding incorrect statements is just making it even more confusing.

 

EDIT: I agree with you that starting with the most simple DeviceProperties and then adding properties as needed is best.  That's why I like your proposed simple config.plist here.  I am looking forward to seeing fermento's test results with your simple config.plist.  Well done.

 

 

1 hour ago, FirstCustomac said:

Expand the spoiler?

 

Thank you.  I am aware of that reference.  The table referenced by Asural is slightly different in that it includes the port number 0x05, 0x06, 0x07). I know that these port numbers are standard - I was just wondering whether Asural created this table or found it in another reference.

Edited January 1 by deeveedee