Hervé

I don't know what you're trying to say here... We publish news and articles whenever we have info to share but we've no active RSS feeds that push info out.

We've not had any RSS feeds for years...

Situation and behaviour regarding Optimus: disabled -> laptop runs on nVidia dGPU only. enabled -> laptop runs on Intel iGPU and nVidia dGPU; dual GPU switching mode on (but unsupported in OS X/macOS). Trouble is that Fermi chips such as the NVS 5200M have no proper support to no support at all in macOS since High Sierra. The buck stopped at Sierra. As such, you can only run Catalina on the Intel HD4000 iGPU. Given that Optimus has to be enabled to that effect, you need to disable the dGPU through ACPI patching in order to prevent it from draining on the battery unnecessarily. Your config shows that you correctly opted for the HiRes Capri Framebuffer 0x01660004 which is required for your HiRes screen 1600x900. This HiRes Framebuffer only offers 1 x video port by default for LVDS/eDP built-in screen so you'll also have to inject additional properties if you ever want to use external monitors (DVI, HDMI, DP; VGA unsupported). You'll find all the necessary details in the dedicated thread to HD4000 graphics available in our R&D->Graphics section. I also noticed you also opted for MBP11,1 SMBIOS; this is a Haswell model that does not require the -no_compat_check boot arg so you could delete that. The boot arg would only be necessary if you opted for an Ivy Bridge model such as MPB9,2 or MPB10,2. You'll also need additional ACPI tables/parameters in your config to trigger support for your keyboards brightness keys; you'll find all the necessary details in my E6230 guide.

You may try and extract your screen's EDID from Windows/Linux, then inject it into macOS through properties passed through your boot loader's config. https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md

No and what you have tried appears to be ThinkPad-specific and therefore unsuitable/not-applicable to your Latitude E7470. DrHurt's and its derivative kexts do trigger proper TrackPad detection in PrefPane and some multi-finger gestures. The major trouble is that, with these kexts, TrackPad dies after wake. https://osxlatitude.com/forums/topic/8285-refined-alps-touchpad-driver/ https://osxlatitude.com/forums/topic/8285-refined-alps-touchpad-driver/page/69/?tab=comments#comment-77013 https://osxlatitude.com/forums/topic/10673-solved-can-e7270-patch-for-3-and-4-finger-working-on-trackpad So, afaik, from a stability and proper usage point of view, the best you can get on the E7x70 to date is basic Trackpad mouse-like functionalities and 2-finger scrolling. See my E7270 guide.

No no no! Leave /S/L/E full vanilla/untouched. Place copies of Lilu + AppleALC (not AppleHDA !) in Clover's kexts folder. Remove VoodooHDA from wherever it is. If it's in /L/E and/or in /S/L/E, rebuild your cache after you delete it. Remove or disable the AppleHDA patch found in your Clover config.

Your sleep issue results from using VoodooSDHC; it breaks sleep so I can only advise you to get rid of this kext. Your posted IOReg shows PCI id 1180,822 for your SD card reader (ACPI device CDR2@1,2) so it's a Ricoh R5C822 model as stated in the associated properties patch seen in your DSDT. I'm not sure it'll work but I invite you to try the property injection detailed here for the card reader. You can either inject the compatible property through your Clover config or by adding it to the existing DSDT patch. Note that this particular SD card reader certainly used to work under old versions of OS X like Leopard/Snow Leopard (eg: Dell Inspiron 6000) through add-on kext IOSDHCIBlockDevice kext. There were updated 64bit versions of that kext so you could try it after patching its Info.plist file for that Ricoh card reader. https://www.insanelymac.com/forum/topic/286224-iosdhciblockdevicekext-driver-for-jmicron-sd-card-readers-for-107108/ Re: audio, your Clover setup shows that you re-use a patched DSDT from an E6400; it's probably fine from a system's point of you (the M4400 being an E6500 with upgraded Tesla dGPU) but it injects properties that are meant for AppleHDA. If you keep those properties, I would experiment with Lilu + AppleALC and remove the AppleHDA binary patch I saw in the Clover config. If you opt for VoodooHDA, you should also use AppleHDADisabler and you may need to remove the audio properties injected through DSDT. You may also want to revise the IRQNoFlags statements configured for HPET ACPI device and change them from 2/8/11/15 to 0/8/11/15.

Disable hibernation as detailed in our FAQ forum section.

No help possible until you specify what computer you're talking about and provide the specs. Opening a thread entitled "help needed" with such absence of information is not suitable and would normally just be deleted.

