Hervé

Did you try and experiment with other CFL mobile framebuffers? For instance FB 0x3EA50004: ID: 3EA50004, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00E30B0A TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel Iris Plus Graphics 655 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: 0x00000498 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 00000800 02000000 98040000 01050900 00040000 C7030000 02040A00 00040000 C7030000 or 0x3EA50006: ID: 3E9B0006, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00131302 TOTAL STOLEN: 39 MB, TOTAL CURSOR: 512 KB, MAX STOLEN: 39 MB, MAX OVERALL: 39 MB (41422848 bytes) Model name: Intel UHD Graphics 630 Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 1, PortCount: 1, FBMemoryCount: 1 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000498 - ConnectorLVDS 00000800 02000000 98040000 Latter would need to be patched for 3 ports and injection of con1+con2 as additional connectors of course. Or change con1/con2 flags of FB 0x3EA50009 from C7010000 to 87010000 or C7030000? Try and post an IOReg extract when HDMI is plugged in.

You should have been able to set DVMT to 64MB or more through Grub. Other reading that would have been of value to you:

Congrats. So KBL mobile framebuffer 0x591e000 it is then! ID: 591E0000, 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 with con1 patched for Pipe=0x12 and Type=HDMI, at least according to your IOREG because it sure ain't in your last posted config. For some reason you also inject this and it really is not necessary (and incorrect) but it's just cosmetic, so... model Intel HD Graphics CFL CRB DATA Injecting "Intel Graphics UHD 620" would be much more appropriate. con0 patches can also be removed with this mobile frame buffer, con0 being for an eDP/LVDS built-in screen. Try and add boot arg igfxonln=1 to your OC config to force all displays online.

Widows and macOS do not operate the same way at all; you'll find nothing in Windows re: Index, BusId, connectors or flags; that's all specific to macOS.

Increasing VRAM will not help. Didn't you mean DVMT? Check your BIOS settings, they may support setting this directly. Otherwise, yes, re-instate the fbmem/stolenmem patches.

Try the following additional properties in your iGPU settings: framebuffer-con0-enable framebuffer-con0-pipe 12000000 DATA framebuffer-con0-type 00080000 DATA framebuffer-con1-enable framebuffer-con1-pipe 12000000 DATA framebuffer-con1-type 00080000 DATA I verified the old bootpack of the (Kaby Lake R / UHD 620) Latitude 7490 I had a few years ago and I had patched HDMI connector con1 that way. Then monitor your framebuffer connectors live in IOReg as you plug and unplug your HDMI cable.

Ok, then you have to experiment with patching of connectors: index, BusID, possibly Pipe and highly likely Flags. Did you try to monitor your iGPU connectors real-time in IOReg as you plug/unplug an HDMI cable? With regards to DVMT, if you try and boot without fbmem and stolenmem patches, do so on a bootable USB Key so that you don't mess out your bootable installation on the SSD. Or vice versa; if you modify the SSD on the EFI partition of your SSD, make sure to have a bootable USB key as backup.

You may find what you seek through basic "Clover versions" and "Hackintool" Google search... Both have their own official repositories which you should fall upon within seconds. Why would you want clover r5157 specifically though? You found my E6230 guide and it provides a copy of Clover r5058 that worked perfectly for Catalina, so... But rest assured that I could still boot Catalina with more recent versions of Clover such as r515x. As for VoodooHDA + AppleHDADisabler kexts, do as you wish: either inject them through Clover's kexts folder or install them in /L/E knowing that latter will require you to set correct permissions to kexts and repair cache. I invite you to consult our old but dedicated thread on the matter in our FAQ section if required. Arguably, caching from /L/E is better. I realise testing can be a little painful but, hey, that's Hackintoshing. Remember that it was never meant to be. You may want to consider a bootable USB key with only Clover on it for testing, that'll save you the hassle of taking your SSD out and back in all the time. Just boot off the USB key, select your maOS partition and off you go.

If you boot without proper graphics settings, you're in what is called VESA mode, i.e. basic graphics without any form of acceleration but system more or less unusable because running slow and lots of graphics defects/glitches. Black screen means that you are getting there but there is another issue along the way. What kind of video output port do you use? VGA, DVI, HDMI?

Does your Latitude 5491 have the nVidia GeForce MX130 dGPU? If so, it's highly likely that HDMI output is actually wired to it and you won't be able to use it under macOS.

