Hervé

See here and use the latest versions of the kexts mentioned in the thread:
https://osxlatitude.com/forums/topic/13140-solved-dw1560-bluetooth-stopped-working

https://github.com/OpenIntelWireless/itlwm/releases
 
Grab the alpha version labeled Sonoma14.4 if that's the macOS version you're running.

Ok, so dGPU remains disabled on warm reboots from macOS into Windows. There are only a few ways to address this:
you opt for the boor arg option rather than the patched ACPI code. 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. you power off your laptop when you want to boot Windows.

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.

That would be perfectly normal since CFL framebuffer layout 0x3E9B0007 is for desktop computers and offer 3 x DP connectors but no LVDS connector for laptops:
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 You would need to patch connector con0 to laptop's settings to hope for your built-in screen to work. For instance to this:
00000800 02000000 98000000 as per CFL framebuffer layout 0x3EA50009 as I illustrated above.
 
Setting the framebuffer layout to mobile may help too.

You do reset NVRAM from the OC Picker after each config change, right?

That's where you get it wrong. To apply the bootpack, you have to run myHack and load/apply it with myHack, it's one of the option in the pop-down menu (called "Install Extra" from memory). Copying/pasting it to the USB key won't do.
 
Please note that T7250 is a little Merom CPU running at 2.0GHz and fitted with only 2MB L2 cache. Performance won't be great, even more so if you run off a mechanical HDD, whether 5400rpm or, preferably, 7200rpm.

You run with the config you used to install Big Sur on this unsupported platform which is using MBP11,1 SMBIOS. Whilst this allows you to keep Big Sur updated, my experience is that it prevents proper CPU power management. You should therefore make a backup of this config (for future use to update Big Sur) and revert SMBIOS to MBP9,2 or MBP10,2 and add boot flag -no_compat_check of course. Also make sure you've disabled hibernation as per the dedicated thread in our FAQ section.
 
You may also have opted for something incorrect when you applied the OCLP patch. But only you can tell us what you did in that respect...
 
NB: There is no limitation to 4 lines for your signature; you must be confusing OSXLatitude with InsanelyMac...

Audio should work with the exact same settings you previously had for Monterey. There should be no issue at all on that matter. Same applies to brightness control.
 
For Wifi and Bluetooth, you need to consult the information available on the ITLWM site. Development for Ventura remained at early alpha stage until very recently (I've not checked status for several weeks) so make sure to check the latest information published by the devs.

Means you need to fake Kaby Lake (KBL) graphics since Skylake (SKL) graphics are no longer supported, Apple having dropped support for all pre-Kaby Lake MacBook platforms (+ others) in Ventura.
Also look at the WhateverGreen User Manual and our GPU support thread.

Your posted IOReg shows:
external display on con2 (FB @2), not con1 (FB @1) con1 patched to HDMI type (as per your OC config) -> [...]con1-alldata 01051200 00080000 ... con2 patched to DP type (as per your OC config) -> [...]con2-alldata 02041200 00040000 ... If your external display on con2 is indeed HDMI, you need to patch its type accordingly, i.e. not to DP (0x0400) but HDMI (0x0800).
 
NB: No need to patch fbmem or stolenmem for Azul frame buffers (i.e. Haswell iGPU HD4200/HD4400/HD4600/etc.). You can remove those from your config and only retain the cursormem patch if you found it necessary (in case of cursor graphics corruption).

Don't hesitate to scrounge the Net before asking on forums...
 
CCC probably best avoided with Ventura; there are lots of unresolved known issues.
https://bombich.com/kb/ccc6/macos-ventura-known-issues
https://bombich.com/kb/ccc6/cloning-macos-system-volumes-apple-software-restore
https://www.reddit.com/r/MacOSBeta/comments/xah1pm/carbon_copy_cloner_mac_os_ventura/
 
My understanding is that you will not succeed trying to boot a cloned OCLP-patched Ventura installation; at best -if that works at all !- you would need to either:
1) clone your basic, i.e. unpatched, Ventura installation prior to OCLP patching; you may then patch your cloned disc.
or
2) unpatch your Ventura build, clone it, then repatch; and, of course, patch your cloned disc afterwards. 
 
