Tahoe - Intel UDH 630 - dual monitor problems

[fermento]

@deeveedee

 

- Tried deeveedee.config-4-2, flickering display, attached connectors.
- Corrected the framebuffer typo in config-test2-2 and tested it, only one display output, attached the connectors.
- Corrected the framebuffer typo in config-test3-1 and tested it, only one display output, attached the connectors.
- Corrected the framebuffer typo in config-test3-2 and tested it, only one display output, attached the connectors.
 

I will try the different boot arguments in a few minutes

 

 

@Max.1974

 

- I updated the BIOS to the latest version as you suggested

- Tried device-simple-test1-Max, only one display output, attached the connectors

 

1. How do I extract a new Device properties complete and IOREG complete from Hackintool? I don't know how to do it 🥲
2. I don't understand where to add the 'BIOS' key and which is the value for generating a correct report. Can you guide me?

[deeveedee]

@fermento thanks for testing and providing screenshots.  When you examine framebuffer connectors in Hackintool, Hackintool may display more helpful information if you select your current framebuffer Platform ID from the menu in the upper right.  For example, if your current configuration uses FrameBuffer with Platform ID 3e920000, select 0x3e920000 from the pull-down menu before capturing your screenshots.  It's not guaranteed to be more helpful, but it doesn't hurt.  

 

Thanks again for re-testing after my typo.  

 

Please be sure to test Max.1974's simplified config.plist here.

[fermento]

@deeveedee

 

1. tested the deeveedee.config-4-2.plist with the addition of boot-arg igfxagdc=0
2. tested the deeveedee.config-4-2.plist with the addition of boot-arg -disablegfxfirmware
3. tested the deeveedee.config-4-2.plist with the addition of boot-arg -igfxhdmidivs
4. tested the deeveedee.config-4-2.plist with the addition of boot-arg igfxfw=2
5. tested the deeveedee.config-4-2.plist with the addition of boot-args igfxagdc=0 -igfxhdmidivs igfxfw=2

 

All the tests gave me flickering displays but test 3 and 5 gave me a different flickering, since the login screen appears. The amount of time to wait is the same before the displays are stabilized but I wanted to describe this because is different. All of the other configs the flickering starts a bit later from the login screen, with the Dell display remaining black for a few seconds until starts doing the flickering.

[deeveedee]

Tests 3 and 5 include boot-arg -igfxhdmidivs which enables WhateverGreen's hdmi dividers fix described here.  I interpret your observation of "different flickering" as meaning that the boot-arg is not necessary for your hack.

 

You may want to review the boot-args / DeviceProperties described here.  There May be others that you want to test.

 

Thanks again for testing.  You're not a quality control tester by any chance?  I haven't met anyone else with your patience for tedium.

 

EDIT: @fermento I think that @brumas2025 's discovery here (using my DeviceProperties from here) is {censored} incredible.  I never would have guessed that.  Another user here reported a similar experience.  You may want to test those DeviceProperties on your hack and report your results.  If you want to test them and you need help, just ask.

 

Edited January 1 by deeveedee

[fermento]

@Max.1974

 

Thanks, here are the files

 

pcidevices.zip

max-config-ioregistry.zip

 

@deeveedee

 

I tested a few more boot arguments from the WhatEvergreen documentation without progress

Edited January 1 by fermento

[deeveedee]

@fermento This "flickering" seems to me to be a problem with HDMI sync (which is why I proposed testing boot-arg -igfxhdmidivs).  In addition to the framebuffer patching tests, you may want to consider the possibility that the flickering on your HDMI->DVI-D display is caused by System Settings in macOS.

 

Have you tried adjusting "Optimize for",  "display resolution", "Refresh Rate", "Color Profile", "Underscan" in System Settings?  This might be especially important if you're trying to use a non-native display resolution for your Dell display.  If you haven't thoroughly tested Display Settings in macOS, add this to your items to test.  Also try rearranging your displays (not physically on your desk, but in System Settings) and changing the Main display.  I'm not suggesting that you make any of your tested settings permanent at this time, but just some new things to try.  You're doing great. 

 

 

EDIT: @fermento  Sorry if you already posted this information, but I don't see it... could you please post the exact brand/model of your HDMI->DVI-D adapter cable and please confirm that the model of your Dell display is E248WFP?  Thank you.

 

