Hervé

Big Sur will run perfectly on Haswell/HD4400 Latitude E5440. It can take anything up to 1hr to complete its installation. Yes, it's quite long and normally requires up to 4 reboots after installation begins. Process has been detailed in our numerous guides like this one for my Haswell/HD4400 Toshiba laptop. There are several E5440/E6440 guides and/or threads on the forum that you can consult to reach your goal.

Several things to revise in your Clover config: CPU power management is all wrong: no need to drop CpuPm and Cpu0Ist tables with a Coffee Lake platform, those drops applied to Sandy & Ivy Bridge systems. In the same respect, remove Generate P States/C States, that applied to Core2Duo/1st gen Core CPUs. I'm quite surprised by the number of ACPI patches you've selected. Are you sure you need all of them? i5-8500 is indeed Coffee Lake with UHD630 iGPU so why did you select Kaby Lake iMac18,3 SMBIOS instead of iMac19,2? Change that. You appear to inject the correct device properties forUHD630 graphics but you only patched con0 and con2 connectors (i.e. video output ports). DP or HDMI audio require that the associated connector bet set to HDMI type 00080000. So, check in IOReg which port connects to your DP or HDMI screen and patch its type accordingly. In your config, only con0 is set to HDMI type. Clover chime, you should easily find out if you search a little better the Clover documentation. Hint: something to do with an audio module/driver... Strangely enough, no ACPI folder in the zipped EFI you posted so I'll assume you're not using any patched DSDT or SSDT. If you do, please post your full EFI. Given that you have a Pascal GTX1060 graphics card in your desktop, you are using the nVidia Web Driver, right?

Try: adding property injection to set fbmem to 9MB switching SMBIOS to iMac19,2

And the Bluetooth module/card model would be ? For the rest, please consult our FAQ section where you'll find existing answers to your questions. As a general rule of thumb, you should always start there and by searching the forum before posting. You're also expected to post in the correct forum section... -> moving to E6xxx support section.

DW1550, like its M.2 counterpart DW1560, is based on Broadcom BCM4352 chip (pci14e4,43b1). As such, you should still be able to get it to work under Catalina and Big Sur with the good old recommended settings: https://osxlatitude.com/forums/topic/11138-inventory-of-supportedunsupported-wireless-cards-2-sierra-big-sur Last 3 x Broadcom chipsets officially supported by AirPortBrcmNIC in Big Sur are: BCM43602 (pci14e4,43ba) BCM4350 (pci14e4,43a3) BCM4360 (pci14e4,43a0) Catalina supported the same + the following additional 2 x Broadcom chipsets through AirPortBrcm4360: BCM4331 (pci14e4:4331) BCM43224 (pci14e4:4353)

That's correct; see our BCM4350 article and guide for references and illustrations.

@davidfrei7as, indeed you should have been more cautious before purchasing the wrong card. Now you have 2 x unsupported Qualcomm Atheros cards! We've detailed this information specifically in our wireless cards inventories, starting in the 1st one back in 2018:

It depends in which country you are and what the default code of the card is set to.

Looking at your posted IOReg + SysInfo data, graphics acceleration is fully functional. All is present and Ok under IGPU@2 in IOReg and SysInfo shows KBL graphics drivers are loaded. Your issue lies elsewhere to me. Check your BIOS settings against the recommended ones.

@cowboy_wilhelm Subsystem id does not matter. Check that your configuration matches our recommended settings posted in the BCM4350 guide.

If I'm not mistaken, Busid 02 and Index 02 are not valid values.

So, according to Ubuntu, it would be an HDMI display and you could therefore apply the patch for HDMI connector type to it's associated connector in macOS. Look it up in IORegistryExplorer app, you'll see an AppleDisplay entry (AppleBacklightDisplay if detected as built-in LCD) under the output port/connector.

