Hervé

No such thing as "clear PRAM" on a Hackintosh; that's for real Mac computers only. You can of course re-install Mavericks (or any subsequent compatible OS X/macOS version) over an existing build.

-> ALC688 codec. Use AppleALC PlugIn of Lilu and configure according to the AppleALC wiki. Same as you had with Monterey really; provided you did not install any OCLP patch for audio; that would be unsuitable.

Patch what?

If the flags patch still makes no difference, the AGDP patch probably is the last and most likely resort. Details are in my old HD4600 patching guide I linked on p1. Totally linked to device (i.e. Mac model) official capabilities and therefore SMBIOS model selected.

All Dell Latitude have a BIOS section about LAN & Wireless devices. Please look this up in your BIOS settings. If in doubt, look up the documentation for your Latitude model on Dell's site (support section). NB: As per our published rules, please refrain from quoting entire posts to reply; forum provides a Reply box at the bottom of each page so use that instead.

Too many models to choose from! We've posted threads about minimum requirements for CPUs and iGPUs. Obviously, the best models are 10th gen Comet Lake and Ice lake laptops since these are the last Intel platforms used by Apple.

You did not specify if both disk use the same identical Bootloader and/or same Bootloader version. I'd recommend you reset NVRAM before you attempt to boot back in Monterey after using Ventura. That should clear out any leftovers that may cause issues. You'd do the same when booting back into Ventura from Monterey.

System freeze on cable connection/disconnection was/is typical behaviour with HDMI on Haswell/HD4600 laptops; this is fixed by patching the connector con1 (0105) pipe value from 0x09 to 0x12; you need to do that same for DP connector con2 (0204) as described in this old Haswell HD4600 patching guide for reference. Edit: Never mind, that's what Jake's done his the adjusted config file he posted just above.

Haswell framebuffer layout 0x0a260006 defines the following graphics properties: ID: 0A260006, STOLEN: 32 MB, FBMEM: 19 MB, VRAM: 1536 MB, Flags: 0x0000000F TOTAL STOLEN: 52 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 116 MB, MAX OVERALL: 117 MB (123219968 bytes) Camellia: CamelliaDisabled (0), Freq: 2777 Hz, FreqMax: 2777 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP [2] busId: 0x04, pipe: 9, type: 0x00000400, flags: 0x00000087 - ConnectorDP 00000800 02000000 30000000 01050900 00040000 87000000 02040900 00040000 87000000 DP should work OOB off connector con2. HDMI requires to change connector con1's type to HDMI and pipe to 0x0A. Check out your connectors behaviour in IOReg (using an app such as IORegistryExplorer) when you hook up your external screens.

Check your port settings/patches in your OC config and in IOReg. We've had reports of similar thing over HDMI with KBL R UHD 620 graphics for instance and it was fixed by setting the connector to the correct type. See here or here. Please make the effort to: read our published rules before posting add your systems specs in signature or in your post(s) post a zipped copy of your OC config post a zipped copy of IOReg extract when TV is connected. It really is the bare minimum to expect assistance...

Last updated: 15 Jun 2024 Restoring support for dropped GPUs in macOS Big Sur and Monterey Best thing to do is favour OpenCore Legacy Patcher (OCLP) tool against other own made tools that are mostly packaged scripts based on developpers work. 1) Big Sur: macOS 11 officially dropped support for Ivy Bridge but the drivers for HD4000 graphics (i.e. Capri framebuffer kexts) remained provided. As such, Big Sur may be installed on Ivy Bridge/HD4000 Hackintosh computers with the SMBIOS of a Haswell (or later) Mac model, then booted with a regular Ivy Bridge SMBIOS as long as boot arg -no_compat_check is used. for 1st gen Intel HD graphics, apply root patches with OCLP, making sure to disable SIP and select an Arrandale SMBIOS (eg: MBP6,2); no need for any other OCLP settings. for HD3000 graphics, apply root patches with OCLP, making sure to disable SIP and select a Sandy Bridge SMBIOS (eg: MBP8,1); no need for any other OCLP settings. for nVidia Tesla graphics, apply root patches with OCLP, making sure to disable SIP and select the SMBIOS or a Mac Model with nVidia graphics; no need for any other OCLP settings. 2) Monterey: macOS 12 officially dropped support for some (but not all) Haswell platforms and drivers for HD4200/4400/4600 and affiliated (i.e. Azul framebuffer kexts) remained provided. On the other hand, support for Ivy Bridge HD4000 and NVIDIA Kepler was totally dropped with no drivers (i.e. Capri and NVDA/GeForce framebuffers kexts) provided. for 1st gen Intel HD graphics, apply root patches with OCLP, making sure to disable SIP and select an Arrandale SMBIOS (eg: MBP6,2); no need for any other OCLP settings. for HD3000 graphics, apply root patches with OCLP, making sure to disable SIP and select a Sandy Bridge SMBIOS (eg: MBP8,1); no need for any other OCLP settings. for HD4000 graphics, apply root patches with OCLP, making sure to disable SIP and select an Ivy Bridge SMBIOS (eg: MPB10,2); no need for any other OCLP settings. for Haswell/HD4x00 graphics, just make sure to apply MBP11,4 SMBIOS. MBP11,1 or MBA6,2 SMBIOS will no longer apply since these are among the Mac models dropped by Monterey. for nVidia Tesla graphics, apply root patches with OCLP, making sure to disable SIP and select the SMBIOS or a Mac Model with nVidia graphics; no need for any other OCLP settings.