EDIT2: I am not familiar with the BIOS settings on your motherboard, so I hope that someone else like @verdazil can confirm this.  According to ChatGPT, your BIOS settings should include the following:

 

BIOS

• DVMT Pre-Alloc → 64MB Min (128MB if possible)
• Primary Graphics → iGPU
• CSM → Disabled
• Above 4G Decoding → Enabled

Edited January 2 by deeveedee

[Asural]

13 hours ago, deeveedee 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.

The table in this post was easy to understand, so I'm currently creating it myself using LibreOffice. I've attached the current file.
 

11 hours ago, Max.1974 said:

 

Depending on the result, we can then start adding Bus ID, as I initially did, and according to RehabMan, when the pipe is undefined we can use <12000000>.For that reason, if we start by checking things in Windows and identifying a framebuffer there, it is always better to test within the same category (desktop or laptop), whenever possible.

 

In general, connectors are more critical on mobile platforms, however there are hundreds of possible combinations, because the processor itself contains “everything” and the actual behavior is dictated by software instructions.

 

This is my personal opinion.

Thank you, I now understand why Pipe = <12000000> is valid.
All combinations result in the table below, but since it includes Mobile and Option VGA, it seems better to separate them, so I plan to modify it later.

 

By the way, I'd like to somehow get the built-in VGA of my HP400G5 working, but how do I check this in Windows?

Connect.ods

Edited January 2 by Asural

[deeveedee]

@Asural I like the table format. Nicely done!

[Asural]

2 hours ago, Max.1974 said:

 

Hi @Asural Framebuffer-conX-alldata  did not work for me. I set up each flag separately, pairing each one with its corresponding values. 

 

Regarding VGA: you can verify whether the built-in VGA output is enabled by entering the BIOS setup (F10 on boot). Under Advanced → Device Configuration, make sure Integrated Graphics is enabled and, if available, Multi-Monitor / iGPU Always Enable is set to enabled. If VGA works in Windows, then the firmware is exposing the iGPU correctly. However, macOS does not support analog VGA output, so VGA will never work there and a digital output (DisplayPort or an active DP→HDMI adapter) must be used.  

It seems possible that the problem is automatically corrected through the bulk settings and individual settings. 
When I have the energy, I will look into the WEG log for the built-in VGA as well.
Regarding index+4, I personally use index1=BusId=1 so I will leave the selection unchanged.
I will add a value for Pipe, but the content is suspicious so I will not write it down.

 

I have attached the corrected file. The font is for Japanese, so please change it to a font that is easier to read.

Connect.ods

Edited January 2 by Asural

[Max.1974]

@Asural  I recommend that anyone with a laptop / desktop intel start with RehabMan’s tips, especially on the website where he talked more deeply about the subject and served the community with great recognition. Unfortunately, I believe he has passed on, but may God bless him. He was not able to finish all of his reports, yet there is a wide diversity of hardware, and because of that it is necessary to start from a ground-zero reference point.

Keep testing, focusing only on Pipe, Bus ID, connector con0, con1, con2, pipe count, etc., if you are able to verify them. From what I have been analyzing, very few people have achieved success with two HDMI monitors. One of my outputs is pure DP, and the HDMI is also pure; however, it comes out through the USB-C port on my laptop.

I’ll see if I can find any Coffee Lake or Comet Lake hardware to test, but I probably don’t have any in my museums. 😉

13 minutes ago, Asural said:

It seems possible that the problem is automatically corrected through the bulk settings and individual settings. 
When I have the energy, I will look into the WEG log for the built-in VGA as well.
Regarding index+4, I personally use index1=BusId=1 so I will leave the selection unchanged.
I will add a value for Pipe, but the content is suspicious so I will not write it down.

 

I have attached the corrected file. The font is for Japanese, so please change it to a font that is easier to read.

Connect.ods 22.59 kB · 2 downloads

 

Congratulations for you great Job!! Very awesome Table !!  

Edited January 2 by Max.1974

[deeveedee]

9 hours ago, Max.1974 said:

I just want to emphasize and reinforce that instead of using boot-args, it is possible to place all of them directly in the DeviceProperties section of the plist, which I consider a better approach to avoid conflicts between what is set in the plist and what is passed at boot time.

 

