Hervé

Well, I think it's pretty much a closed matter: systematic black screen if you only run on the nVidia dGPU (Optimus disabled). All those tests are useless if they can only be completed with Optimus enabled, i.e. when you run on the HD4600 iGPU. So, as far as I'm concerned, you'll have to accept that you need to run with the HD4600 iGPU knowing that the nVidia dGPU can clearly be used for external screens (at least HDMI). There's probably a good chance you would not get any HDMI output if you disabled the dGPU through ACPI patching. But do that if you're never gonna use an external screen and you want to save battery life when you run macOS.

Obviously, the value shown in IOReg is the one in use... So you may try and experiment with the tool mentioned at Dortania. No guarantee that any of this will bring life to the built-in LCD with nVidia graphics-only of course. One other thing to try is boot your Big Sur (or any other macOS version) USB installer and, once (or if) your reach the installation screen on the built-in LCD, open up Terminal to check the NVCAP value in IOReg with the following command: ioreg -l | grep NVCAP It may show a different value that what you previously had. That's how I got VGA output to work on the GT730 fitted to my old C2D desktop: initially, I had no VGA output -only DVI-D and HDMI- and NVCAP was showing a given default value once system was booted up. One day, after my partition got corrupted, I rebooted the USB installer with dual DVI + VGA screens connected and, to my surprise, the VGA screen was active and displaying video once I reached the macOS installation screen. On checking the NVCAP value in IOReg, it showed a different value than the one I had before. Once I injected that value in my bootloader config file, I've had all outputs fully working ever since, including VGA.

Oh that's right, I had also mentioned NVCAP but not provided a specific value, just listed the one shown in your IOReg (which is gone now). Basically, with Intel iGPUs, video outputs are handled through connectors and connector types (LVDS/eDP, DVI, DP, HDMI) whereas, with nVidia graphics, it's the NVCAP value that defines the video outputs. It's somehow detailed in the Dortania documentation at following URL but, with a Google search, you would also find old threads on the Net in other Hackintosh forums about it: https://dortania.github.io/OpenCore-Post-Install/gpu-patching/nvidia-patching/

Looks like our server took a hit this today and all posts/threads made since Sunday afternoon or Monday are gone. Rest assured there was no Moderator's/Admin's actions to deleted posts/threads. Sorry but I can't remember all that I had posted but I believe I had stated that your posted IOReg showed built-in LCD attached to HD4600 iGPU and an external monitor attached to the nVidia dGPU (I think it was HDMI). I had re-affirmed my belief that the built-in LCD is probably wired to/controlled by the iGPU but, having looked at your OC config, you could try the following boot-args adjustments with Optimus disabled in BIOS (i.e. only nVidia dGPU active): given that you are using MBP11,5 SMBIOS, i.e. a fully supported platform in Big Sur, you could remove the -no_compat_check boot arg of your OC config since it's unnecessary and will prevent Big Sur updates from being offered to you. change your csr-active-config value from 0x7FF to something where the 2nd nibble does not set bit 5 to 1 which enables Apple Internal. When that SIP flag is enabled, Big Sur updates are not offered. As such, you may change your value to 0x7EF. I recommend you consult our dedicated thread on disabling SIP that's available in our FAQ section. add boot arg agdpmod=pikera or agdpmod=vit9696 in case Apple Graphics Device Policy is somehow responsible for black built-in screen. With such boot arg, AGDP will be disabled/bypassed.

You have an eDP display type. Connector type is the same in OS X/macOS at least for Intel iGPU. Please note that things are very different with nVidia dGPUs with which output port types are controlled by NVCAP (and the registered connector type does not really matter). As I said, none of this really matters if the built-in LCD is wired to/controlled by the Intel iGPU...On the other hand, you may find that external output such as HDMI are controlled by the dGPU. You'd have to check that out in IOReg having opted for iGPU as main graphics card with Optimus enabled in BIOS and the dGPU not disabled.