See our Hardware Information->Intel Platforms and Hardware Information->Graphics forum sections. Our Monterey and Ventura release articles also specify the minimum supported Intel platforms and those that were dropped. Obviously, given that Apple has abandoned Intel, you should opt for the latest possible supported platforms (i.e 10th gen).

OCLP really is meant for unsupported Apple Mac computers not Hackintosh computers; as such, not all patches are relevant and it's to be used with outmost precaution on Hacks.

You can ignore the size of screen reported by macOS; I've experienced that too with several TV screens that I hooked over HDMI to my Hacks over the years. In my case, it was just a cosmetic thing and never had any impact on screen resolution or manner in which the video was displayed on screen. With regards to your OC config: You've created a dedicated kext to inject your screen's EDID; you no longer enable it so (I guessed it was of no help) so I'd just get rid of it; I've never seen EDID injection required for anything else but laptop's built-in screens. You've got a 4K screen so check the value assigned to DVMT; you'll need at least 64MB allocated at BIOS level. In that respect, you must evidently remove your patch that reduces stolenmem to 19MB (framebuffer-stolenmen 00003001 DATA). You patch your framebuffer's connectors in a way I'm not familiar with: You've opted for CFL framebuffer desktop layout 0x3E9B0007 which defines the following graphics 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 i.e. 3 x DP ports on connectors con0 (0105), con1 (0204) and con2 (0306). Your patches change these connectors to: [1] busId: 0x06, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x05, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [3] busId: 0x04, pipe: 8, type: 0x00000800, flags: 0x000003C7 - ConnectorHDMI 01060900 00040000 C7030000 02050A00 00040000 C7030000 03040800 00080000 C7030000 Can you explain what drove you to such busId patches or was it just part of a config you acquired somewhere? Can you post an IOReg extract to examine things? As asked by Jake, do specify the type of connection you use for your screen. Your HDMI patch would lead us to believe you use HDMI need but your SysInfo screenshot indicated TB/DP.

Your OC config shows 2 x disk-related patches enabled: one is to force trim (should not be necessary but Ok), the other is labelled "internal HD patch test". No idea what the latter does but maybe you ought to disable it... Can't see anything else that'd look suspicious in your setup.

No need to ask to post whatever fix you've found. Just post it.

Check the eventual obsolescence of your HFSPlus driver/module. You could also envisage testing OpenHFSPlus or HFSPlusLegacy drivers as alternatives.

Having Ventura on an external SSD is irrelevant here and bears no impact to Bluetooth. Any change of behaviour after putting laptop to sleep then waking it?

The screenshot you attached in post #1 shows that the Bluetooth module is seen (and should therefore be operational) but that the Bluetooth service has been disabled. Check that out in the BT icon of your Finder's bar or in the BT PrefPane. Bluetooth disabled: Bluetooth enabled: Do compare the version of firmware displayed in Monterey's SysInfo vs. that displayed in Ventura's SysInfo (v0 c0). It could simply be that Ventura does not load the necessary firmware.

Did I ? Well, there sure ain't no specific patch or properties injection against RP08 or RP08.PXSX device so I really can't see what I could have done for your BCM94360S card in that DSDT, especially as such card requires no patching. Or maybe I removed some existing patching at the time.

Card is seen, driver is loaded. Nothing wrong on that front. But Wifi appears to be turned off/disabled. Check that out in your Monterey Control Panel or through the Wireless icon in the Finder's bar if it's displayed there. I was only familiar with subsystem id 106b:0134 for the Wifi part of BCM94360CS, not 106b:0112 as shown for yours. On the other hand, all is as expected on the Bluetooth front with subsystem id 106b:8289. I'd have to double check to be certain this is not a fake card. Edit: 106b:0112 appears to be subsystem id of wireless cards fitted to MacBookPro11,1 so all should be well. Just can't say if the model was BCM94360CS or another but that's really secondary.

If you switched from OpenCore to Clover you must 1st clear NVRAM. You can do this from: an OC USB key -> reset/clear NVRAM at OC Picker macOS Recovery mode -> Utilities -> Terminal -> command "nvram -c"

Try a different PCIe slot. Check your IOReg.

Go ahead and post your zipped EFI folder. If I understood you correctly, you've not made any change to your Monterey bootloader setup before trying to update to Ventura, right?

If the card/hardware is fully functional (i.e. not faulty/defective), it works OOB. No need for add-on kexts such as AirportBrcmFixup so you can disable it/get rid of it. Check if you see the card in IOReg. If you hookup the Bluetooth connector to an internal USB port, you'll also see the BT module in IOReg + in SysInfo->Hardware->USB.