Hello, you're using the recommended CFL framebuffer layout for sure. I've noticed 2 things: your IOReg shows MBP15,1 in use, yet your OC config uses MBP15,3 SMBIOS; there is discrepancy here. you patch iGPU fbmem and stolenmem with recommended values but this can occasionally impact HDMI output. If you can patch your BIOS through the documented GRUB process to set DVMT to 64MB (or higher), you could get rid of the fbmem/stolenmem patches. Did you try the igfxonln=1 boot arg? It's sometimes required to get HDMI working alongside the built-in screen. Then, of course, no harm in experimenting patching con1 and/or con2 to HDMI type. Yes, it's usually only required for HDMI audio but, on occasion, it can fix issues with HDMI video issues.

Intel i5-8250U is Kaby Lake R with UHD 620 graphics (iGPU id 0x5917). Looking at your posted IOReg + OC config, your injected graphics settings are incorrect: iGPU id 0x5917 is not natively supported. Please note that injecting hardware's own/native ids is useless and therefore totally unnecessary. Vendor id not to be specified in device id. No such thing as framebuffer layout 0x17590000 (or 0x59170000 which is presumably what you intended to use). Make sure to specify ids in the correct format and byte order; it needs to be from least significant to most significant. 0x80865917 must be entered as 17598680 and 0x59170000 must be entered as 00001759. You need to refer to the KBL/ABL section of the WEG user manual for guidance. You must fake a supported KBL/ABL iGPU id (ideally 0x5916) and call on a valid KBL/ABL framebuffer layout (ideally supported desktop id 0x59120000). In a nutshell, you need to modify your graphics injected as follows: AAPL,ig-platform-id 00001259 DATA device-id 16590000 DATA You may experiment with other desktop values of course; please note that if you do not specify one, the default framebuffer layout id is 0x59160000 and it's a mobile layout (i.e. for laptops). If you're game, you may experiment with laptop values too but this will require you to patch the framebuffer layout (no LVDS/eDP connector on a desktop) and you'll probably have to change your SMBIOS to that of a MacBook too. But I see no reason why desktop settings would not work. KBL framebuffer 0x59120000 defines 3 x DP ports (i.e. connectors). Adjust as required if you have other types of video outputs (eg: DVI, HDMI) 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 Once you've fixed the injected iGPU properties of your OC config, cleared NVRAM at OC picker and rebooted, your IOReg will show you something that will look a bit like this, where your injected values should be reflected (laptop's settings below):

The .dsl file is source code whilst the .aml file is the compiled table, i.e. the one you need. From memory, the tool may put a .dsl on the desktop (or offers you to open/view it?) but you'll find the compiled table under the Library/ssdtPRGen folder of your home directory. This subfolder is available after you execute the script. Re: audio, it looks like you're looking at it the wrong and complicated way. AppleALC fully supports IDT 92HD93 if you inject correct layout id 12. If you go for VoodooHDA, you need to disable AppleHDA kext through the AppleHDADisabler kext that usually accompanies VoodooHDA. Do not delete AppleHDA from /S/L/E, that really is a bad idea. Keep that system folder full vanilla and untouched. Look for my Toshiba R50 guide, it contains a pack that includes those VoodooHDA+AppleHDADisabler kexts. Can't see why CC would not mount your EFI partition but you sure can mount it manually with a simple Terminal command: sudo diskutil mount EFI It really is as simple as that.

Careful because the pack I posted for the E6230 does not fully apply to your E6430 which has Optimus technology. In your case, you need to make sure Optimus is enabled in BIOS settings so that HD4000 iGPU is enabled and you have to use an ACPI patch to disable the unsupported nVidia dGPU (this will avoid unnecessary battery drain by the dGPU). Re: CPU power management, don't use the SSDT from my E6230 guide, it's not for your CPU. You can generate your own CPU power management through Pike R Alpha's script tool; it's still available on the Net: https://github.com/Piker-Alpha/ssdtPRGen.sh Just follow the indications. If you require them, the specs of your i7-3520M are available here but they should already be in the script's CPU database.

Re: DW1510, it's perfectly normal given that Catalina dropped support for such cards. All the necessary information was published in the relevant wireless card inventory available in our Technical Info section. Re: audio, you probably have a duff config setting re: layout id. Please post a zipped copy the the following EFI contents you use: Clover config file ACPI folder of injected patched tables kexts folder Which version of Clover do you use?

