Hervé

All is ok then, it's the right one.

Is it really an Alps v7 model? It's been a couple of years since I last had an E7250 but I'm pretty sure the TouchPad worked Ok with Dr Hurt's VoodooPS2 kext for Alps. Is it the driver you're using?

nVidia Quadro K620 is Maxwell and therefore unsupported beyond High Sierra with which it requires the nVidia Web Driver since Maxwell cards are not natively supported. You'll have to replace your graphics card by a supported model if you want to run Big Sur with a discrete graphics card. The only nVidia graphics cards that remain fully and natively supported since macOS Mojave are Kepler ones. See our Supported/unsupported graphics cards thread in our Technical Info, R&D->Graphics section for guidance. Of course, you may choose to fallback to your Intel HD P530 iGPU instead. That should be fully supported with the usual settings for Intel HD 530 graphics.

Whilst I can understand @Baio77's desire for a single unified patching SSDT (it looks nice and simple), to me it's a kind of step back because it totally hides what patches are applied without looking into the SSDT and it makes ACPI troubleshooting much more difficult. Dedicated specifically-named SSDTs have the advantage of being readily identifiable in terms of patches and can easily be individually enabled/disabled for troubleshooting. Now I say this, I say nothing of course...

4th beta released July 27th, 2021. Build 21A5294g. Ok on my Latitude E7270 (Clover r5133) and Satellite Pro R50-B (OC 0.7.0).

No issue on mine with Lilu v1.5.4, AppleALC v1.6.2 and layout #11 in current version 11.5.1 and Clover r5133. Was using the exact same setup in 11.5 without problems either.

Realtek RTL8153 GigEthernet of WD15 Dock certainly used to work OOB in Mojave and Catalina: https://osxlatitude.com/forums/topic/11410-dell-latitude-7490-with-i7-8650u-intel-uhd-620-and-1920x1080-lcd-mojavecatalina/?do=findComment&comment=90288 I would therefore expect it to work for you too.

Please consult our FAQ section re: SIP. There's a dedicated thread to describe it and the values that may be used. By all means, do try and inject CodecCommander from that folder, but if it does not load, you'll have to cache it from /L/E; this will have to be done manually through Terminal and after enabling Gatekeeper: sudo spctl --master-enable Reboot then copy the kext to /L/E sudo cp -R <path>/CodecCommander.kext /L*/E*/ Authorise the kext through Security & Privacy PrefPane and reboot again. You may then disable Gatekeeper again if you wish: sudo spctl --master-disable

3rd beta released July 14th. Build 21A5284e. Straightforward update with Clover r5133 on my Skylake/HD520 Latitude E7270. And same with OC 0.7.0 on my Haswell/HD4400 Satellite Pro R50-B.

Are you using CodecCommander kext at all? If not, try it.

With Big Sur, do not attempt to replace a vanilla kext in /S/L/E by a patched one. Simply apply the required changes either through on-the-fly binary patches (as supported by Clover) or, most preferably, injected properties.

HD4000 laptops with screen resolution starting at 1600x900 require Capri layout 0x01660004. Unfortunately, that's a single port layout that only natively supports LVDS/eDP built-in LCD. That's why you need to patch your Capri framebuffer as detailed in the link provided by Jake so that you convert that single-port layout to a 4-port layout that'll support external displays, including HDMI.

No, everything is Ok.

In case you ignore this, the nVidia RTX 2060 dGPU will not be supported. Only the UHD 630 iGPU of the Coffee Lake i7-9750H CPU can be used.

Hey, welcome back! 'been a while indeed. How are you? Looking forward to hearing from you on the forum.

I'd recommend using pre-existing/ready-made SSDTs rather than creating new ones. In all the Hacks I've had, ready-made ones never have been a problem.

Looks like the above method no longer works, certainly not in Big Sur 11.4, possibly before. @Slice reminded us that Gatekeeper can be used as an alternative. Many people often disable Gatekeeper by default through Terminal command: sudo spctl --master-disable Kexts can be cached from /L/E in Big Sur (and Monterey) by re-enabling Gatekeeper, copying the kexts to /L/E through Terminal via sudo commands and authorizing the kexts from Security & Privacy PrefPane. Upon such authorisation, Gatekeeper will rebuild the cache and restart macOS with the newly cached kexts. Gatekeeper can then be disabled again afterwards. sudo spctl --master-enable sudo cp -Rf <path>/xxxx.kext /L*/E*/ GateKeeper can be disabled again afterwards.

No patched DSDT should be required. Only SSDTs.