Could gain from clean-up. Patched DSDT already injects all graphics properties in a XDSM method so why do you re-inject in OC config? Patched DSDT already contains a PNLF device so why use a SSDT-9 (strange name by the way) to inject PNLF? Patched DSDT contains an EC device (for PNP0C09) so why inject the SSDT-EC? Don't use FakePCIID_Intel_HDMI_Audio; it's deprecated and you already inject Lilu + AppleALC. No need for AICPUPM patch on a Haswell platform; that patch is for Sandy Bridge and Ivy Bridge platforms only. Using OCC app, reselect MacBookPro11,1 profile to regenerate SMBIOS. You probably should try without your patched DSDT, I think it clashes with the rest of your OC setup.

Ideally, we would need to know the type of display of your built-in LCD; LVDS or eDP or DP; unlikely to be HDMI.

Just looked at your patch. Indeed... erm... it's... erm... special... All you need to do is: identify which connector is DP and which is HDMI; you do that by connecting one output at a time and check which port/connector shows ups with a display in IOReg. Use IORegistryExplorer app to that effect. you then patch the identified connector for DP and/or HDMI connector-type. That's it, that's all. You've opted for UHD630 framebuffer 0x3E9B0007 which is defined as follows (as perWEG manual): 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 So, default connectors are as follows: 1st connector con0: 01050900 00040000 C7030000 2nd connector con1: 02040A00 00040000 C7030000 3rd connector con2: 03060800 00040000 C7030000 all being DP by default (type set to 00040000). Your patch effectively converts them to: con0: 02020900 00080000 C7030000 con1: 03040800 00080000 C7030000 con2: 01010900 00080000 C7030000 which looks quite wrong to me to say the least. Again, 1st determine which port/connector is what (built-in LCD, DP output, HDMI output), then patch accordingly. In the patch, you only require to specify what you want to change, not everything, especially if the values remain there same (eg: flags). So, for instance if HDMI output is con1, your connector patch should only be: framebuffer-con1-enable 01000000 DATA framebuffer-con1-type 00080000 DATA with nothing else in terms of connector patching. If your built-in LCD works perfectly OOB, don't patch its connector!

Obviously it's quite a bad idea to use the EFI folder of an Ivy Bridge laptop on a Haswell one. So don't. Not the same chipset, CPUs, CPU power management, etc.

Very strange. Given that you stated that speakers work in Windows, we've got to rule out speakers cable being disconnected so no idea about your problem. Sorry.

If you're talking about the CPU power management SSDT, no, it's of no influence on audio (unless you got it completely wrong of course but then the rest of the Hack would suffer). If you inject add-on kexts from Clover, you may indeed choose to cache them from /L/E (rather than /S/L/E) instead.

No. Lilu + AppleALC operate on vanilla AppleHDA.

One has to wonder why you'd follow a guide for AMD Ryzen desktop where the guy clearly states "this will not work for a laptop"... We've got existing guides available for E7x50 in our Guides section and I would suggest you consult them. Eg: https://osxlatitude.com/forums/topic/8514-dell-latitude-e7450-uefi-only-clover-and-opencore Our FAQ section also contains hints and tips re: making an installer from Windows.

Nice little toy! Make sure to select "French PC" keyboard. Then you may obtain the "@" character through either [ALT][à] or [Win][à] depending on whether you've swapped Option and Command keys or not. Regarding your OpenCore setup, you may seek inspiration from the Big Sur guide I posted for my Toshiba Satellite Pro R50-B. It's a similar type of Haswell platform with i5-4210U & HD4400 graphics. Obviously not all kexts are applicable to your HP laptop since it has different audio/LAN/wifi/etc. but most of the OC config should be re-usable, especially the Quirks. One parameter that I expect you'll specifically require will be Lapic kernel patch (because it's a HP platform).

Can you please post the detailed specs of the computer? Touchscreens usually are USB-based so if yours does not work after sleep, it's indeed a USB-related problem.

All Latitude E6x30 with Intel HD4000 graphics can run macOS Big Sur without any trouble. Update your BIOS from very old A02 to latest version to begin with. Then follow any existing Big Sur guide for the E6x30 models, there are a few on the forum. These Latitude models are 100% supported (with a fully compatible Wireless/Bluetooth card of course).

The only alternative to the kexts mod or FakeSMC injection (by far the best method to me) I can think of would be to apply an on-the-fly Info.plist patch for the target kext through your bootloader config. The patch would consists of replacing the vendor and device ids of an existing model entry by the Intel ones.