Do consider that, since Big Sur -even more so with Ventura-, CCC (and other apps such as SuperDuper) are no longer reliable for macOS disc cloning, especially on Hackintosh running patched installations for unsupported hardware. Issues are related to (sealed and encrypted) snapshots. Many people have written about this if you care to search the Net.
 
Also consider alternative bootable disc cloning solutions for macOS Ventura (if such things do exist and they may not be free):
https://www.doyourdata.com/disk-copy/best-disk-clone-software-for-macos-ventura.html
https://www.doyourdata.com/disk-copy/make-bootable-backup-clone-for-mac.html
https://www.donemax.com/mac-disk-clone/clone-macos-ventura-to-external-hard-drive.html

Did you check the default DVMT settings of your 7480? Under macOS, DVMT must usually be set to 64MB or 96MB to obtain 4K output; afaik, you won't get it if DVMT is set to 32MB even if you patch the DVMT settings (fbmem + stolenmem) through properties injection.
 
With DVMT set to 64MB or 96MB (BIOS mod through Grubshell, see our FAQ topic on the matter or my E7270 guide), I can get 4K @24-30Hz out of HDMI and 4K@60Hz out of mDP on my Skylake/HD520 E7270 laptop. Can't see why it'd be different on your 7480, unless it's the TB port that's causing the issue under macOS of course.
 
Don't hesitate to post a zipped copy of your bootloader's EFI folder so that we can check your settings.
 
Do post your system's specs in signature since they're are 6th gen and 7th gen 7480...

I don't think it'd have any influence on Sleep/Wake but it certainly could on a boot time perspective but Samsung 970 Evo Plus was not natively supported unless firmware was updated; can't say which version but it'd be worth checking whether you run on the latest version or not:
https://semiconductor.samsung.com/consumer-storage/support/tools/

Is there any particular reason why, as suggested by PM, you won't uncomment the properties injection for the DW1820A? Without this injection, you're highly likely to encounter system reset or plain freeze at startup.

I looked at the patch you took inspiration from and can only make the following comments:
it's something dating back to 2016 it's something that applied to an Asrock Skylake desktop motherboard I'm not entirely convinced that the patch that consists of simply removing the entire method _L6F is fully applicable to your Dell Comet Lake laptop but Ok if you've established your high CPU utilisation derived from the same problem of having kernel_task process running at 100% CPU load of course. Did you see a similar ACPI _L6F related error message in your boot log? I really must ask what makes you so sure about your statement  re: bugged UEFI firmware...
 
Anyway, as a simpler alternative to DSDT patching, I would suggest that, in you Bootloader config, you simply rename method _L6F to XL6F (or _L6X) through the following ACPI patch/renaming:
Find (Hex): 5F4C364600 Replace (Hex): 584C364600 (or 5F4C365800) because _Lxx methods are for interrupts xx (in hex).
 
The only way you could remove method _L6F from ACPI through an SSDT would be to replace the entire _GPE scope that contained the method by a new one that would not contain it. It's feasible of course but really complicated (several instances of Scope (_GPE) in your DSDT, need to rename all methods and/or variables the scopes contain, etc.) when you may simply isolate/void method _L6F through the above renaming. Of course, you could also consider renaming _L6F to, say, XXXX to be more radical:
Find (Hex): 5F4C364600 Replace (Hex): 5858585800  
Failing that, just use a patched DSDT where method _L6F has been removed.

I'm not certain you need to change pipe value or inject flags for your iGPU connectors. Injecting/faking the iGPU's own device id is, of course, of no use. I also believe injecting enable-hdmi20 to be inapplicable on platforms that only support HDMI 1.4...

 
All I do on my Skylake i7-6600U/HD520 E7270 is inject HDMI type (00080000) to con1 and use boot arg igfxonln=1. I have adjusted DVMT pre-allocated memory through Grub shell-based BIOS data mod. Try that and see if these settings makes a difference. I detailed my observed behaviour with HDMI in my E7270 guides.
 
