Tahoe - Intel UDH 630 - dual monitor problems

[fermento]

@deeveedee

 

I tested config2 monitor.plist ->Flickering issues

 

I tested the following changes from config-test2-1.plist

3EA50009 (<0900A53e>) -> only one display output
3E920009 (<0900923e>) -> only one display output
3E9B0009 (<09009B3e>) -> only one display output
3EA50000 (<0000A53e>) -> only one display output
3E000000 (<0000003e>) -> only one display output
3E9B0000 (<00009b3e>) -> only one display output
3EA50004 (<0400A53e>) -> only one display output
3EA50005 (<0500A53e>) -> only one display output
3EA60005 (<0500A63e>) -> only one display output
 

On 1/3/2026 at 1:31 PM, deeveedee said:

Is it still true that you can boot macOS normally (without flickering) with one display powered-off, and then power-on the second display after booting?  Is it also true that the second display turns on "immediately" when you power it on and that both displays then remain on without flickering?

 

• When I boot with the second display powered off but connected, after login, I can see a brief flickering on display 1, then I power on display 2 and both are stabilized as normal, both working fine. So, I assume, the flickering is there but I am not seeing it because the second display is power off.
• When I boot with the second display disconnected and a few minutes after login I connect the second display, they both stabilize instantly without no flickering

[deeveedee]

@fermento I reviewed the posts in this thread and see that we only wanted to test those other framebuffers with config-test2-1.plist IF config-test2-1.plist worked with framebuffer 0x3e920000.  See here and your test results here.  Since your test results showed that config-test2-1.plist did not work, we would not expect it to work when changing framebuffer patform IDs, so we should not be using config-test2-1.plilst to test other framebuffer platform IDs.

 

In order to test the other framebuffer platform IDs, you would need to test with deeveedee.config-4-2.plist (the corrected version of deeveedee.config-4-1.plist) as noted here.  

 

I apologize for the confusion.  There's a lot going on in this thread and my config.plist naming convention is not helping.

 

In summary...

If you want to test the other framebuffer platform IDs, use deeveedee.config-4-2.plist as specified here, not config-test2-1.plist.  Thank you for your continued patience.

Edited January 4 by deeveedee

[fermento]

@deeveedee

 

Tested the following platform IDs from deeveedee.config-4-2.plist

3EA50009 (<0900A53e>) -> flickering issues
3E920009 (<0900923e>) -> flickering issues
3E9B0009 (<09009B3e>) -> flickering issues
3EA50000 (<0000A53e>) -> flickering issues
3E000000 (<0000003e>) -> flickering issues
3E9B0000 (<00009b3e>) -> flickering issues
3EA50004 (<0400A53e>) -> flickering issues
3EA50005 (<0500A53e>) -> flickering issues
3EA60005 (<0500A63e>) -> flickering issues
 

[deeveedee]

@fermento That was quick!  I wonder if your experience will be similar to that of brumas2025 in his thread.  If you change your mobile framebuffer in deeveedee.config-4-2.plist back to the desktop framebuffer 0x3e9b0007 (leaving all other properties untouched), do you see the same "flickering issues" with both displays "working?"

 

I'm going to refresh my knowledge of connector flags (framebuffer-conX-flags) to see if I have another suggestion for you to try.  Thanks again for your patience.

[deeveedee]

@fermento

 

Based on all of your testing, I think you have demonstrated that the "flickering" problem is not resolved by changing framebuffer platform IDs, thus framebuffer flags are probably not going to fix the problem.  You have also demonstrated that using mobile or desktop framebuffers make no difference as long as busIDs and pipes are properly patched.  

 

In addition to framebuffer-flags that govern the behavior of all connectors in a framebuffer, there are flags for each of the connectors (framebuffer-conX-flags) defined in the framebuffer.

 

The connector flags for Coffee Lake / Comet Lake Framebuffers are defined as follows

