HP All-in-One (Coffee Lake): no display on built-in/internal screen

[Tridon]

Hi, I have a similar issue as discussed here with an All-in-One and have followed the suggestions, but I am unable to get the internal display to work.

 

If I have graphic acceleration enabled, the internal display switches off 4 seconds into boot and the external display connected over HDMI works fine and is detected by Hackintool. I have taken a ioreg dump here, labeled "MM_with_external_display_only.ioreg".

If I disable graphic acceleration (by choosing an invalid platform id) the internal and external display (which is cloned/mirrored) are working but only the internal display is listed under Hackintool/Settings>>Display. I have taken another ioreg dump here, labeled "MM_with_accel_disabled_and_internal_display.ioreg".

 

It feels as though I am staring at the answer, but for some reason, I just can't make this work with both displays and graphic acceleration enabled neither can I make it work with acceleration enabled on the internal display.

 

I have read (and tried) framebuffer bus patching though I might've done it incorrectly.

I have tried injecting my internal display EDID to no avail.

 

Is there anything else that I can try ?

 

HP AIO, i7-8700T (UHD630) on Q370.

EDID Info.zip MM_with_external_display_only.ioreg MM_with_accel_disabled_and_internal_display.ioreg EFI.zip

[Hervé]

Maybe you're not using the correct graphics settings for a desktop Hackintosh. CFL framebuffer 0x3e920000 is a mobile layout which defines the following output ports:

ID: 3E920000, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000130B
TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes)
Model name: Intel HD Graphics CFL CRB
Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00040000 87010000

i.e. 1 x LVDS/eDP output and 2 x DP outputs.

 

Did you experience similar issues with the CFL layouts recommended for desktops, i.e. 0x3EA50000 and 0x3E9B0007? Cf. WEG user manual.

I would also recommend you try and identify the type of display connector used for your built-in/internal screen (DP? eDP? LVDS?) so that you may patch the appropriate framebuffer connector accordingly.

The CFL layout recommended for desktops is 0x3E9B0007. Layout 0x3EA50000 is the default one if nothing is specified in your config. Those define the following properties:

ID: 3E9B0007, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00801302
TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes)
Model name: Intel UHD Graphics 630
Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP
[3] busId: 0x06, pipe: 8, type: 0x00000400, flags: 0x000003C7 - ConnectorDP
01050900 00040000 C7030000
02040A00 00040000 C7030000
03060800 00040000 C7030000

This is a desktop layout which defines 3 DP outputs.

 

ID: 3EA50000, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00030B0B
TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes)
Model name: Intel HD Graphics CFL CRB
Camellia: CamelliaDisabled (0), Freq: 0 Hz, FreqMax: 0 Hz
Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
00000800 02000000 98000000
01050900 00040000 87010000
02040A00 00040000 87010000

This is a mobile layout which defines 1 LVDS/eDP output and 2 x DP outputs.

 

Of course, Mac mini is not an ideal SMBIOS either given that such models do not come with built-in screen; I'd recommend you opt for a Coffee Lake iMac/iMacPro SMBIOS instead.

 

Intel i7-8700T CPU integrates UHD 630 iGPU with native PCI id 0x3E92; as such, no need to inject any device-id in your config; id 0x3E92 is fully and natively supported by macOS CFL drivers. Your OC config is Ok on that front. On the other hand, I find it to be incorrect on the following front:

 

You inject the framebuffer layout incorrectly; due to the endianness used by Apple, make sure you specify all hexadecimal properties in "reverse bytes order" if you'll allow the expression. As such, framebuffer 0x3e920000 is injected as follows:

AAPL,ig-platform-id        0000923E        DATA

 

I would suggest you experiment with the correct CFL framebuffer (and nothing else) to begin with and before attempting to patch framebuffer's connectors.

[Tridon]

I wanted to try and troubleshoot this by myself (and learn in the process) but I'm still struggling.

 

I've tried reading every guide and forum post that I thought would help, but obviously, I am doing something wrong.

I tried it again by changing to iMac19,1 SMBIOS and both the recommended device-ids : 3E9B0007 / 3EA50000