Translucency of Finder's bar & Dock Info in About this Mac Info in SysInfo->Graphics In SysInfo->Software->Extensions, check if nVidia Kepler drivers are loaded (GeForce + NVDAResman + NVDAGK100Hal) General responsiveness (Hackintosh will be lagging quite severely without graphics acceleration) Graphics card status in IOReg (check with IORegistryExplorer app) Open up Chess (from Applications) and move the board in 3D (should be smooth with graphics acceleration) Open up LaunchPad repeatedly by clicking repeatedly on the icon in the Dock (should be all smooth) Download Heaven from Unigine and check benchmarking (should run fairly smooth and with decent FPS) Download OpenGL Extensions Viewer (off the AppStore) and run Cube/King tests etc. etc.

GT710 is expected to be supported OOB as long as it is a Kepler model (GK208 chip). If it's a Fermi model (GF1xx chip), it won't be supported at all (in any version past El Capitan/Sierra). https://www.techpowerup.com/gpu-specs/?mfgr=NVIDIA&mobile=No&workstation=No&igp=No&generation=GeForce 700&memtype=DDR3&sort=generation To identify your card's chipset, you may use apps such as GPUZ in Windows for instance. Or any other app/tool that will show you the chip model and/or the info about shaders/TMUs/ROPs. The Zotac part # should also be indicated somewhere on the card (like on a sticker) and you may look that up on GPUZoo.com. Make sure you use the SMBIOS of an iMac with nVidia graphics (eg: iMac 14,2/14,3) or graphics probably won't initialise, as seems to be the case. Given that these models are not officially supported by Big Sur, you'll have to use the boot parameter -no_compat_check.

Probably not; there's a fair chance that built-in LCD is wired to/driven by the iGPU so, if you disable it... My understanding is that: Optimus disabled -> nVidia dGPU only Optimus enabled -> Intel iGPU + nVidia dGPU active Afaik, you'll only be able to get your built-in LCD active with the iGPU. So, yes, in my opinion, you have to accept it's an unresolvable fact.

Try iMac14,2 SMBIOS and see if that makes a difference; you never know.

Why change the device property for your wireless card to that of BCM4352 (14e4:43b1) which is not natively supported in Big Sur when your signature shows "BCM94360 w/ adapter" ? Given the mention of an adapter, I can only assume it's an Apple Card which is obviously supported OOB and would not require any property injection other than cosmetic ones to be listed in SysInfo (model & slot-name). But certainly no compatible statement required and not one to declare compatibility with any unsupported card.

Please note that listing PCI devices in SysInfo is usually purely cosmetic and does not make anything work, unless accompanied by specific properties aimed at that very purpose.

Look at all existing E6x40 Catalina threads available in this E6xxx section.

Again, knowing your hardware is a mandatory pre-requisite to succeed in building a Hackintosh... Back in the days when I had one, I posted a guide for the E6440 which basically listed the hardware specs. LAN/Ethernet card is Intel so please, pretty please, get rid of those Realtek or Atheros LAN kexts non-sense. Also get rid of those FakePCIID kexts, you're highly unlikely to need them now given that they're mostly deprecated these days. Please specify the make and model of your wireless card (remove the bottom tray to physically check it if necessary) then head over to our R&D->Wireless forum section to, at minimum, consult our posted inventories. With regards to essential kexts such as VirtualSMC (& PlugIns), Lilu (& PlugIns such as AppleALC or WhateverGreen), make sure you've grabbed the latest versions off their relevant repositories on the Net. Use Google to find them if required. With regards to BIOS settings, please check the dedicated thread on the matter in this very section and adjust your settings accordingly. With regards to the actual Clover config itself... well... ouch... it's a pile of crap! Whoever used this could not possible run a 6440 properly! Far too much duplicate, deprecated and incorrect stuff in there, from ACPI patches to injected device properties or boot args, binary patches and other patched ACPI tables. I'll try and post an adequate alternative asap because -again- Ouch!

