Hervé

Normally, all you'd need is to ensure that the connector type of the port used for HDMI output is set to HDMI (00080000). In the config file of the pack you linked to, I see: AAPL,ig-platform-id 00001219 DATA framebuffer-patch-enable 01000000 DATA framebuffer-con1-enable 01000000 DATA framebuffer-con1-alldata 01050900 00080000 87010000 02040A00 00080000 87010000 DATA SKL framebuffer 0x19120000 is defined as follows: ID: 19120000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000110F TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Model name: Intel HD Graphics SKL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [255] busId: 0x00, pipe: 0, type: 0x00000001, flags: 0x00000020 - ConnectorDummy [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP FF000000 01000000 20000000 01050900 00040000 87010000 02040A00 00040000 87010000 So, if your HDMI output registers against con1 or con2, you should be Ok. What does it show in IOReg? I also noticed that SMBIOS was set to laptop model (MBP13,3). So you may want switch to SKL framebuffer 0x19160000 instead and see how that goes. ID: 19160000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000090F TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Model name: Intel HD Graphics SKL 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 I've no issue getting HDMI audio out of my Skylake/HD520 Dell Latitude E7270 laptop (ALC293 codec, layout-id 11) under Monterey with the following iGPU properties (and only those), SMBIOS MBP13,1 and igfxonln=1 boot arg: AAPL,ig-platform-id 00001619 DATA framebuffer-patch-enable 1 NUMBER framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA hda-gfx onboard-1 STRING Maybe you should remove those extra properties dealing with HDMI.

Well, it sure is seen in IOReg: And, from what I see, you appear to inject suitable properties. Maybe be you ought to rename your ACPI device from WL00 to ARPT. See if that makes any difference. You could also try a different SMBIOS profile to see if it makes any difference though I should not think so. MBP13,x/14,x/15,x sure support the card normally.

You need to follow the required process for Broadcom BCM4350 cards as detailed here. But if the wifi card is not even detected, that probably won't do much good. Maybe hardware is faulty. Post a zipped IOreg extract taken from IORegistryExplorer.

Congrats on learning by yourself, sort of...

As stated before, download one of my most recent E6230 packs, open up the Clover config with CC and you'll see for yourself; it's really not difficult if you make a little effort to learn by yourself.

If you download a Clover bootpack from one of my existing E6230 guides and open the config file with CloverConfigurator, you'll see what to do and how it's done. Look up the Device tab on the left, the the Properties area at bottom right:

Released August 22nd, 2023. Build 23A5328b. Smooth and straightforward update using the same principles applied before. New wallpapers and screen savers with this 6th beta.

Exact same process; you may use CloverConfigurator. Property injection is done in the exact same way in the config file.

All you really have to do is grab an existing config and look it up with apps such as OpenCoreConfigurator (or otherwise) and do the same. Just make sure to target the correct IO locatoin/device path by verifying things in IOReg 1st. You may use apps such as IORegistryExplorer to that effect.

Plenty of existing threads on the matter. See here for instance. in your bootloader's config, inject device property declaring your card compatible with Broadcom BCM4360 (14e4:43a0). inject AirPortBrcmFixup kext. make sure you use a suitable SMBIOS profile (eg: MPB12,1) or -no_compat_check boot arg if you're using MBP9,x/MBP10,x profile.

It's based on Broadcom BCM4352, so, apply the necessary patch. It's never been natively supported. https://osxlatitude.com/forums/topic/11138-inventory-of-supportedunsupported-wireless-cards-2-sierra-ventura https://github.com/khronokernel/IO80211-Patches

Ok. So you use CFL mobile framebuffer 0x3EA50009 which is natively defined as follows: ID: 3EA50009, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00830B0A 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: CamelliaV3 (3), 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: 0x000001C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 You patch it using the following properties: in particular, you patch your connectors like this: con0: 00000800 00080000 98010000 con1: 01050900 00080000 C7010000 con2: 02040A00 00080000 C7010000 Considering your computer is a mini desktop with no built-in LCD, there is absolutely no value in patching connector con0 the way you do. For connectors con1 and con2, you simply set their type to HDMI (00080000) and that's Ok, it's a must for HDMI audio to work. You also patch the framebuffer's flags: FB flags: 4A0B8300 To what purpose do you do that? What does this new value bring? Is it something you obtain through Hackintool?? Ever considered not patching this and simply use the default value?

You certainly could install OS X and early macOS versions on Dell laptops with Legacy BIOS. Chameleon, Enoch and Clover certainly supported this and Clover still does. Opencore natively requires UEFI mode though it could be tuned to run and boot on older systems with legacy BIOS mode only. No idea if recent versions still support this. Why would you want to run in legacy BIOS mode? Win7 fully supports UEFI mode. From memory, BIOS just had to provide some specific functionality but it eludes me now.

