Hervé

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

New version v2.5 released. Minor update to display a different SD card icon.

Index 1 would be con0. I'm a little surprised with stated BusId 1 and Pipe 18 as there is no such native thing in any CFL framebuffer layouts, nor in any KBL or ABL layouts.

No, that's impossible. What you're dealing with is NVRAM.

Can't say more; wrong settings somewhere for sure... Maybe undesired add-on kexts in /S/L/E or /L/E. Check those out and clean-up as required..

Surely, it couldn't be just that! More likely some mistakes or conflicting settings given that OP stated he's mixing 2 x different set of configs and, ouch!, that set of kext patches! @Ahmadfini start by removing those AppleHDA patches... Can't understand why you made those ACPI & Kext patches changes. Rest assured the config posted in my guide works 100% for all E6220 as long as you follow the posted process.

No, DW1820 is unsupported. Don't go for that and don't confuse that card with the DW1820A.

The error message you get is an indication from OpenCore that something is wrong with your setup in relation to CodecCommander kext injection: either the kext or its Info.plist is missing in your OC EFI kexts folder or it is incorrectly defined in terms of PlistPath in the OC config. If you look into what you downloaded, you'll notice that OC EFI kexts folder does not contain no CodecCommander kext. So you either download it from the Web and install it in the folder or you remove the injection of that kext in your OC config (kernel section). OpenCore is without pity on kexts injection. Get anything wrong in the slightest way and it just won't boot. A true lesson of rigor...

Yes, you're expected to disable that unsupported Maxwell dGPU with that SSDT. If you don't, your battery will just drain out quicker.

You need to inject the required properties for your Broadwell HD5500. Follow the configuration you'll find in existing guides for Broadwell laptops that are available on the forum. You may also consult the WhateverGreen manual for guidance. Not much further we can provide until you post a zipped copy of your bootloader EFI folder or config for checkup. Given that HD5500 iGPU of i3-5005U CPU carries id 0x1616, all you would normally require in terms of properties injection for iGPU@2 would be: framebuffer-patch-enable 01000000 DATA framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA WhateverGreen kext then taking care of everything, including the correct BDW framebuffer layout. SMBIOS MBP12,1 of course!

Values for DATA type properties are specified in reverse byte order and, usually, as WORDs of 32bits (i.e. 8 x hexadecimal characters). If you look at the specs of your Intel i7-6820HQ CPU, you'll see that its HD530 iGPU carries id 0x191b. In order to obtain graphics acceleration on Skylake (SKL) HD530, you must: changed iGPU id to 0x1916. use layout 0x19160000 Since these values are injected as 32bit hexadecimal WORD in reverse byte order, you must use 16190000 and 00001619 respectively. If you look at the other injected properties: framebuffer-fbmem = 00009000 -> 00009000 equates to hex 0x00900000 which is 9437184 in decimal, i.e. 9*1024*1024 or 9MB framebuffer-stolenmem = 00003001 -> 00003001 equates to hex 0x01300000 which is 19922944 in decimal, i.e. 19*1024*1024 or 19MB You can read all about graphics framebuffers and injected properties in the WhateverGreen manual. Be careful as -again- most DATA properties are entered as 32bit WORDs, i.e. 8 x hexadecimal characters. In that respect, the 9 x character value you posted for framebuffer-stolenmem (000030001) was incorrect but that was clearly just a typo since it was Ok in your config file. The other important part you need to understand with regards to property injection is the location/device at/to which you apply the injection; it's the left part of the injection screen in tools such as Clover Configurator or OpenCore Configurator. This must be right or you may inject properties at the wrong place which may result in undesired side-effects and may lead to operating system crash/KP. These locations are related to chipset and manufacturers choices of hardware implementation. For instance, in a laptop, the integrated GPU (iGPU) is always located at IO address 0x00020000 (or @2) and the discrete GPU (dGPU) is always located at IO address 0x00010000 (or @1). When you inject properties in your bootloader config, this is expressed as: PciRoot(0x0)/Pci(0x1,0x0) PciRoot(0x0)/Pci(0x2,0x0) In the same respect, the audio controller is often found at IO address 0x001b0000 (or @1b); again this is expressed as: PciRoot(0x0)/Pci(0x1b,0x0) LAN card can often be found at 0x00190000 which is expressed as: PciRoot(0x0)/Pci(0x19,0x0) Sometimes, devices are located under secondary root bridges. This typically applies to hardware accessories such as SD card reader or wireless card; for instance you could find a card reader located at 0x0 under a root bridge located at address 0x001c0005 or a wireless card located at 0x0 under a root bridge located at address 0x001c0000; in such instances, this is expressed as: PciRoot(0x0)/Pci(0x1c,0x5)/Pci(0x0) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0) To identify the location of any given device of the PCI bus (or in IO), you may use tools such as IORegistryExplorer, IOJones or other such as Hackintool, etc. Or you may open up your DSDT with tools such as MaciASL but this is a little more tricky and requires more computing knowledge.