0 0 0 0 0 1 0 0 1 0 0 1 1 0 0 0 0x0498 (LVDS) <98040000>
0 0 0 0 0 0 0 1 1 0 0 0 0 1 1 1 0x0187 (DP)   <87010000>
0 0 0 0 0 0 0 1 1 1 0 0 0 1 1 1 0x01C7 (DP)   <C7010000>
0 0 0 0 0 0 0 0 1 0 0 1 1 0 0 0 0x0098 (LVDS) <98000000>
0 0 0 0 0 0 1 1 1 1 0 0 0 1 1 1 0x03c7 (DP)   <C7030000>
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | +- CNAlterAppertureRequirements
| | | | | | | | | | | | | | +--- CNUnknownFlag_2
| | | | | | | | | | | | | +----- CNUnknownFlag_4
| | | | | | | | | | | | +------- CNConnectorAlwaysConnected
| | | | | | | | | | | +--------- CNUnknownFlag_10
| | | | | | | | | | +----------- CNUnknownFlag_20
| | | | | | | | | +------------- CNDisableBlitTranslationTable
| | | | | | | | +--------------- CNUseMiscIoPowerWell
| | | | | | | +----------------- CNUsePowerWell2
| | | | | | +------------------- CNUnknownFlag_200
| | | | | +--------------------- CNUnknownFlag_400
| | | | +----------------------- CNUnknownFlag_800
| | | +------------------------- CNUnknownFlag_1000
| | +--------------------------- CNUnknownFlag_2000
| +----------------------------- CNUnknownFlag_4000
+------------------------------- CNUnknownFlag_8000

I copied the bit definitions from Hackintool and the framebuffer-conX-flags values from here.  In the past, I have successfully patched framebuffer connector flags through pure luck on a few hacks by trying the flags employed by each framebuffer definition; specifically:

• 0x0498 (LVDS) <98040000>
• 0x0187 (DP)   <87010000>
• 0x01C7 (DP)   <C7010000>
• 0x0098 (LVDS) <98000000>
• 0x03c7 (DP)   <C7030000>

Framebuffer 0x3e9b0007 defines the framebuffer-conX-flags as 0x03C7 for each connector - the connector flags that you are currently using in your DeviceProperties.  I am not going to try to mislead you into thinking that I know what I'm doing.  This is black magic as far as I'm concerned.  My suggestion to you would be to test each of the known flag settings as defined for the Coffee Lake / Comet Lake Framebuffers.

 

The attached config.plists are based on config-test1-11.plist (going back to the "early days" of our testing  ) which limits the port count to 2 and changes con1 index to 3 (so that your con0 and con1 connectors are active) as was the case in your originally posted config.plist.  The difference between the attached config.plists is that they have different framebuffer-conX-flags.  For this first simple test, I have chosen to define the framebuffer-conX-flags the same for con0 and con1.  That may not be the best solution, but it's a start to our testing.  the goal is to observe and report any behavioral changes caused by the changing framebuffer-conX-flags.

 

The attached config.plists are as follows:

• config-5-1.plist: config-1-11.plist with framebuffer-conX-flags defined as 0x03C7 (unchanged from their definition for framebuffer platform ID 0x3e9b0007).  If this config.plist does not "work," stop testing and do not test the other config.plists.  If it does "work," we don't expect this config.plist to cause any changes in the "flickering" behavior.
• config-5-2.plist: config-1-11.plist with framebuffer-conX-flags = 0x0498
• config-5-3.plist: config-1-11.plist with framebuffer-conX-flags = 0x0187
• config-5-4.plist: config-1-11.plist with framebuffer-conX-flags = 0x01C7
• config-5-5.plist: config-1-11.plist with framebuffer-conX-flags = 0x0098 

 