These are Chameleon/Enoch boot args so not applicable to Clover or OpenCore if you're using one of those. So, please: post your system's specs specify which bootloader and bootloader version you're using attach a zipped version of your bootloader folder (EFI for Clover/OpenCore, Extra for Chameleon/Enoch) Your issue is indeed USB-related so you could try and boot off other USB ports but make sure you're using USBInjectAll kext. Of course, don't re-use any patched DSDT that comes from a different model.

I don't believe anyone posted a High Sierra guide (or any other version to that effect) for the Precision M4400 model in our Guides section. However, you may follow the process detailed in any existing High Sierra guide published in the aforementioned section. You'll just have to adjust the part relating to the pack by using the package you found. Given that the M4400 is an old late-Penryn C2D (FSB 1066MHz) laptop, you can have a look at my Latitude D630/D830 (nVidia) guides for High Sierra or any such guide for the E6400/E6500 (nVidia). The Precision M4400 is effectively a Latitude E6500 with a more powerful Tesla dGPU. Please post your full system's specs if you need further assistance.

5th beta released August 11th, 2021. Build 21A5304g. Ok on my Latitude E7270 (Clover r5133) and Satellite Pro R50-B (OC 0.7.0).

That EFI folder does not appear to use/inject SSDT-PNLF table which, by far and large, is necessary to obtain brightness control. After you've added that table and rebooted/reset NVRAM, check if your Display PrefPane presents the brightness control bar or not. It should. Once you've asserted you have brightness control, your keyboard brightness keys may not be operational but other keys/key combinations probably will. You mar refer to this guide to remap brightness control keys.

As stated in my previous reply: EDP was OSXLatitude's own post-install tuning tool. It had nothing to do with bootloading. After its demise back in 2014/2015, fully tuned bootpacks were provided as replacement. References to EDP have now been removed from all those ML with MLPF guides for the old D Series

The old laptops are totally obsolete today but they did run Mac OS X extremely well; I remember fondly the days when I had my D620 and D630 and, God!, did SL feel fast on those! But they've had it by now (especially the flawed nVidia models) for most basic stuff. NB: as per our recent news update on the matter, Lion and Mountain Lion are available off Apple for free so no need for pirate repositories.

This guide is over 8 years old and is obsolete as far as EDP is concerned. Other than removing the deprecated references to EDP tool, I'm not going to revisit those old ML with MLPF guides in 2021 given the obvious obsolescence of the D Series and Mountain Lion. You'd also find it difficult to get your hands on the old MLPF tool these days. Anyway, if you do, you may still follow the guide but just forget about the EDP part. Complete Chameleon/Enoch bootpacks are included in the MLPF guides. I had mentioned this in the ML/MLPF guide for the D430 but must have forgotten to do the same for the other guides: There are no other guides on this site to install unsupported ML on D Series laptops that I know of.

I would invite you too grab the bootpack I posted in my E6220 Mojave guide before I sold the laptop. I re-worked the entire ACPI patches through 5 x SSDT rather than a patched DSDT. SSDT-IMEI, SSDT-PNLF and SSDT-XOSI are all pre-made readily-available tables, only the SSDT-PM is obviously specific to the i5-2520M CPU that was fitted to my E6220. SSDT-Q66 is a table I built to take care of brightness keys and should be applicable to the E6320 too. For your i7-2640M CPU, you should generate your own CPU power management table with Pike R Alpha's well-known script but here's a pre-made one: SSDT-PM_i7-2640M.zip The Clover config is re-usable on the E6320 but a few adjustments are expected to be required on the properties injection part because I did add some cosmetic info that were specific to ExpressCard slot or mini-PCIe slots at their exact IO location. These locations may differ on the E6320 but this can be adjusted once you've provided an extracted IOReg. Rest assured that the properties injected in the E6220 config will not interfere or cause issues. On the kexts front, all is re-usable too except the USBPorts which was specifically built for thew E6220. I expect you'd have to build your own through Hackintool app. Meantime, you would probably need to use USBInjectAll kext as a temporary replacement.

Update Lilu and its PlugIns to latest versions. You're using very old versions from early 2020. You should also enable the patch to rename HPET's _CRS to XCRS in the original DSDT since you're injecting a modified one through SSDT. That patch is disabled in your config.

Post a zipped copy of your bootloader EFI folder. Please specify which version of bootloader you used.

GT710 will be Ok as long as it's a Kepler card, not a Fermi one. Kepler cards are fully and natively supported OOB.

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