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.

Try and inject the following iGPU property: enable-max-pixel-clock-override 1 NUMBER See here for details.

Unrelated to HDMI output of course but note that reducing stolenmem to 34MB is not required if DVMT is set to 64MB or above in BIOS; also, it'll prevent support for 4K output, something the OP is after here... For the rest, the only noticeable differences are: the use of KBL framebuffer 0x5916000 and KBL iGPU device id 0x5916. the lack of max pixel clock override.

Did you try and inject your screen' EDID as suggested previously?

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).

What if you also fake ABL iGPU id 0x87c0 rather than keep native KBL id 0x5916? AAPL,ig-platform-id 0500c087 DATA device-id c0870000 DATA Cf. WhateverGreen User Manual.

IOReg shows you're injecting framebuffer layout 0x87c00005 in Ventura, something normally used for Amber Lake platforms. Any reason for not using KBL layout 0x59160000 or 0x591b0000 as would be expected?

Typical values for the DVMT register are: 1 -> 32MB 2 -> 64MB 3 -> 96MB It's always a multiple of 32MB. See here. Check out your register possibilities through the ModGrub CLI help if that's available.

For your info, on a laptop Hackintosh: internal built-in screen usually is -if not always- attached to FB@0 (i.e. con0) and should always register as AppleBacklightDisplay. external screens usually are attached to FB@1/@2/@3 (i.e. con1/con2/con3) and should always register as AppleDisplay.

The (now) old PS2Controller kext from Dr Hurt (version R6 compiled by Bronxteck) for Alps touchpads should work Ok on the E7450 platform. Certainly did on all my old Sandy Bridge to Broadwell E Series laptops: E6220, E6230, E6440 and E7250. Said kext is available in our R&D->Kernel Extensions forum section and in my E7250 guide.

You have to be more specific with regards to your statement about "using MBP14,1, SKL graphics settings". OCLP is to patch unsupported systems. As such, if you want to apply the tool to your system, you have to apply it with MBP13,1 SMBIOS selected in the tool (not MBP14,1 which is a supported platform), then boot with MBP13,1 SMBIOS + -no_compat_check boot arg.

Do try to inject your screen's EDID though if it's not required for Monterey, it should not be for for Ventura. Feel free to experiment with OCLP if the usual tricks don't work for you.

Try the KBL settings for Ventura with Monterey (MBP14,1, KBL faked iGPU settings, boot arg -igfxsklaskbl).. Failing that, try and boot Ventura in VESA mode to check if you can reach the desktop without graphics acceleration. This would confirm whether your issue is iGPU settings related or not.

@EMU7989 I don't think you need some of those properties you inject: I recommend you remove those properties highlighted in red. Never seen any need for dual link properties since Ivy Bridge days (this may be the cause of your black screen), HD520 is not HDMI 2.0 and KBL 0x59160000 framebuffer is natively defined with 3 ports/3pipes. Re: injected kexts, you correctly inject v1.6.3 of Lilu + Whatevergreen but I do wonder what those do and why you inject them: AppleBacklightSmoother AMFIExemption YogaSMC I'd recommend you get rid of those too. One thing you can do with Monterey is call on a Ventura-targeting config in which you add the Lilu/WEG boot arg -igfxsklaskbl which will allow you to test faked KBL graphics in Monterey. If you use Clover, you may just boot Monterey with a specific config file to that effect that you'd call from the Clover main menu->Options->Configs. This being said, do search the forum for black screen in Ventura, I think there are posts about this very matter on Skylake laptops.

@Eldeebo please make every effort to post in a suitable manner. A thread entitled "Precision 7510 Ventura wifi bug" in the Precision x000 section was not appropriate for your predicament. You could have at least indicated the wireless card model and consulted the OpenIntelWireless site where support for Intel wireless cards stops at Monterey with release v2.1.0 of Jan 2022. As indicated by Jake, support for Ventura may only be provided in v2.2.0 which is clearly stated to be at early pre-release alpha stage at this point of time. A link to the Gitter Chat room is also provided as the place to report/discuss issues. https://github.com/OpenIntelWireless/itlwm/releases Meantime, you may either replace your wireless card for a Broadcom model supported in Ventura or opt for macOS Monterey and have proper support for your Intel card.

If everything works Ok, leave it be and enjoy your Hack as it is.

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

Don't hesitate to rollback your PS2Controller kexts then.

Re: BIOS, I think you're very confused and no OC package can contain a BIOS update. If your BIOS version shows A09, that's what you got. You can only update your BIOS through the DOS/Windows .exe published by Dell, i.e. only from Windows or through a DOS-based USB key for instance. Rest assured OpenCore does not touch BIOS or BIOS settings in any way.

I've completely revamped my E6230 Big Sur guide. See here. I don't believe I changed the PS2Controller kexts between Catalina and Big Sur but feel free to experiment (make sure to boot off a USB key when testing to avoid breaking a running build).

3 wireless cards experiencing the same issues: I think it's safe to say the issue lies elsewhere but with the card themselves. Faulty slot (unlikely)? Defective antennas ? Duff macOS installation? Try and make a new build on a separate partition, even if temporarily so. To rule out a hardware issue, did you try those cards in, say, Windows?

compatible statement carries no value in your OC config; bound to be a problem... You could get rid of the Intel wireless/Bluetooth kexts, at least disable them in your OC config. Can't see anything else.

Nothing to do with AFPS, something macOS uses since High Sierra. So Mojave also uses APFS file system. Audio sometimes requires to patch HPET for IRQs (interruptions). Maybe you need that. You would find typical patched HPET SSDTs at the Dortania repo and can re-use them. I attach an example. SSDT-HPET.aml.zip

Re: brightness control, all was normally included in the patched DSDT I had posted. I've made a fresh (re)install of Big Sur 11.7.2 with Clover r4151; will update my guide accordingly very soon. Meantime, do add/replace the following tables (once unzipped) in the ACPI/patched folder of your Clover EFI (you may also add the SSDT-PNLF table to the list specified tables in your Clover config). SSDT-PNLF.aml.zip DSDT.aml.zip Your IOReg clearly shows Big Sur booted but your Clover config does not show the -no_compat_check that's necessary with MBP10,2 bootpack. Did you use the old alternative method of modifying the macOS file that defines the supported models?

Nothing looks wrong in IOReg. After 3 x different cards, hardware issues being excluded, there can only be an issue with your setup: BIOS settings, macOS installation, bootloader config. Make sure there's nothing disabled in BIOS for Wireless services and do post a zipped copy of your EFI (limit contents to ACPI + kexts folder & config file).