ASRock H310M-HDV - dual monitor problems

[brumas2025]

44 minutes ago, deeveedee said:

Sorry about the confusion...

 

I was asking you to swap the port types for con1 and con2:  framebuffer-con1-type = <00040000> (DP) and framebuffer-con2-type = <00080000> (HDMI)

 

See the attached config.plist with the following connector types:

• con0: DP (for VGA if it works)
• con1: DP (for DVI-D -> VGA)
• con2: HDMI (for HDMI -> HDMI)

I tried this config - DVI works, HDMI doesn't.

[deeveedee]

@brumas2025 Based on your test results, the only tested solution that 'works' for both displays is when the port types are all HDMI - is that correct?

Edited January 2 by deeveedee

[brumas2025]

12 minutes ago, deeveedee said:

@brumas2025 Based on your test results, the only tested solution that 'works' for both displays is when the port types are all HDMI - is that correct?

it turns out that yes,.... maybe it's worth stopping.... (I'm already used to turning the monitor button on and off)😀

Edited January 2 by brumas2025

[deeveedee]

I'd like to summarize the test results so far. Please let me know if any if this is wrong:

• Motherboard's DVI-D and HDMI ports work. VGA port does not work in both macOS and but it does work in Windows.
• So far, dual displays work in macOS only when using the DeviceProperties from my HackMini8,1 with mobile framebuffer 0x3e920000 with all connector port types = HDMI
• After booting macOS, displays have horizontal black lines. This is 'fixed' by powering either of the displays off and then on again.
• Increasing shared memory in BIOS does not change display behavior
• Adding framebuffer fbmem properties does not change display behavior

 

EDIT: I'll stop if you stop. I think your solutions (first your wireless display and now turning a display off and then on) are clever fixes. I am guessing that you have achieved more with this motherboard and macOS than many (if not most) other users.

Edited January 2 by deeveedee

[deeveedee]

@brumas2025 If you still have any testing patience left, you could test all of the 3-connector Coffee Lake / Comet Lake framebuffers (AAPL,ig-platform-id). Leave all other DeviceProperties unchanged and change only AAPL,ig-platform-id for each test. I provide the list of platform ids in fermento's thread.

[brumas2025]

14 minutes ago, deeveedee said:

I'd like to summarize the test results so far. Please let me know if any if this is wrong:

• Motherboard's DVI-D and HDMI ports work. VGA port does not work in both macOS and Windows.
• So far, dual displays work in macOS only when using the DeviceProperties from my HackMini8,1 with mobile framebuffer 0x3e920000 with all connector port types = HDMI
• After booting macOS, displays have horizontal black lines. This is 'fixed' by powering either of the displays off and then on again.
• Increasing shared memory in BIOS does not change display behavior
• Adding framebuffer fbmem properties does not change display behavior

 

EDIT: I'll stop if you stop. I think your solutions (first your wireless display and now turning a display off and then on) are clever fixes. I am guessing that you have achieved more with this motherboard and macOS than many (if not most) other users.

• Motherboard's DVI-D and HDMI ports work. VGA port does not work in both macOS and Windows.  = VGA port work in Windows.
• So far, dual displays work in macOS only when using the DeviceProperties from my HackMini8,1 with mobile framebuffer 0x3e920000 with all connector port types = HDMI =yes.
• After booting macOS, displays have horizontal black lines. This is 'fixed' by powering either of the displays off and then on again. = yes.
• Increasing shared memory in BIOS does not change display behavior = yes.
• Adding framebuffer fbmem properties does not change display behavior = yes.

Thanks for the help. If it wasn't for your configuration, I wouldn't have achieved dual monitor operation.

I'm ready to test more if you have any ideas..

Edited January 2 by brumas2025

[deeveedee]

@brumas2025 In addition to experimenting with the complete list of 3-connector framebuffer platform IDs as I indicated here, we could try experimenting with connector flags.  This ventures into the dark arts.  I know enough to be dangerous and have successfully fixed graphics problems by changing connector flags (framebuffer-conX-flags), but it's definitely more luck than skill (for me).  If we go down this path, it's a last resort.

 

I asked ChatGPT for any other suggestions and received the following reply: change framebuffer-con0-type to 0.  I've never tried this before.  The DeviceProperties to test this are attached.  I'm fairly certain that ChatGPT has no idea, but it's more than I have for you at this time.

 

EDIT: ChatGPT also suggested swapping the Main and Extended display in System Settings > Displays.  Try this as a temporary change just to see if your graphics behavior is affected by the display arrangement.

config 0006.plist.zip

Edited January 2 by deeveedee

[brumas2025]

7 hours ago, deeveedee said:

@brumas2025 

EDIT: ChatGPT also suggested swapping the Main and Extended display in System Settings > Displays.  Try this as a temporary change just to see if your graphics behavior is affected by the display arrangement.

