Hervé

The GPU...

If you want to consider a suitable build with SSDTs only, I suggest you post the raw/vanilla DSDT extracted from BIOS and the patched one. We'll then be able to examine the differences between them and suggest SSDT alternatives to the patched DSDT.

I wouldn't bother to try and use OpenCore or follow the Dortania guidance for an old C2D laptop. OpenCore has no proper support for CPU power management on these platforms. Stick to Clover, knowing that using SSDTs only is not restricted to OpenCore at all and can of course be used with other bootloaders such as Clover.

It's just a matter of framebuffer and matching of connectors with physical outputs. On rare occasions, certain outputs may not work at all. Patching the HDMI port to type 00080000 is only required to gain HDMI output, it's not required for video output.

 

All I can suggest is that you experiment with the various CFL/CML framebuffers and check them all out for HDMI output.

That's entirely cosmetic and bears no influence on your Hackintosh. Furthermore, it probably only appears in an add-on application such as About this Hack. If you want the proper CPU model to be reported, inject its CPUID in your OC config.

Seems your HP 400 G6 is fitted with a Comet Lake CPU given that the reported iGPU id is 0x9BC8.

 

It's a desktop platform, yet you use mobile framebuffer 0x3E9B0000 which natively defines the following 3 ports:

[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 not suitable given that 1st output port (i.e. connector con0) is defines as an LVDS port.

DP output appears to attach to 2nd connector con1 in your IOReg.

 

I would suggest you opt for the desktop framebuffer recommended in the WEG user Manuel, i.e. 0x3E9B0007 which defines the following 3 ports:

[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 should give you a better chance to obtain DP + HDMI output. If you do, identify which connector is DP and which connector is HDMI so that you may patch the HDMI one accordingly (i.e. set its type to 00080000) should you wish to enjoy HDMI audio.

 

You may also want to switch SMBIOS from iMac20,1 to MacMini8,1.

Try with SecureBootModel set to disabled.

 

https://github.com/OpenIntelWireless/itlwm/releases

 

Grab the alpha version labeled Sonoma14.4 if that's the macOS version you're running.

You're probably using an unsuitable kext for your TouchPad. Identify your model. Check what's available in existing bootpacks for your laptop model, similar ones or models with similar TouchPads.

Ok, you meant Sleep when on mains/AC.

 

What are your sleep settings? Did you disable hibernation?

Sleep on power ?

Ok, so dGPU remains disabled on warm reboots from macOS into Windows. There are only a few ways to address this:

1. you opt for the boor arg option rather than the patched ACPI code.
2. you call on your EGPU ACPI code on macOS shutdown to re-enable the dGPU; that should be handled by an event that you need to identify. Maybe one of those EV methods.
3. you power off your laptop when you want to boot Windows.

If you're using OpenCore that's normal. Only Clover or Chameleon apply ACPI patches at macOS level only by default.

You may want to consider switching to Clover on your Arrandale laptop. OpenCore does not provide adequate CPU power management for pre-Sandy Bridge CPUs whereas Chameleon/Clover do (Generation of C States/P States). This being said, if what you experience is instant wake on sleep, it usually is USB-ports related.

As for lack of brightness control and black screen on wake, your SSDT-PNLF is probably unsuitable.

You also need to have full graphics acceleration to be able to wake your laptop properly. Do you obtain it on this 1st gen HD model? If your model is not compatible, just forget it as a Hackintosh.

https://www.insanelymac.com/forum/topic/286092-guide-1st-generation-intel-hd-graphics-qeci/

Feel free to make one up if you cannot find any existing one.

You now call upon KBL/ABL framebuffer 0x87C00000:

ID: 87C00000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000078B
TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 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

 

Your patches, as found in your posted Opencore config file:

i.e.

[0], busId: 0x00, pipe: 8, type: 0x00000200, flags: 0x00000098 - Connector Analog DVI
[1], busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2], busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
00000800 00020000 98000000   --> analog DVI connector type
01050900 00040000 87010000
02040A00 00040000 87010000

 

Other than the strange patch of connector type 00020000 for con0 (which does not matter because con0 is not used, IOReg showing screen attached to con2), I fail to see the relevance of your other patches given that the values you inject are exactly the same as those natively defined in the framebuffer. As such, you most definitely do not patch any connector's pipe and you most definitely do not patch any property of the connector used for your LG TV.

 

Since that you've now opted for a KBL/ABL framebuffer which attaches your screen to con2, why don't you just adjust con2's pipe to 0x12?

framebuffer-patch-enable        1               NUMBER
framebuffer-con2-enable         1               NUMBER
framebuffer-con2-pipe           12000000        DATA

 

What version of Sonoma?

What version of OpenCore?

Try and set SecureBoot to disabled rather than default. I understand that's required for Sonoma 14.4.

Sonoma guide revised for version 14.4 (new wireless kexts) as detailed in thread linked right above.

Revised wireless kexts for Sonoma 14.4, the previous ones not providing wifi service beyond Sonoma 14.3. OCLP 1.4.1 or later required too.

Wifi_kexts_Sonoma_14.4.zip

Try and change con1's pipe to 0x12.

Doesn't seem to be a standard disk or USB disk but some form of virtual setup. This matter is unrelated to the boot loader but your platform arrangement. A VM it would seem?

Released Mar 7th, 2024.

Build 23E214

 

Enhancements, bug fixes ans security updates. Safe to install on our Hackintosh platforms.

Note that it's important to update wireless kexts IO80211FamilyLegacy + IOSkywalkFamily to new versions tuned for Sonoma 14.4 (kexts used up to 14.3 no longer work). No wifi without those revised kexts. All details are available here in our dedicated thread on the matter.

 

Also released at the same time:

• macOS Ventura Security Update 13.6.5 (build 22G621)
• macOS Monterey Security Update 12.7.4 (build 21H1123)

View full article

No idea what you mean by colour being "funny". If colours look funny to you on screen, maybe you just need to tune/calibrate your screen profile or use a different one.

 

IOReg shows KBL framebuffer 0x59120000, yet you still inject patches to set con0/con1/con2 to DP, which is what they natively are... 

ID: 59120000, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000110B
TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 115 MB, MAX OVERALL: 116 MB (122171392 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
01050900 00040000 87010000
02040A00 00040000 87010000
03060A00 00040000 87010000

No harm of couse, just totally useless.

Good, thanks for the feedback.

The WEG manual details the connectors patches very clearly and as follows; I really don't know where you copied your values from...

framebuffer-conX-enable (enabling patches for connector X)
framebuffer-conX-index
framebuffer-conX-busid
framebuffer-conX-pipe
framebuffer-conX-type
framebuffer-conX-flags
framebuffer-conX-alldata (completely replace the connector)
framebuffer-conX-YYYYYYYY-alldata (completely replace the connector, if the current framebuffer matches YYYYYYYY)
Where X is the connector index.
Alldata patches can patch multiple connectors in sequence by putting them in a single string and specifying the index of a connector to start with. The string length should be a multiple of 12 bytes (the length of a single connector)

 

You may have missed that 12-bytes alldata property is comprised of index + busid + pipe + type + flags. I specified the size of each element in my previous post. This parameter can cover multiple connectors as long as you specify a multiple of 12 bytes and these will cover the specified connector and the following multiple-1 connectors.

 

For instance:

framebuffer-con0-alldata    AAAAAAAABBBBBBBBCCCCCCCCLLLLLLLLMMMMMMMMNNNNNNNNXXXXXXXXYYYYYYYYZZZZZZZZ    DATA 

is the same as

framebuffer-con0-alldata    AAAAAAAABBBBBBBBCCCCCCCC    DATA
framebuffer-con1-alldata    LLLLLLLLMMMMMMMMNNNNNNNN    DATA
framebuffer-con2-alldata    XXXXXXXXYYYYYYYYZZZZZZZZ    DATA

and

framebuffer-con1-alldata    DDDDDDDDEEEEEEEEFFFFFFFFRRRRRRRRSSSSSSSSTTTTTTTT    DATA

is the same as

framebuffer-con1-alldata    DDDDDDDDEEEEEEEEFFFFFFFF    DATA
framebuffer-con2-alldata    RRRRRRRRSSSSSSSSTTTTTTTT    DATA

Note that you can't patch con0 and con2 (without patching con1) in a single 24-bytes alldata injection.

 

This being said, experiment with iGPU properties injections such as this:

AAPL,ig-platform-id        00001659        DATA   (-> KBL framebuffer 0x59160000)
AAPL,slot-name             Built-in        STRING (-> this is purely cosmetic)
force-online               1               NUMBER (-> same as igfxonln=1 boot-arg)

 

Given that your screen appeared attached to connector con1 in a previous IOReg extract, it's fair to say that you may experiment with any other framebuffer that has con1 as DP by default. These include:

Desktop:

• 0x59120000 (the recommended framebuffer for KBL desktop but does not seem to suit you)
• 0x59230000
• 0x59260000
• 0x59260007 (watch, max stolenmem set to 79MB so DVMT must be 96MB, else KP most probably)
• 0x59270000

Laptop:

• 0x59160000 (this is the default framebuffer if you do not inject any specific AAPL,ig-platform-id property)
• 0x59160009
• 0x591C0005
• 0x591E0000
• 0x591E0001
• 0x59260002
• 0x59270004
• 0x59270009
• 0x87C00000
• 0x87x00005

 

Mobile framebuffer 0x591B0000 defines 3 ports: LVDS + HDMI + DP so, if you use that one, you'll have to patch con1 to DP by adding the following properties:

framebuffer-patch-enable     1               NUMBER
framebuffer-con1-enable      1               NUMBER
framebuffer-con1-type        00040000        DATA

 

If you do not get anywhere with any of those framebuffer and default/native device id 0x5912 (that of your particular iGPU), then you may add the following property:

device-id        0x16590000         DATA

and start your experimentation again with all those frame buffers above.

Then, you may consider doing it all again with other device ids but that's a rather unusual thing to do. Supported device ids are listed in the WEG user manual.

 

If nothing works out to provide you 4K@60Hz, you may then consider patching connector's Flags but I'm dry on that one; never had to. This would be done with the following additional properties:

framebuffer-patch-enable        1               NUMBER
framebuffer-conX-enable         1               NUMBER (-> where X is target connector
framebuffer-conX-flags          XXXXXXXX        DATA   (-> where X is target connector and XXXXXXXX target flags value)

 

NB: Please note that you never enter any space in DATA values; spaces are simply displayed by tools such as OCC or CC for ease of reading.

 

Good luck.