I am not criticizing you or trying to attack you - I just want to state a differing view about WhateverGreen boot-args and DeviceProperties.  This is the WhateverGreen.kext source code that processes the igfxfw boot-arg and DeviceProperty:

                if (supportsGuCFirmware && getKernelVersion() >= KernelVersion::HighSierra) {
                        if (!PE_parse_boot_argn("igfxfw", &fwLoadMode, sizeof(fwLoadMode)))
                                WIOKit::getOSDataValue<int32_t>(info->videoBuiltin, "igfxfw", fwLoadMode);
                        if (fwLoadMode == FW_AUTO)
                                fwLoadMode = info->firmwareVendor == DeviceInfo::FirmwareVendor::Apple ? FW_APPLE : FW_DISABLE;
                } else {
                        fwLoadMode = FW_APPLE; /* Do nothing, GuC is either unsupported due to low OS or Apple */
                } 

WhateverGreen processes the boot-arg first (before the DeviceProperty).  If the boot-arg is present, WhateverGreen never processes the DeviceProperty.  This means that WhateverGreen boot-args override WhateverGreen DeviceProperties.  If both the boot-arg and DeviceProperty are present in the config.plist (e.g., if the config.plist includes both boot-arg igfxfw=2 and DeviceProperty "igfxfw, Data, <00000000>", WhateverGreen will inject the property igfxfw=2 and ignore the DeviceProperty "igfxfw, Data, <00000000>".

 

This is why it is often preferable to test with WhateverGreen boot-args and then after testing is complete, to either leave the properties as boot-args (which is perfectly fine) or convert them to DeviceProperties (which is also perfectly fine).  It is a personal preference.

 

The WhateverGreen boot-arg and the WhateverGreen DeviceProperty can be used interchangeably.  WhateverGreen processes them at the same time.  Conveniently, if a WhateverGreen DeviceProperty exists and one wants to change the DeviceProperty for testing, it is possible to simply override the DeviceProperty with its corresponding boot-arg for testing, and then to remove the boot-arg to revert to the DeviceProperty.

 

For example, if config.plist DeviceProperties contain WhateverGreen property "force-online, Data, <01000000>" and one wants to test with force-online disabled, simply add the boot-arg igfxonln=0 while leaving the DeviceProperty unchanged.  Then, after testing is complete, remove the boot-arg so that the DeviceProperty applies.

 

9 hours ago, Max.1974 said:

Regarding VGA: ... However, macOS does not support analog VGA output, so VGA will never work there and a digital output (DisplayPort or an active DP→HDMI adapter) must be used.

 

This is incorrect.  VGA ports normally work fine in macOS when the port type is configured as DP.  I frequently use VGA ports on hacks when booting macOS High Sierra through Tahoe.

As state here

Note: VGA on Skylake and newer are DisplayPorts internally and so are supported by macOS. Please use the DisplayPort connector for these systems.

Edited January 2 by deeveedee

[deeveedee]

@Asural Is your analog VGA discussion intended to solve fermento's problem for the motherboard/configuration in this thread, or is that for another system?  I'm confused about the solutions being proposed and just want to make sure that I understand.  Thank you.

Edited January 2 by deeveedee

[Asural]

17 minutes ago, deeveedee said:

@Asural Is your analog VGA discussion intended to solve fermento's problem for the motherboard/configuration in this thread, or is that for another system?  I'm confused about the solutions being proposed and just want to make sure that I understand.  Thank you.

This was a question about the lack of VGA display on the H310 in another thread, but it seems that VGA output is possible.
Of course, the question was mainly about my HP400G5.
 

[deeveedee]

@Asural Thank you for clarifying.  Have you created a thread dedicated to solving the issues with your HP400G5?  In the same way that brumas2025 created a separate thread for his ASRock H310M-HDV to separate the two discussions, it would be helpful to separate your discussion from this thread as well.  Thank you.

[Asural]

9 minutes ago, deeveedee said:

@Asural Thank you for clarifying.  Have you created a thread dedicated to solving the issues with your HP400G5?  In the same way that brumas2025 created a separate thread for his ASRock H310M-HDV to separate the two discussions, it would be helpful to separate your discussion from this thread as well.  Thank you.

Off topic...
It seems that your thread also has questions about the HP400 series, but since the settings for SFF/Mini are quite different, I'm considering creating a comprehensive guide.
I'd like to set up a thread on this in the future.
 

[deeveedee]

@Asural Creating a separate thread for your hack would be helpful to avoid confusion in this thread.  This discussion is complicated enough when only discussing one hack

 

Off Topic: @Asural Note that Analog VGA ports usually work without problems in macOS.  Set the port type to DP for Analog VGA.  I frequently use analog VGA ports in macOS High Sierra through Tahoe without any problems.

 

As state here

Note: VGA on Skylake and newer are DisplayPorts internally and so are supported by macOS. Please use the DisplayPort connector for these systems.

 

Edited January 2 by deeveedee

[fermento]

17 hours ago, deeveedee said:

@fermento This "flickering" seems to me to be a problem with HDMI sync (which is why I proposed testing boot-arg -igfxhdmidivs).  In addition to the framebuffer patching tests, you may want to consider the possibility that the flickering on your HDMI->DVI-D display is caused by System Settings in macOS.

 

Have you tried adjusting "Optimize for",  "display resolution", "Refresh Rate", "Color Profile", "Underscan" in System Settings?  This might be especially important if you're trying to use a non-native display resolution for your Dell display.  If you haven't thoroughly tested Display Settings in macOS, add this to your items to test.  Also try rearranging your displays (not physically on your desk, but in System Settings) and changing the Main display.  I'm not suggesting that you make any of your tested settings permanent at this time, but just some new things to try.  You're doing great. 

 

 

EDIT: @fermento  Sorry if you already posted this information, but I don't see it... could you please post the exact brand/model of your HDMI->DVI-D adapter cable and please confirm that the model of your Dell display is E248WFP?  Thank you.

 

EDIT2: I am not familiar with the BIOS settings on your motherboard, so I hope that someone else like @verdazil can confirm this.  According to ChatGPT, your BIOS settings should include the following:

 

 

BIOS

• DVMT Pre-Alloc → 64MB Min (128MB if possible)
• Primary Graphics → iGPU
• CSM → Disabled
• Above 4G Decoding → Enabled

 

- I tested the different configurations on Displays option in macOS with no different results.

- Yes, the second display is a Dell E248WFP

- The HDMI->DVI-D adapter is generic, no info at all

- I checked my bios settings and are configured like that

 

 

[deeveedee]

@fermento In macOS Display settings, please experiment with lower resolutions for the Dell display (stay with resolutions that are natively supported by your display).  If macOS is having problems negotiating the HDMI -> DVI-D link, you may have problems in macOS with Dell resolutions over 1920x1080 at 60Hz (single-link DVI).  I'm not saying to stop testing all of the mobile framebuffers, but other settings need to be considered, too.

 

EDIT: If lower resolutions fix the flickering problem, then you may need to purchase a high-quality HDMI->DVI-D adapter.

 

EDIT2: @fermento I have ordered a HDMI -> DVI-D adapter to test on my hack. I already have a Dell display with DVI-D and VGA input ports.  If we don't resolve this for you by the time my adapter arrives next week, I'll be in a position to test myself.  Experimenting without the actual hardware is a bit challenging

Edited January 2 by deeveedee

[fermento]

On 1/1/2026 at 5:15 PM, deeveedee said:

Thanks again for testing.  You're not a quality control tester by any chance?  I haven't met anyone else with your patience for tedium.

 

😂 no, I'm software engineer

 

@deeveedee

 

I don't believe is an adaptor or display problem because, as I said before, I tested replacing the Dell with a Samsung Tv using HDMI to HDMI cable directly and the flickering was still there. Also, no flickering at Windows or Linux.

 

Did you suggest to me to try this config?

 

I will be testing a few more configs in a brief.

 

[Asural]

34 minutes ago, fermento said:

 

😂いいえ、私はソフトウェアエンジニアです

 

@ディーブディーディーディー

 

アダプターやディスプレイの問題ではないと思います。前にも言ったように、HDMIからHDMIケーブルを直接使用してDellをSamsung TVに交換してテストしたところ、ちらつきがまだありました。また、WindowsやLinuxではちらつきはありません。

 

この設定を試すように提案しましたか？

 

もう少し設定をもう少しテストします。

 

The HDMI signal synchronization may be delayed, so I have attached a file with HDMI set to con0, so please try it.

 

ADD:

This boot-arg may have some effect, so please try it.

HDMIcon0.plist

Edited January 3 by Asural

[fermento]

@Asural

 

• HDMIcon0.plist - default - Flickering issues
• HDMIcon0.plist - gfxrst=1 - Flickering issues
• HDMIcon0.plist - gfxrst=4 - Flickering issues

 

@Max.1974

 

• device-simple-test2-Max.plist - Only Gigabyte display output
• 3-full-UHD630-Desktop-Baio.plist - Flickering issues but different than the rest, both displays sincronized tried to show the login screen at the same time, the main display correctly, the other display was kind of a blue screen because of the Tahoe background login screen, I think was flickering so fast that was seen as a blue screen, after a few seconds, the most common flickering until stabilization. Amount of time to stabilization similar to the others.
• plist-full-test3-max.plist -  Flickering issues 
• UHD630-alternative-device-properties.plist - Only Gigabyte display output

 

I attached my EFI folder.

 

Any advice to export correctly the report on OpCore-Simplify? I was not able to find what is the error with the 'BIOS' key.

 

 

EFI.zip

[Asural]

7 hours ago, fermento said:

I attached my EFI folder.

 

Any advice to export correctly the report on OpCore-Simplify? I was not able to find what is the error with the 'BIOS' key.

 

 

EFI.zip 9.13 MB · 2 downloads

Is the attached EFI ACPI the SSDT that you created in Windows?
It seems to have worked fine when created with ACPI.
 

ADD:

Since you have updated the BIOS, it is recommended that you create the ACIP again.
 

Edited January 3 by Asural

[deeveedee]

20 hours ago, fermento said:

😂 no, I'm software engineer

🤣

 

20 hours ago, fermento said:

I don't believe is an adaptor or display problem because, as I said before, I tested replacing the Dell with a Samsung Tv using HDMI to HDMI cable directly and the flickering was still there. Also, no flickering at Windows or Linux.

 

Good point - I missed that you had tested a direct HDMI->HDMI and still had the same problem.  I'm not sure how I missed that, given the small number of posts in this thread.   I agree that the adapter is not the problem.

 

20 hours ago, fermento said:

Did you suggest to me to try this config?

 

 

Yes.

 

 

EDIT: @fermento 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?

 

 

EDIT2: @fermento It's a good thing the adapter isn't the problem ... I just received an order delivery update from Walmart.com: my adapter is expected to arrive on 26 January.  I've heard of slow deliveries, but that must be on the slowest boat from China.

Edited January 3 by deeveedee

[Asural]

1 hour ago, Max.1974 said:

 

The ideal approach now would be for you to set the Pipes, BUS IDs, and the correct ports according to the Intel HD Framebuffer from the WEG page; I believe this won’t be difficult for you. Test your other Dell monitor on the same port to see if it works. I also researched that some users were having issues with the DMAR table in the ACPI folder, and they disabled DisableIOMapper in the config plist and VT-d in the BIOS. I wish you good luck. 

When you update the BIOS, it will be reset to the factory settings, so you will probably need to reconfigure it.
I think there are many mistakes where people add the SSDT created in ACPI and then don't reflect the contents of patches_OC.plist in ACPI.
Regarding VT-d=ON, which you pointed out, I think this guide will need to be revised regarding DMAR.

 

1 hour ago, Max.1974 said:

Here are some links with a complete background that I can cite here:

 

Thank you for the references, especially Russian ones, which are hard to find.
 

Edited January 3 by Asural

[Max.1974]

25 minutos atrás, Asural disse:

Quando você atualizar o BIOS, ele será redefinido para as configurações de fábrica, então você provavelmente precisará reconfigurá-lo.
Acho que há muitos erros em que as pessoas adicionam o SSDT criado no ACPI e, em seguida, não refletem o conteúdo de patches_OC.plist no ACPI.
Em relação ao VT-d=ON, que você apontou, acho que este guia precisará ser revisado em relação ao DMAR.

 

 

Obrigado pelas referências, especialmente as russas, que são difíceis de encontrar.
 

 

You are absolutely right, because I myself recently updated the BIOS on my Gigabyte Z790 and remapped everything using USBToolbox + UTBMap, after converting it to USBPorts with Hackintool, which in my opinion provides greater stability in terms of power delivery and avoids issues where a USB 2.0 device is not recognized on a USB 3.0 port. and ACPI tables can change as well — I actually saw this happen when I updated my Lenovo T14 some time ago, especially because it has two BIOS modes, one for Linux and one for Windows. on macOS, only the Windows mode (in the BIOS) works. I would like to help more, but I still need to go deeper into the subject; once I gain more knowledge from my software engineering degree, I’ll try to develop something for us to play around with here hahaha!! good luck!!