1) I tried it with different values - the results are in the table.  

2) In addition, I swapped the displays - nothing has changed.

3) I tried your example 0006 - also without any changes.

 

Quote

  These are the test results.

 

[Asural]

9 minutes ago, brumas2025 said:

1) I tried it with different values - the results are in the table.  

2) In addition, I swapped the displays - nothing has changed.

3) I tried your example 0006 - also without any changes.

 

  These are the test results.

 

I've verified the attached EFI, but it only has ACPI for Install and no SSDT to add post-install.
Please refer to this guide.
1. Start with Dump DSDT (P).
2. Create all except FakeEC Laptop.

 

Creating one item will create a Resolt folder and create an SSDT and plist. It's convenient to rename the plist for OpenCore to the SSDT name.
Items that cannot be created will simply result in an error, so proceed to the next step.

 

Once you have created all the items, press Q to exit and copy the Resolt folder to your MacOS using a USB stick or similar.
Please attach the Resolt folder you created on MacOS.
 

[brumas2025]

40 minutes ago, Asural said:

I've verified the attached EFI, but it only has ACPI for Install and no SSDT to add post-install.
Please refer to this guide.
Please attach the Resolt folder you created on MacOS.
 

Following your instructions, I downloaded the program, run it in Windows, pressed the buttons (some incomprehensibly required a path) I'm applying the result.

Results.zip

[Asural]

11 minutes ago, brumas2025 said:

Following your instructions, I downloaded the program, run it in Windows, pressed the buttons (some incomprehensibly required a path) I'm applying the result.

Results.zip 74.62 kB · 1 download

You worked quickly, but it seems I didn't get my point across.
Every time you create an item, an SSDT patch is added to patches_OC.plist, so it's difficult to tell which patch is which SSDT item.
Every time you create an item, change patches_OC.plist to NameOfSSDT.plist.
 

Please delete the Windows Resolt folder and try again.
 

[brumas2025]

14 minutes ago, Asural said:

Please delete the Windows Resolt folder and try again.

You are my savior! I made a folder with patches from Windows and, miraculously, both monitors booted perfectly, no need to click anything...

Now my problem is solved, I think 100%.

I am attaching a folder..

EFI.zip

iMac 03-01-26.ioreg

Edited January 3 by brumas2025

[deeveedee]

@Asural and @brumas2025 Well done!  It didn't occur to me that the black lines in the display would be caused by a missing (or incorrect) ACPI patch.  Correct me if I'm wrong, but the DeviceProperties from here plus ACPI patches from SSDTTime creates a fully working solution.

 

Which SSDT fixed the "black lines" problem?

[brumas2025]

25 minutes ago, deeveedee said:

@Asural and @brumas2025 Well done!  It didn't occur to me that the black lines in the display would be caused by a missing (or incorrect) ACPI patch.  Correct me if I'm wrong, but the DeviceProperties from here plus ACPI patches from SSDTTime creates a fully working solution.

 

Which SSDT fixed the "black lines" problem?

I do not know which one of them - I have added several of them..

Quote

 

Edited January 3 by brumas2025

[brumas2025]

7 hours ago, brumas2025 said:

Now my problem is solved, I think 100%.

I wasn't happy for long, but after another reboot, the stripes reappeared.. so again I have to switch the HDMI monitor...😪

[deeveedee]

@brumas2025 You have the right attitude and perseverance for this problem solving.  What I love most about your efforts and @Asural's  efforts is that this is what "never giving up" looks like.  Keep tinkering.  The fact that patching ACPI temporarily "fixed" the problem is a clue.  Does clearing NVRAM (from Open Core boot menu) also temporarily "fix" the problem?

 

Switching the display off and then on is still a long way from where you started.  Well done.  Most would have given up a long time ago.  Not you.

[brumas2025]

10 minutes ago, deeveedee said:

@brumas2025 You have the right attitude and perseverance for this problem solving.  What I love most about your efforts and @Asural's  efforts is that this is what "never giving up" looks like.  Keep tinkering.  The fact that patching ACPI temporarily "fixed" the problem is a clue.  Does clearing NVRAM (from Open Core boot menu) also temporarily "fix" the problem?

 

Switching the display off and then on is still a long way from where you started.  Well done.  Most would have given up a long time ago.  Not you.

I analyze and come to the conclusion: sometimes my HDMI monitor does not start immediately after overloading, but then it goes to the desktop. and it probably just so happened that it started working when the other monitor booted up.   resetting the nvram does not help...

Thank you for your support, I couldn't have progressed without you.

Edited January 3 by brumas2025

[Asural]

22 minutes ago, brumas2025 said:

I wasn't happy for long, but after another reboot, the stripes reappeared.. so again I have to switch the HDMI monitor...😪