3E9B0007 : External display lights up, internal display switches off after the first few seconds

3EA50000 : Gives an error, cannot boot to desktop.

 

Basically, when an invalid framebuffer(example : 3E920000) is supplied, the internal display lights up and the external display is cloned, however, there is no graphic accceleration (7 MB issue !)

When supplied with a correct framebuffer,(example : 0000923E, 07009B3E)  graphic acceleration is enabled but only the external display works, with the internal screen switching off.

 

Any ideas what I could do next ? I believe, I have to do the correct framebuffer bus patching but I cannot figure it out.

Would it be be possible to examine my ioreg files that I posted earlier and point me in the right direction ?

[Tridon]

I've tried your advice of every framebuffer for CoffeLake UHD 630 but only have a black screen.

Booting with an invalid framebuffer (12345678) magically works on the internal display, though it is without acceleration.

 

Can i extract the bus id + pipe from a ioreg dump(attached below) here and then use it for correctly patching the framebuffer ?

iMac12345678.ioreg

[Hervé]

IOReg taken with invalid/dummy framebuffer layout 0x12345678 is useless. You need to take an IOReg once booted with a valid CFL layout. You can do that either after having setup screen sharing and accessing the Hack from another computer or by using an external HDMI/DP display.

[Tridon]

@Hervé

Thank you for the suggestion of using screen sharing, I did that successfully !

I've tried it with 07009B3E, first with the external display connected and then with the external display disconnected. On both attempts, I get a black screen. I'm attaching those ioreg  dumps here.

 

Curiously enough, as you'll see from 'iMacremote', there is no display detected. So, the internal display is just not getting detected. What I cannot understand is how the internal display works with an invalid framebuffer.

I've tried to read this : https://dortania.github.io/OpenCore-Post-Install/gpu-patching/intel-patching/busid.html and apply it but again, I must be doing something wrong.

 

What else can I try ? The more challenging this gets, the more I want to fix it !

 

iMacremote.ioreg iMacexternalmonitor.ioreg

[Hervé]

When you boot with an invalid framebuffer, macOS operates in what is called VESA mode; consider it like Windows safe mode if you want a comparison. In this mode, you have no graphics driver loaded and the system operates in a very basic graphics mode. This is fully reflected in IOReg where you see no framebuffer whatsoever:

 

When you boot with a valid (CFL) framebuffer, the driver loads/applies the framebuffer's defined output ports. Those will be reflected in IOReg and include the displays against/under their associated connectors (i.e. video output ports), provided these are fully and properly detected. In the case of your internal screen, regretfully it is not (no display registers again FB@0, FB@1 or FB@2):

 

On the other hand, your external display does register as an HDMI monitor attached to 3rd output port FB@2:

 

Now, looking at each output port when you boot with valid CFL layout 0x3e9b007, I see that all 3 x video output ports (i.e. connectors) are set to HDMI type (00080000). In all likelihood, your internal screen is LVDS or DP/mDP and you should try and experiment with that. It should be attached to 1st output port, i.e. FB@0 aka con0. As explained in my previous post, CFL framebuffer layout 0x3e9b007 defines 3 x DP ports. I would suggest you revisit your bootloader's config file and, in the iGPU device properties section, you experiment with con0's type as follows:

framebuffer-con0-enable        1               NUMBER
framebuffer-con0-type          XXXXXXXX        DATA

where XXXXXXXX corresponds to the desired port type:

• 00080000 -> HDMI
• 00040000 -> DP/mDP
• 02000000 -> LVDS/eDP
• 04000000 -> digital DVI (or is it dual link DVI ?)
• 00020000 -> analog DVI (or is it single link DVI?)

LVDS/eDP type being the most likely target value. If you stop injecting a port type for con0, you'll revert to default DP type but I assume you may have already tried that.

 

You may also require to inject different values for the connector's flags but I'm not so familiar with that. Say, inject the same flags as for the built-in display of a CFL mobile layout:

framebuffer-con0-flags        98000000        DATA

 

Or disable/play with AGPM, that's another possibility.