We have plenty of guides and threads relating to the E6440 here and I would suggest you grab your Clover pack from there rather than any other obscure place you must have grabbed yours from. You must clean up your Clover setup and get rid of all those useless kexts you've got in the kexts folder. Knowing your hardware is a mandatory pre-requisite. Had you done so, you'd have quickly realised how mad (not to say anything else) it is to just throw all sorts of LAN / wireless / XHCI / RAID / SATA / FakePCIID / etc. kexts at the system. E6440 is a Haswell laptop and therefore built on Series 8 chipset. As such adding kexts for Series 100, 200 or whatever else is pure non-sense for instance. Clean-up and start afresh. Use Clover v5119 max to avoid the Big Sur-related quirks stuff.

Your GB5 scores certainly look Ok. Everymac.com shows that an iMac15,1 with exact same i5-4690 CPU obtains this: Single Core: 927 Multiple Core: 2925 https://everymac.com/systems/apple/imac/specs/imac-core-i5-3.5-27-inch-aluminum-retina-5k-late-2014-specs.html This being said, you should adjust the following elements of your Clover config: get rid of AICPUPM patch, it's for Sandy Bridge and Ivy Bridge platforms only get rid of XCPM patch, you only need KernelPm since you've enabled PluginType in the ACPI section It probably won't make a difference, but it'll be cleaner. On the other hand, I suspect a likely issue with your RX580 graphics card which may cause the sluggishness you observe. You have a HIS model and that brand is part of those that are not recommended due to known issues with the VBIOS. You would have to dig into the fixes or workarounds that may exist (I can't help you on that) or consider flashing your card's BIOS. Failing that, best brand to use is Sapphire... https://dortania.github.io/GPU-Buyers-Guide/modern-gpus/amd-gpu.html#polaris-10-and-20-series As for USB ports, well, just follow the old and well documented process to inject the correct and necessary properties (injector kext, Hackintool app, etc.).

Of course, your true screen resolution remains at 1366x768; it's just software upscaling, not true full HD res of course and resulting picture quality is naturally a little degraded. 1600x900 is probably a better resolution on a 12,5" LCD than 1920x1080... Also has to be 16:9 aspect.

Most painless card as possible? Go for an Apple BCM94360CD card + a mini-PCIe adapter. That's what I fitted into my Latitude E6220 and E6230 years ago and never had to look back or even think about wireless or Bluetooth any more. See our dedicated thread on the matter in our R&D->Wireless section. For the rest, well, I don't want to be rude or slap you...

What are you talking about ??? You need to pay attention to what you read. It appears you've totally missed that, as clearly stated in our inventories, Broadcom BCM43228 is... totally unsupported ! You'll have to replace that card by a supported model. Probably not what you wanted to hear but that's the reality. End of story.

Not looked into the provided Clover EFI folder and config in details but I can see that the patched DSDT already contains several/many of subsequent patches offered through the accompanying SSDT or set in the config. Not quite certain of the benefits of duplicating things here, in fact, possibly the contrary. Example #1: iGPU device in patched DSDT: iGPU properties injection & Graphics in config: Example #2: EHCx and XHC devices in patched DSDT: SSDT-EH0x/SSDT-XHC injected tables: I would suggest returning to a more basic setup without duplicates (especially ACPI patches) to begin with.

Please search the forum and consult our FAQ section before posting. https://osxlatitude.com/forums/topic/11138-inventory-of-supportedunsupported-wireless-cards-2-sierra-big-sur As a general rule, avoid making copies of the same kexts in multiple places; best recipe for trouble unless you fully master what you're doing... You either cache your kexts (ideally from /L/E) or you inject them from your boot loader's EFI kexts folder.