I believe all you need to inject is:
AAPL,ig-platform-id 00001619 DATA AAPL,slot-name Built-in STRING framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA -> not needed if you change DVMT pre-alloc mem to 96MB through Grubshell framebuffer-stolenmem 00003001 DATA -> not needed if you change DVMT pre-alloc mem to 96MB through Grubshell framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA  

Of course, you need to adjust your config; that's the little pleasures every month with every new OC version.
https://www.insanelymac.com/forum/topic/349151-how-to-opencore-073-074-differences/
https://www.insanelymac.com/forum/topic/349485-how-to-opencore-074-075-differences/

Of course, you need to adjust your config; that's the little pleasures every month with every new OC version.
https://www.insanelymac.com/forum/topic/349151-how-to-opencore-073-074-differences/
https://www.insanelymac.com/forum/topic/349485-how-to-opencore-074-075-differences/

Your IOReg shows next to nothing under device HDEF so, indeed you have no audio enabled. Assuming there's nothing in BIOS to block this, you should consider implementing the HPET IRQ patch. That should fix your audio issues.
https://dortania.github.io/Getting-Started-With-ACPI/ssdt-methods/ssdt-easy.html#so-what-can-t-ssdttime-do
 
Did you fix your config conflicts regarding codec layout id? Because the config you posted in port #1 showed:
codec layout 11 being injected in Device Properties codec layout 3 being injected through NVRAM boot arg
 
You need to decide on one method or the other, not both and opt for the correct layout of course!

I'm pretty confident your issue derives from using that single unified SSDT which I believe to be incomplete. I would advise you gradually get rid of this SSDT and return to a more standard set of patched SSDTs. You'll then avoid such issues as that you currently encounter.
 
When it comes to USB ports power settings, your single SSDT contains the following code and nothing else:
        Device (USBX)         {  [...] Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific Method             {                 [...] Return (Package (0x08)                 {                     "kUSBSleepPowerSupply",                      0x13EC,                      "kUSBSleepPortCurrentLimit",                      0x0834,                      "kUSBWakePowerSupply",                      0x13EC,                      "kUSBWakePortCurrentLimit",                      0x0834                 })             }  
E5470 is Skylake, right? On my Skylake E7270, I also inject the attached standard XHC/USB3.0 patched SSDT which defines the following power settings:
                "AAPL,current-available",                  0x0834,                                          "AAPL,current-extra",                  0x0898,                                          "AAPL,current-extra-in-sleep",                  0x0640,                                          "AAPL,max-port-current-in-sleep",                  0x0834                         
Try and add that XHC patched SSDT to your setup.
SSDT_XHC.aml.zip

All off-topic posts deleted. Guys, I remind that this topic is about HDMI audio...
 
Looking at the zipped EFI provided above, I can se that the OC config lacks the required, yet well-known, properties injection for HDMI audio: that of the HDMI connector type for the relevant iGPU connector/port (usually con1).
framebuffer-con1-enable       1        NUMBER framebuffer-con1-type         00080000 DATA If audio is working from the onset, the above will enable HDMI audio. Of course, the exact connector used by HDMI output needs to be verified and adjusted as required (con2, con3).
 
See the Whatevergreen user manual for details.

Nope, what you get/see is perfectly normal. Mainstream multi-core CPUs have always been reported as single CPUs with n cores, something that totally reflects the hardware. Here's my own i7-based E7270 SysInfo:

 
In no way does "dual-core/4 threads CPU" mean 2 x processors and 4 cores; you misunderstood things.

Look up my recent Mojave and Catalina updates in my E6220 guide. They offer an installation free of patched DSDT, in UEFI mode and the posted pack contains all the SSDT tables + ACPI renamings in the Clover config to cater for brightness keys. You'll find the necessary code for Fn-UP/Fn-DOWN operation in the SSDT-Q66 table.

Updates are not offered when running macOS with the -no_compat_check boot arg. There are 2 x pre-requisites for obtaining Big Sur update offers:
the SMBIOS of a Mac model compatible/supported by Big Sur (MBP11,x minimum). a SIP value that does not enable Apple Internal; it's disabled by default and must be kept disabled (bit #5 of SIP value, see here for details).