Hervé

Correct; macOS has no support for integrated graphics of Intel 11th gen CPUs. See our compatibility-related threads: https://osxlatitude.com/forums/topic/2998-min-requirements-for-os-xmacos https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards

Identify your hardware specs. Build your own bootpack from other Haswell-based Latitude E5x40/E6x40/E7x40. i5-4310u includes HD4400 iGPU.

Using an AR9462 card in a Hackintosh is a punishment in itself...

No, you have not. You need declare RP05 AND its PXSX child as external. Ok, it's the SSDT table that you've named ARPT. And I'm pretty sure you need to use SCOPE for your target rather than DEVICE since we're dealing with existing ACPI objects, not new ones you wish to create. Original objets need to be renamed if you wish to replace them by new entries, otherwise your code is just ignored as I suspect yours is ('noticed the " 1 table load failures" error message?). Hence why renaming such as X--- or ---X can be found in Bootloader's configs to accompany pathed SSDTs. Eg: _OSI renamed to XOSI, OSID renamed to XSID, HPET renamed to XPET, etc. that complement specific patched SSDTs that redefine the original objects. To me, your SSDT should look like: external (xxxx.RP05.PXSX, DeviceObj) Scope (xxxxx.RP05.PXSX) { Method (_DSM, 4, NotSerialized) { [...] } } assuming, of course, that there's no existing _DSM method under RP05.PXSX in your vanilla DSDT.

Best thing really is to replace that Atheros AR9462; they're totally crap under macOS. Failing that, with the specific rewritten kext for AR9462: https://github.com/khronokernel/IO80211-Patches

If you wish to try the SSDT method, you need to declare device PXSX as eternal too because it already exists in the DSDT. If you don't declare it as external, your DSDT basically attempts to create a duplicate of a valid existing one and this is rejected. And, of course, if you inject AirportBrcmFixup or rename your wireless ACPI device as seems to be the case, device PXSX gets renamed to ARPT... So, you're basically shooting blanks for the time being. NB: as per our published rules, no systematic quoting to post replies please. Forum offers Reply boxes at the bottom of every page for that very specific purpose so please use that.

Posted config file appears incorrect and cannot be opened with usual OC tools. Line 1246 carries a syntax error/ <string><>/string> Should be! <string></string> According to the IOReg screenshot you posted, none of the desired properties appear injected for the DW820A at the desired location 1C,0. That explains why you're not able to boot unless you disable wireless in BIOS. So, there's definitely something wrong in your config file. Check it out thoroughly and use the config verification tools. Please note that you should not require AirportBrcmFixup nor its PlugIns for the DW1820A, even in. Monterey.

Failing that, you may use the kexts I provided in the bootpack of my E7270 guides. Basic features only (tap to click, 2-finger scrolling, no trackpad PrefPane) but 100% operational otherwise.

We have a dedicated thread on the matter in our FAQ section. Look it up. It won't give you the specifics for your E6420 but certainly all the necessary pointers for creating a macOS USB installer from Windows. Please note that HD3000 iGPU was last officially supported in macOS High Sierra 10.13 which goes back to 5 years ago so the ageing Sandy Bridge E6x20 are no longer a great platform to run as Hackintoshes. This is worsen by the poor/buggy support of HD3000 graphics since OS X El Capitan 10.11/macOS Sierra 10.12.

No HDMI output registering...

Apart fom the weird value shown for iGPU subsystem id, all looks ok to me. What were your settings at the time you took this IOReg? Was HDMI monitor plugged in?

The iGPU properties injected in @Vonjy's Clover config are odd and contradictory: device location is incorrectly entered (though it probably works due to values being <10) framebuffer port count set to 2 yet there's a patch for a 3rd one This needs be revisited and configured with correct syntax and meaningful parameters: 1) iGPU device location PciRoot(0x0)/Pci(0x2,0x0) 2) iGPU properties AAPL,ig-platform-id 00001659 DATA device-id 16590000 DATA framebuffer-patch-enable 1 NUMBER framebuffer-stolenmem 00003001 DATA framebuffer-fbmem 00009000 DATA framebuffer-unifiedmem 00000080 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA // but this is usually to support HDMI audio, not HDMI per sé 3) SMBIOS Check whether MBP14,3 is more appropriate than MBP14,1.