Can't find any reference to any Aspire (not espire) E 13 on Acer's web site. You'll have to post the correct reference of the model and its specs of course. This being said, the few Google findings I obtained for an Aspire E13 or ES13 all lead to low-end laptops with Bay Trail, Braswell or Apollo Lake CPUs and associated GT1 Intel HD/HD 500 graphics, i.e. platforms not compatible with macOS and therefore unsuitable as Hackintoshes. If this is your case, don't waste your time any longer. https://osxlatitude.com/forums/topic/2998-min-requirements-for-os-xmacos https://osxlatitude.com/forums/topic/8238-supportedunsupported-gpus-graphics-cards

It would be a mistake to believe that the E7470 and the 7490 are "very similar laptops". They're not. Former is a 6th gen Skylake model and latter is 8th gen Kaby Lake R model. They're of different generations and use different CPUs, different chipsets, different iGPUs, different audio codec, etc. Afaik, the only pieces of hardware they have in common are the Intel GigEthernet card and the Realtek SD card reader. Your may create your 7490 OpenCore setup from an existing E7470 one but you must extensively modify it of course. At this point of time, given your stated skill set, I would recommend you use the following process instead: 1) follow the Dortania Opencore guidance for Kaby Lake R laptops 2) grab the last Clover pack I posted in my Latitude 7490 guide and adjust your Opencore setup accordingly (patched tables, properties injection, kexts) Failing that, I believe there are several copies of Opencore EFI folders for Big Sur available in various existing 7490 threads. Here for instance.

I suggest you start by simplifying your properties injection in order to fallback to a minimum set of working properties that do not get graphics acceleration altered by complicated and probably misunderstood properties. Just start with the basics (CFL framebuffer id, device id, fbmem + stolenmem patches if required). Once you have graphics acceleration working, you can look at additional outputs such as HDMI and that sort of things. Please refer to the thread linked in the last post before your 1st one. As I said, it's limpid as far as getting graphics acceleration working is concerned on the exact same platform as you, although OP clearly misunderstood what con0/con1/con2/etc. were in terms of output ports; anyway no reason why his setup would not work for you as long as you apply them the same way. NB: As per our published rules -which I again invite you to read-, please refrain from systematically quoting messages to post replies. Just use the Reply box available at the bottom of each forum page.

Your OC config shows a # character in front of location PciRoot(0x0)/Pci(0x2,0x0) for the iGPU. As such, you're not injecting any properties for your iGPU and that's why you're not getting any graphics acceleration. Uncomment that line, i.e. remove the # character and you should find that your properties injection will get applied. I expect that things should change thereafter... I can't say more about the iGPU connectors patches that are listed other than question their relevance. But that's another story. I'd also suggest you experiment with MacBookPro15,x SMBIOS. I noticed some odd ACPI patches too, though there's a good chance they do no harm, but just irrelevant:

No need for the AppleCpuPmCfgLock kernel patch; that for 2nd gen Sandy Bridge and 3rd gen Ivy Bridge platforms. You opted for SSDT-EC table instead of SSDT-EC-USBX table as recommended in Dortania's documentation. Dortania does state that SSDT-EC is for Broadwell and older systems when SSDT-EC-USBX is for Skylake and later. Being a Coffee Lake platform, your laptop falls into the 2nd category. UHD630 iGPU of i7-9850H carries native id 0x3E9B. As such, no need to inject that exact same device-id through OpenCore. It does no harm of course. MacBookPro16,4 may not be the correct or best SMBIOS to use though MBP16,1/MBP16,4 are 9th gen Coffee Lake with UHD 630 graphics. You could try MacBookPro15,1 or MacBookPro15,3 instead. Absolutely no need for the -no_compat_check boot arg in NVRAM. That's for systems using an officially unsupported SMBIOS in a given macOS version. Not the case here, whether you use MBP15,x or MBP16,x SMBIOS. The boot-arg will do no harm but will block all macOS update offers. If you keep getting back screen, do experiment with other CFL mobile framebuffer layouts such as those listed in the https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md. You may also refer to the suggestions provided in Clover Configurator app. I've never Hackintoshed any Coffee Lake laptop so I don't know how accurate these are but 2018 8th gen CFL MBP15,1 certainly uses layout 0x3E0B0006: You've linked to the Dortania documentation but it appears you did not followed it thoroughly. I suggest you do so using the section written for the Coffee Lake laptops: https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/coffee-lake.html

Please post a zipped copy of you OpenCore EFI folder. Resources subfolder can be removed to minimise size.

5GHz networks should normally be visible with a DW1820A but you may have an issue related to Country Code or something like that. Check what you card shows in SysInfo->Network->Wifi in terms of Locale and Country Code. Then check your box/router settings for 5GHz networks/SSIDs. You may need to use AirPortBrcmFixup and one of its parameters as indicated in our BCM4350 guide. But, what I don't understand the most is that you do not inject anything for your DW1820A given that the entry for it is commented out in your OC config... What's the reason for that?