A little update further to recent discussions at InsanelyMac on the matter of SIP and macOS updates not being offered in Big Sur. 1st of all, it should be pointed out that Big Sur introduced a new 12th flag for unauthenticated root updating SIP as follows: nibble: #3 | #2 | #1 nibble bits: 4 3 2 1 | 4 3 2 1 | 4 3 2 1 bits: 12 11 10 9 | 8 7 6 5 | 4 3 2 1 - - - - - - - - - - - - | | | | | | | | | | | | | | | | | | | | | | | | / | | | | | | | | | | | Unauth. Root / | | | | | | | | | | Policy Over. / | | | | | | | | | Kext app. / | | | | | | | | Recov. OS / | | | | | | \ Device Config. / | | | | \ Kext Sig. NVRAM Prot. / | | \ FS Prot. DTrace Rest. / \ Task for PID Apple Int. Kernel Debug. where: Bit #1 = Allow untrusted kexts Bit #2 = Allow unrestricted FileSystem Bit #3 = Allow task for PID Bit #4 = Allow kernel debugger Bit #5 = Allow Apple internal Bit #6 = Allow unrestricted DTrace Bit #7 = Allow unrestricted NVRAM Bit #8 = Allow device configuration Bit #9 = Allow any recovery OS Bit #10 = Allow unapproved kexts Bit #11 = Allow executable policy override Bit #12 = Allow unauthenticated root Source: csr.h (in bsd/sys folder) of Big Sur 11's published XNU source code at https://opensource.apple.com/ Initially, back in the days of El Capitan, disabling SIP was mostly required to load add-on kexts, especially when these were cached. With Big Sur, this is not really required with add-on kexts being injected from Clover and/or OpenCore and SIP can usually remain enabled with no particular side effects/impacts. For those who still want to disable SIP -for instance if booting Big Sur with Clover and using cached kexts- it's important not to set all flags to 1 as this blocks/prevents Big Sur updates from being offered to the Hackintosh. This is typically what happens to people who use csr-active-config 0xFFF as recommended in Dortania's OpenCore documentation. Such a value results in the following SIP status: admin@E6230 ~ % nvram -p | grep csr csr-active-config %ff%0f%00%00 admin@E6230 ~ % admin@E6230 ~ % csrutil status System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: enabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled BaseSystem Verification: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state. However, Apple Internal flag needs to be kept disabled (i.e. bit #5 unset) for Big Sur updates to be offered. Alternative csr-active-config values such as 0x67 / 0x267 / 0x867 / 0xA67 / 0xFEF are therefore recommended instead of 0xFFF. Example with 0xFEF: admin@E6230 ~ % nvram -p | grep csr csr-active-config %ef%0f%00%00 admin@E6230 ~ % admin@E6230 ~ % csrutil status System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled BaseSystem Verification: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Your OC config is incorrect in several instances: you opted for XCPM on this Ivy Bridge laptop and that no longer works (well) afaik: Remove the AppleXcpmCgfLock quirk from the Kernel section only to keep the AppleCpuPmCfgLock quirk Remove the SSDT-PLUG.aml table from your OpenCore EFI/ACPI folder and replace it by your CPU-specific power management SSDT table (that you can rename SSDT-PM if you wish) generated with good old generator script from Pike R Alpha. It's the best solution for Sandy and Ivy Bridge laptops. Then, in your config's ACPI section, replace the defunct reference to SSDT-PLUG by the name of your generated CPU PM SSDT. In your OC config's Device Properties section, you need to add the following properties against your iGPU to reduce framebuffer memory size from 16MB to 8MB (or you'll get glitches): framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00008000 DATA Not sure you need SSDT-HPET table. Not sure you need -wegnoegpu boot arg in NVRAM settings. Does your E5430 have a dGPU that needs disabling? alcid=1 seems incorrect to me if, as I suspect, your E5430 is fitted with same IDT audio codec as the E6x30, in which case the correct layout id is 12 (0x0C). you did not say which macOS (or OS X) version you're trying to install but you've set csr-active-config NVRAM parameter to 3. This was fine for older OS versions but more recent versions would typically require different values. It really depends on what you want to disable in SIP Check the OC pack I had posted in my E6230 Big Sur guide and build from it.

You did adjust the relevant PrefPanes for Dock effects and Hot corners, right?

Better replace the card with a compatible Broadcom model. Your Wifi 6 will be kind of wasted with the current limitations in macOS.

What about it? Do you see any reply to that thread which dates back to Big Sur beta? Of course Sandy Bridge CPUs/platforms can run Big Sur... with a compatible graphics card! As I said: no support for HD3000 graphics in Big Sur. If you need further confirmation, read this: https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/ If you don't believe me, go ahead and knock yourself out at it.