? You're mistaken; I do not own any HP laptop...

I don't know the difference between your 820 G3 model and the 840 G3 but the bootpack you use is for the 840 G3. Maybe the SSDTs do not entirely apply to the 820 model. I've noticed that the device properties in Jake Lo's bootpack add a 4th video output port. This is possibly unnecessary or irrelevant to the 820 G3. You may also want to use KBL framebuffer 0x56160000 and device id 0x5916 rather then the values of the bootpack.

What make and model of SSD do you have in that laptop?

Your Big Sur EFI should be able to boot Ventura without issues. Sonoma probably too. Just make sure to update your kexts and bootloader to latest versions.

Tried not to use that SSDT-Shutdown ACPI table? What does it do/fix?

-+-+-+-+-+-+-+-+-+-+ /!\ Sonoma and later /!\ -+-+-+-+-+-+-+-+-+-+ Sonoma dropped all official support for what Apple calls legacy cards that remained supported up to Ventura; this includes cards based on the BCM4350 chipset. The above solution for Big Sur, Monterey and Ventura remains applicable in Sonoma but comes as a complement to the solution required to support legacy wireless cards in macOS 14 and which is explained here.

Further to my communication of July 2023 and Jake Lo's post above, I can confirm that Clover r5157 now supports blocking of vanilla kext IOSkywalkFamily kext which is required to support and use "legacy" wireless cards in Sonoma, i.e. cards that worked perfectly, natively or not, up to Ventura. This is basically equivalent to the kext exclusion available in OpenCore but limited to IOSkywalkFamily kext. The blocking is available as kext patch called BlockSkywalk and is integrated to latest versions of CloverConfigurator too. Process with Clover is therefore as follows: update or install Clover r5157 (versions r5155 and r5156 are supposed to provide the patch too but I found that it was not working and resulted in a freeze at startup) apply/enable Kernel & Kexts patch BlockSkywalk in your Clover config either add boot arg -amfi_get_out_of_way=1 in your config or add AMFIPass kext provided above by Jake to your kexts/14 or kexts/Other Clover folder and add boot arg -amfipassbeta boot arg in your Clover config add kexts IOSkywalk (renamed copy of older version of IOSkywakFamily kext) and IO80211FamilyLegacy kexts provided above by Jake to your kexts/14 or kexts/Other Clover folder you can keep SIP disabled with CsrActiveConfig set to 0xFEF, I found there was no need to change to, say, 0x803 install and run OCLP Patcher and apply Networking: modern wireless or Networking legacy wireless (depending on the card) root patch which should be automatically offered reboot and enjoy recovered wireless services out of your PCIe wireless card Clover_r5157.pkg.zip Clover Configurator.zip Example with the Apple BCM94360CS2 card fitted with an adapter board to the M.2 WLAN slot of my Dell Latitude E7270: or (as text): <key>BlockSkywalk</key> <true/>

Also revisited Sonoma guide to reflect on latest version of Clover that now fully supports blocking of vanilla IOSkywalkFamily kext, something mandatory to be able to support and use legacy wireless cards that were fully supported up to Ventura but officially dropped in Sonoma. See this thread for details.

Revisited all bootpacks to replace the SSDT-GPRW patched ACPI table. I added a test applicable to all ACPI devices RPxx, specifically RP05@1C (i.e. WLAN port), to fix an intermittent loss of Bluetooth on wake, requiring Bluetooth to be switched off and on at macOS level (PrefPane or Finder's bar icon) to recover services. This fix applies to combo Wifi/Bluetooth M.2 cards fitted to the WLAN slot. If (LEqual (0x69, Arg0)) { Return (Package (0x02) { 0x69, Zero }) }

You can check the type of touchscreen in IOReg or in SysInfo->Hardware->USB. Here are the details of the Atmel USB touchscreen fitted to my Skylake E7270. Since Big Sur, in which Apple dropped support for old USB hardware, the USB HID fix/patch is necessary for the touchscreen to work (touchscreen worked OOB in previous macOS versions up to Catalina). Details of the USB HID patch are readily available on the Net and I copied them in my E7270 guide here. Depending on the type of touchscreen fitted to the E7440, this may not be applicable of course.