Intel i5-10210U is not a 7th gen. Kaby Lake CPU but a 10th gen. Comet Lake one. It's fitted with UHD 720 graphics carrying id 0x9b41 (which is not natively supported). Why you would want to apply KBL settings (as shown in your "BRIX" IOReg) to the iGPU is a bit of a mystery and don't expect this to work. IOReg "BRIX w: sound" correctly shows CFL/CML framebuffer layout 0x3ea50009 being used. If you only use 1 video output and that's your HDMI, then this is what registers against connector con1 (FB@1). And you also injects the correct connector type (HDMI 00080000) in your config by the look of things. Whatevergreen User Manual states that the following iGPU ids are supported, as shown in the CFL framebuffer kexts: <key>IOPCIPrimaryMatch</key> <string>0x3E9B8086 0x3EA58086 0x3EA68086 0x3E928086 0x3E918086 0x3E988086 0x9BC88086 0x9BC58086 0x9BC48086</string> Your IOReg shows you fake/inject CFL iPU id 0x3e9b, maybe you should try and fake one of the following CML ids instead: 0x9bc4, 0x9bc5 or 0x9bc8. Though I doubt it'll make any improvement... If you don't use it, try and add boot arg igfxonln=1. Ideally, post a zipped copy of your bootloader's EFI folder (config file + ACPI & texts folders).

-> moved to Latitude 3000 series section. Check existing Latitude 3400 threads. I understand the EFI posted by @davidfrei7as here provided a fully working laptop.

'can't remember if screen mirroring is enabled by default in VESA mode but it really does not matter. It's not the proper way to run macOS, so... no point wasting any time on that.

Maybe you ned to inject your screen's EDID value. See our FAQ topic on the matter.

KBL HD620 with id 0x5916 is natively supported, even in Sonoma. FYI, if you checked the KBL driver in macOS 14.0 beta, you'd see the following iGPU ids: <key>IOPCIPrimaryMatch</key> <string>0x59128086 0x59168086 0x591B8086 0x591C8086 0x591E8086 0x59268086 0x59278086 0x59238086 0x87C08086 0x3E9B8086 0x3EA58086 0x3EA68086 0x3E918086 0x3E928086 0x3E988086 0x9B418086 0x9BCA8086 0x9BCC8086 0x9BC88086 0x9BC58086 0x9BC48086</string>

This is a complete (bad) joke, right? Booted OS was Big Sur (kernel 20.6.0, build 20G1426) and your OC config + IOReg show you're injecting Skylake settings! SKL framebuffer 0x10160000 and SKL iGPU id 0x1916... So, not only are you incorrectly using 6th gen. Skylake settings on a 7th gen. Kaby Lake laptop, must we also remind you that Skylake graphics are unsupported since Ventura? And it was also stated before that you should be using MBP15,2 SMBIOS, not MBP15,3. If you follow what was previously suggested, I'm sure you'll get somewhere... Use the correct settings in your config file, save it and make sure to reset NVRAM at OC Picker when you reboot.

What happens if you disable hibernation as described in our FAQ topic?

Released August 8th, 2023. Build 23A5312d. As usual, no OTA update offered when running with MBP15,2 SMBIOS and had to reboot temporarily with iMac19,1 SMBIOS. Otherwise, completely smooth update.

What's not working for iGPU? No HDMI output or freeze/KP on plugging/unplugging the HDMI cable? You sure got the correct patch in place. I'm a little confused when you say you get a black screen on putting the computer to sleep? What else did you expect? Does it not go to sleep? Or do you mean you get black screen on wake? In which case, what if you wait something like several (long) minutes (but under 5mins)?

Absolutely no need to add any folder called MacOSX, no. If you're building your USB installer from Windows, consult our FAQ section where you'll find a dedicated topic on the matter.

If you really want to be on the safe side of things, you may of course try/test your revised setup out of a USB boot key, then apply the proven setup to your internal disk. But we're only talking kexts updates here, not experimentation with new kexts.

I suggest you read up the Dortania documentation as a general refresher course. Why consider complicated routes for kexts when all you need is the simplest path? Just make sure to reset NVRAM at OC Picker when you reboot. Re: HD4600 iGPU, all you need is the usual that's been used for the last 10 years and nothing else: AAPL,ig-platform-id 0600260A DATA device-id 12040000 DATA framebuffer-patch-enable 1 NUMBER framebuffer-con1-enable 1 NUMBER framebuffer-con1-pipe 12000000 DATA framebuffer-con1-type 00080000 DATA