Ok, something's lost in translation here because what you write does not make much sense. Being a piece of Apple hardware, Broadcom-based BCM94360CD remains supported OOB and 100% operational in Big Sur and Monterey, i.e. without any sort of particular settings or add-on kexts. At the risk of paraphrasing you, I know because that's what I use in my Latitude E6230 running Big Sur. It also worked 100% and OOB in Monterey during the short time I tested that version on the E6230. Of course, your BCM94360CD does not need your Intel card to be installed for its Bluetooth module to work, that really goes without saying. What you experience must obviously be a conflict of some sort due to hardware competition and/or incorrect settings, either in your OC config and/or BIOS. You can only expect one card to provide the wireless and/or Bluetooth service(s), not both cards. I remember that, when I had my Latitude E6440, it came fitted with an unsupported (at that time) Intel combo Wifi/BT card that I kept in place despite adding an Atheros wireless-only card into the 2nd mini-PcIe slot. Bluetooth was enabled in BIOS and, obviously, could only be available from the Intel card. I found that it was natively but only partially supported in OS X (very limited functionalities) and came to complement the wifi service offered by the Atheros card. In that situation, I got wireless through the Atheros card and Bluetooth through the Intel card, there was no conflict. If you have competing hardware that offer same services, you'll experience conflicts. Not so much for wireless here because the Intel card needs specific drivers when the Apple card does not, so as long as you do not install the itlwm drivers, you'll be Ok. For Bluetooth, things are different because the technology is not PCIe based but USB based and the chipsets fitted to the cards may be natively supported by macOS. In addition, when Bluetooth's availability is controlled through BIOS settings, this usually applies to the hardware fitted into WLAN slot or the built-in module. For instance, in my E6230 (and it was the same for my E6220 when I still had one), if I enabled Bluetooth in BIOS, it applied to the small DW3xx modules and I found these could take precedence and overcome my BCM94360CD cards. Again, I strongly advise you to remove your Intel card and all add-on kexts/ACPI patches/config settings for wireless and Bluetooth. Also check your BIOS settings for Bluetooth. If you insist on keeping your Intel card in place in the WLAN slot (but I can't see any valid reason to do so), make sure Bluetooth is disabled in BIOS and you should then be good to go with all wireless and Bluetooth services available and operational through the Apple BCM94360CD. BIOS Bluetooth settings apply to what Dell sometimes refer to as "internal module" and, in your particular case, you may want to keep it disabled to avoid all possible confusion and hardware conflict (it'll basically disable the USB functionality of the WLAN slot). Afaik, the BCM94360CD will still provide you Bluetooth services with the option disabled in BIOS. One word of caution with regards to Monterey: despite the use of Apple hardware, Bluetooth may still be a little glitchy/buggy in Monterey but it's something specific to that version of macOS and, if it's been more or less fixed on real Macs, things remain a little itchy on Hackintosh systems. You can read it all on the various Hackintosh forums.

https://openintelwireless.github.io/IntelBluetoothFirmware/FAQ.html#what-additional-steps-should-i-do-to-make-bluetooth-work-on-macos-monterey I really can't see why you'd keep the Intel card alongside the Apple BCM94360CD which is 100% supported OOB. In addition, having 2 x cards that basically provide the same type of services really is a bad idea. I suggest you remove the Intel card and all add-on kexts/ACPI patches/config settings you have in place for wireless and bluetooth. You do not need anything with the Apple card.

Just add this IOHIDFamily patch to you OC config: https://dortania.github.io/OpenCore-Install-Guide/extras/big-sur/#keyboard-and-mouse-broken

Erm... all you have to do is add the single necessary ACPI patch in your bootloader config (1 line if you use Clover Configurator or OpenCore Configurator).

Well, if you think the touchscreen is that Intel Sensor, did you try the USB HID Fix I mentioned above?

I don't see much difference in IOReg... Question: if this is the Bluetooth module of your Intel 7260 wireless card, is this the touchscreen?

'same as Jake for me: 'could not see any USB-based touchscreen in your extracted IOReg. Unless I missed something, I didn't see any confirmation that touchscreen was working on the XPS 12 9Q33 with Jake's 2017's bootpack you just linked. Do you see your touchscreen in SysInfo->Hardware->USB or can you post a SysInfo extract? If it's USB based, you need to ensure you've properly mapped all your USB ports and, if it does not natively work under Monterey but is visible in Sysinfo, you may need to apply the USB HID Fix (described here if you're using Clover or at Dortania if you're using Opencore).

Absolutely correct, I had forgotten! https://osxlatitude.com/articles/news/macos-monterey-is-out-r44/ https://support.apple.com/en-us/HT212551 https://everymac.com/systems/by_year/macs-released-in-2015.html

Check the SMBIOS in use; you need one of a model compatible with Monterey. Typical Haswell MBP11,1 is not compatible; you need to select Broadwell (eg MBP12,1) Haswell MacBookPro11,4 SMBIOS minimum to get Monterey upgrade offered.

You're using a rather odd framebuffer layout for your 10th gen Comet Lake UHD620 graphics: you opted for unusual 7th gen Kaby Lake framebuffer 0x591C005, something listed in the Whatevergreen user manual for UHD 617. ID: 591C0005, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00A30702 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 617 Camellia: CamelliaV3 (3), 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: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7030000 02040A00 00040000 C7030000 Any reason why don't you use the recommended settings for a Comet Lake laptop? https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake-plus.html

Don't know what you were possibly expecting with old Chameleon boot option cpus=1 but whatever; you got it sorted, that's all that matters.

Does not look different to me. Properties injection for DW1820A don't look like they're being injected. If you disable Wireless in your BIOS settings, there should be a difference... In addition, what are the reasons for using: SKL framebuffer 0x191B0000 rather than 0x19160000? SSDT-AC + SSDT-DMAC + SSDT-MCHC-SBUS + SSDT_OCWorkDell patched tables? add-on kexts such as FeatureUnlock + Intel & Broadcom Bluetooth firmware + NoTouchID + Sinetek-rtsx + VoodooI2C + CPUFriend? Your SSDT-EC-USBX_Laptop patched table looks wrong to me and could also cause a system freeze. I suggest you download the table from Dortania's web site. I have a much simpler set of ACPI tables and kexts on my E7270 and all works perfectly well. Looks like you've thrown all sort of (inappropriate) things at your E7470. I would suggest you seek inspiration out of Jake's guide: https://osxlatitude.com/forums/topic/9179-dell-latitude-e7x70-clover-and-opencore

See my reply in your identical thread posted at IM: screenshot shows a reference to Broadcom card 14e4:43a3. OpenCore config shows properties for a DW1820A commented out. If you have a DW1820A in that E7470, you must inject the properties that fake BCM4360 and disable ASPM or you'll indeed encounter system freeze at startup. See our detailed thread about BCM4350-based cards in our R&D->Wireless section. Looks like you modified your OC config before or after updating to 12.1