Please test the attached config.plists starting with config-5-1.plist.  If config-5-1.plist does not work (any displays are black or doesn't boot), stop testing and report failure.  If config-5-1.plist "works," test the remaining config.plists and report results.  In your results, report the number of displays active after booting and whether the "flickering" behavior has changed.  You don't need to post any screenshots.  Thank you.

 

EDIT: Notes for future tests (ignore for now):

• Trim injected kexts to minimal required
• Test Pipes 0x11 and 0x12
• Test con flags 0x4c7

 

config-test5-1.plist.zip config-test5-2.plist.zip config-test5-3.plist.zip config-test5-4.plist.zip config-test5-5.plist.zip

Edited January 6 by deeveedee
Fixed typo

[LockDown]

dual monitor works here

 

Lockdown-DualMonitor.zip

[Asural]

@deeveedee The changes to Connect.ods are shown based on the contents of IntelFramebuffer.bt.
BusId has been increased to 7 as suggested by RehabMan (index+4), increasing the number of connect options.

 

@Max.1974 I'm starting to read flag, but are there any resources that will explain it to me in a gentle way?

 

 

Connect.ods

Edited January 5 by Asural

[Max.1974]

7 horas atrás, Asural disse:

@deeveedee As alterações no Connect.ods são mostradas com base no conteúdo do IntelFramebuffer.bt.
O BusId foi aumentado para 7, conforme sugerido pelo RehabMan (índice+4), aumentando o número de opções de conexão.

 

@Max.1974 Estou começando a ler bandeira, mas há algum recurso que me explique de maneira gentil?

 

 

Conexão.ods 32,16 kB·0 downloads

 

Hello @Asural my friend, I would like to say that I wish there were more resources available, but the means are scarce. I only managed to find the websites mentioned above that I sent you. I can say that your table is very well structured and would be a good starting point. However, it is necessary to consider the combination of connector types with device types (the relationship between DP, HDMI, LVDS, VGA with pipes, Bus ID, and con0 + flag is the unknown that the creator of Hackintool, RehabMan, and others were not able to fully resolve).

 

Therefore, I suggest testing, and it is through testing that progress is sometimes possible, even when the results are not always logical. I apologize for not being able to help further, because I could create dozens of plist files, but the combinations would be dependent on testing and specific hardware. Perhaps these combinations could be generated by AI based on the framebuffer platform ID and the available flags. 

[Max.1974]

13 hours ago, LockDown said:

dual monitor works here

 

Lockdown-DualMonitor.zip 1.09 kB · 5 downloads

 

Oh!!! Very good job my friend!! Congrats!!   

[deeveedee]

@Max.1974 Aren't they same DeviceProperties that fermento started with in this thread?  See here, here and here.  That's how we got here.  

[Max.1974]

Maybe should try @Asural and  @fermento  could manage with EC RWEverething from Windows 10, to get the real framebuffer. 

 

https://rweverything.com/download/ 

 

It’s a good program to get real hardware bits.

 

 

 

 

It doesn’t work on Windows 11.

[deeveedee]

@@Max.1974 This thread is getting cluttered with a lot of posts.  I, too, am starting to get lost in the clutter of extra posts that seem to have nothing to do with this thread.  fermento's original DeviceProperties are here - the same as the "new" list that you proposed.

[Max.1974]

Indeed, you’re right, but I didn’t post as much as you did. In our eagerness to help, we ended up repeating ourselves. This problem would be solved if I just bought an AMD card hahaha. 

[Asural]

14 hours ago, Max.1974 said:

Maybe should try @Asural and  @fermento  could manage with EC RWEverething from Windows 10, to get the real framebuffer. 

It doesn’t work on Windows 11.

I don't think it's a problem with the 12 Bytes framebuffer settings (although the connector settings are important, of course).
I've already updated to Windows 11, but I'll install 10 later and try that out.
Don't delete the list of references I wanted to read...
 

[deeveedee]

6 hours ago, verdazil said:

@deeveedee, You recommend framebuffer 07009B3E for testing (which is correct). However, you ignore the fact that according to the specification of this framebuffer, all connectors are of type DP, while the user has only one DP port on the motherboard (or even none). In such cases, you need a lspcon patch.

Earlier in this thread, I did test lspcon patches with framebuffer-conX-preferred-lspcon-mode 0 and 1.  It didn't help.  See here, here, here and here.   fermento had also tested lspcon.

 

I'm open to any suggestions, since we still haven't found a working solution for this thread.

[Max.1974]

9 hours ago, Asural said:

I don't think it's a problem with the 12 Bytes framebuffer settings (although the connector settings are important, of course).
I've already updated to Windows 11, but I'll install 10 later and try that out.
Don't delete the list of references I wanted to read...
 

@Asural 

Hi my friend, I’m sending you the list in PM with more websites too. 

[fermento]

@deeveedee

 

- config-test5-1.plist -> flickering issues
- config-test5-2.plist -> not able to reach the login
- config-test5-3.plist -> flickering issues
- config-test5-4.plist -> flickering issues
- config-test5-5.plist -> not able to reach the login
 

@LockDown

 

LockDown-DualMonitor config -> flickering issues

[deeveedee]

3 hours ago, verdazil said:

 

I believe this area hasn't been explored deeply enough. My successful example confirms this.

 

I think the best way to proceed would be for you to post one or more config.plists that you want fermento to test.

[KL45U5]

The exploration has been done already but that was like 10 years ago. A lot of info is burried in the depths of waybackmachine where corpse of dead forums are buried.

 

IntelFramebuffer.bt linked to by Asural is actually a binary template for the 010 Hex Editor which helps with analyzing framebuffers. So I suggest you just import that into 010 Editor and check framebuffer and build from there instead of starting all over again. 

 

 

[fermento]

15 hours ago, verdazil said:

There are several unknown parameters.
1. What HDMI cable is used (version 1.4 or 2.0)?

2. What kind of monitor is used (2K or 4K) and what inputs does it have?

3. What is the motherboard revision (1.0 or 1.1)?

 

My successful result was achieved on a motherboard with revision 1.1, an HDMI 2.0 cable, and a 4K monitor. If these parameters match the user's settings, they can use my settings without any modifications.

config-UHD630.plist 917 B · 3 downloads

 

Tested your config, flickering issues during login

 

1. HDMI cable 2.1

2. Displays

  2.1. Gigabyte M27Q - 2‎560 x 1440 (QHD)

  2.2. Dell E248WFP - 1920 x 1200 FHD

3. Revision 1.1

[fermento]

23 minutes ago, verdazil said:

It's also possible that the existing adapter is simply unsuitable for macOS.

 

What do you mean? Works on Linux and Windows without any problem, why would not do it for macOS? Also, as I already told in the thread, I tested directly HDMI - HDMI with a Samsung Tv and the same flickering happened, that's why we discarded the adapter.

[fermento]

32 minutes ago, verdazil said:

Try framebuffer-con2-type  = 00020000 or = 04000000

 

No output on Dell display for both values

[deeveedee]

@verdazil Here's a summary of test results that might help:

• Testing two displays where one is connected with HDMI->HDMI or HDMI->DVI-D produces the same results with "flickering".  The video of this flickering is here.  I believe this demonstrates that the HDMI->DVI adapter is not causing the "flickering" problem.
• Booting macOS with one display connected boots without delay/flickering.  After booting, the second display can be connected without issues.  This was first demonstrated here.
• There are two "working" config.plists
  • One employs pipes/busIDs to activate displays on con0 and con2.  First demonstrated here.  This first test had lspcon enabled and displays still flickered at boot.
  • One swaps indices of con1 and con2 to activate displays on con0 and con1.  First demonstrated here.  This test does not have lspcon enabled and displays still flickered at boot.

I concluded that lspcon was not relevant to this hack, but I am open to the possibility that I tested incorrectly.

Edited January 7 by deeveedee

[deeveedee]

Ok - I will watch while you test lspcon with fermento. Thank you.

[verdazil]

Ok, one last test that could decide everything. Connect the Gigabyte M27Q monitor to the motherboard twice (simultaneously) – with an HDMI-HDMI cable and a DP-DP cable. Use my settings as is.

Switch monitor inputs to ensure both are working.

Edited January 7 by verdazil