After updating the BIOS, your BIOS settings will likely be reset to factory settings, so please check your BIOS settings.
As pointed out elsewhere, you will need to modify DMAR by following this guide in order to turn on VT-d.
 

[Asural]

1 hour ago, brumas2025 said:

 

Thank you for your support, I couldn't have progressed without you.

The attached EFI does not reflect the ACPI contents of Results/patches_OC.plist, so the modified SSDT will not function properly.
Please overwrite config.plist with the contents of patches_OC.plist.

 

I will be working on the SSDT contents and DeviceProperties settings in the future, so please follow the contents of this post.
 

ADD:

Don't forget to reset the NVRAM after making the changes.
 

Edited January 3 by Asural

[brumas2025]

46 minutes ago, Asural said:

The attached EFI does not reflect the ACPI contents of Results/patches_OC.plist, so the modified SSDT will not function properly.
Please overwrite config.plist with the contents of patches_OC.plist.

 

I will be working on the SSDT contents and DeviceProperties settings in the future, so please follow the contents of this post.
 

ADD:

Don't forget to reset the NVRAM after making the changes.
 

I booted into Windows and made files with different names. attached.  

I didn't understand when I need to reset the nvram - after restarting from Windows?

Results 030126.zip

[Asural]

24 minutes ago, brumas2025 said:

I booted into Windows and made files with different names. attached.  

I didn't understand when I need to reset the nvram - after restarting from Windows?

Results 030126.zip 81.29 kB · 1 download

Be sure to reset if you modify any NVRAM items.
It's also a good idea to reset if you modify the contents of cnfiig.plist.
 

During the verification test, there is no need to delete the SSDT used during installation, but please use recreated patches, etc.

[brumas2025]

25 minutes ago, Asural said:

Be sure to reset if you modify any NVRAM items.
It's also a good idea to reset if you modify the contents of cnfiig.plist.
 

During the verification test, there is no need to delete the SSDT used during installation, but please use recreated patches, etc.
 

if I understood correctly, should I add one newly received aml file to the configuration and check?

[Asural]

2 hours ago, brumas2025 said:

if I understood correctly, should I add one newly received aml file to the configuration and check?

@deeveedee's question is "which SSDT caused the success?", so we first need to find the cause of the malfunction.

First, configure ACPI, then reset the NVRAM to see if it works properly.

 

Resetting the NVRAM will reconstruct the internal connections of the OS when you start up macOS.

OpenCore does not have access to all of the PC's NVRAM information, so it may erase Windows information needed by the PC.

In this case, start up Windows, then start macOS without resetting the NVRAM; it will work normally.

 

First, update the EFI, reset the NVRAM, and test the boot and display.

Next, check which step causes the display to malfunction.
 

ADD:

 I think the Sleep issue has been resolved in SSDT, so I recommend removing HibernationFixup.kext.
Test whether the behavior of Sleep changes with or without HibernationFixup.kext.
 

Delete -igfxhdmidivs from boot-arg as it is for a different CPU, and delete igfxfw=2 and include it in PciRoot(0x0)/Pci(0x2,0x0).
 

Edited January 3 by Asural

[deeveedee]

2 hours ago, Asural said:

Delete -igfxhdmidivs from boot-arg as it is for a different CPU

 

The boot-arg is for SKL, KBL and CFL platforms.  i3-9100 is Coffee Lake (CFL).  I agree that the boot-arg didn't help, but not because it's for a different CPU.

 

EDIT: I was reading this to see if I missed anything important.  According to Acidanthera, CPUs with device-id 0x3e91 (like i3-9100) should be "spoofed" as device-id 0x3e92.  This means that DeviceProperties for PciRoot(0x0)/Pci(0x2,0x0) should include 

device-id, data, <923e0000>

 

I'm not sure if this helps, but it's worth a try.

 

EDIT2: @Asural I'm not confident that the problem has anything to do with ACPI patching (I doubt it).  I think the fact that displays "worked" after new ACPI patches were included in the EFI was just a timing glitch.  Don't give up on the ACPI patches, since they'll only improve his hack, but I'd continue to think about settings / configuration that would affect display initiation timing.

 

@brumas2025 In your BIOS, do you have an option for "Fast Boot" or something similar?  If so, please make sure that this setting is "Disabled" in BIOS.

Edited January 3 by deeveedee

[Baio77]

 

Dagli screenshot di Hackintool che hai pubblicato vedo che i passaggi per mostrare la patch caricata all'avvio nell'EFI non sono stati eseguiti.

In questo modo Hackintool visualizza lo stato attuale della patch, che corrisponde a quanto letto in Ioreg.

 

Un esempio per spiegare cosa intendo.

 

 

 

If you see the Hackintool information here it does not match what ioreg says.

Edited January 3 by Baio77