Hervé

You inject a subsystem-vendor-id property for the SD card reader; afaik, that's not necessary, the SD card reader of all my E6220/E6230/E6440/E7250 having perfectly worked with just the compatible statement (the other properties being cosmetic for reporting in SysInfo). As such, try and remove that property injection from your OC config. See this thread for details: https://osxlatitude.com/forums/topic/7346-applesdxc-driverdsdt-patch-for-o2-micro-sd-card-readers

Afaik, you cannot disable those Fn-<key> that act as others would be expected to, even if you apply patches to get the expected keys to work.

Your setup looks Ok from a graphics acceleration and CPU power management point of view. However, your setup should be cleaned up to avoid all possible confusion or errors on the Keyboard/Touchpad (i.e. PS2 controller) front as well as the USB front: your kexts folder contains 3 x PS2 controller kexts but you only use one, which is correct. The kext you want for an E6440 is VoodooPS2Controller R6 compiled by Bronxteck posted here in Dr Hurt's dedicated Alps controller thread. I would delete/suppress the other kexts from the kexts folder and your OC config. you've got USBInjectAll kext and a SSDT-UIAC-E7440 patched table + a USBPorts_E7440 kext. I would refrain from re-using E7440 stuff that may not apply to the E6440 and reboot with only USBInjectAll in order to subsequently generate your own E6440 USB table and kext with Hackintool app. You probably know this already but you use either USBInjectAll + SSDT-UIAC table or generated USBPorts kext. you do not rename EHCx USB2 controllers to EH0x as is normally required since El Capitan. Can't remember if the E6440 USB2 ports still operate without the renaming but I certainly saw both EHC1 and EHC2 controllers in your posted IOReg extract. All could be Ok on that front. Also: given that you're injected a SSDT-EC table that defines a (fake) EC device, you do not need to rename ECDV to EC in your OC config; I would get rid of that ACPI patch mobile HD4600 does not usually require fbmem/stolenmem/portcount/etc. patches as currently defined in your OC config. I would have expected the fake id + layout id + HDMI connector patch to suffice (+ patches for the other connectors/ports if you use a docking station). The cursormem patch is only required if you experience glitches but I never did when I had my E6440. In addition, there is no need to inject values that are identical to the vanilla/default arrangement of the selected framebuffer layout; for instance, you inject a portcount=4 property to 4 x port layout 0x0a260006; that's unnecessary though it does no harm of course... AppleCpuPmCfgLock is the AICPUPM patch applicable to Sandy Bridge and Ivy Bridge platforms; it does not apply to your Haswell laptop (for which CPU power management is handled by the kernel so AppleXcpmCfgLock patch suffices) and you can therefore disable it (though it does no harm). -no_compat_check boot arg is unnecessary with SMBIOS MacBookPro11,1 (it's a platform supported by Big Sur) and will prevent you from getting updates.

Updates are not offered when running macOS with the -no_compat_check boot arg. There are 2 x pre-requisites for obtaining Big Sur update offers: the SMBIOS of a Mac model compatible/supported by Big Sur (MBP11,x minimum). a SIP value that does not enable Apple Internal; it's disabled by default and must be kept disabled (bit #5 of SIP value, see here for details).

@truceFR the behaviour of the Touchpad as you described it seems pretty normal to me: yes you use the "palm" or "face" of your fingers to move the cursor, not the tip. I must admit that don't know any TouchPad that would work like that. I had never even thought or considered doing it but I can too confirm that 2-finger scrolling appears to work when using the tip of the fingers; it's a very unusual way to use a TouchPad and certainly feels very weird and awkward to me. I certainly could not get mouse control or tap-to-click working when using the tip of my finger but, again, that felt really weird... As for the Touchpad sensitivity, it's indeed adjustable through the FingerZ parameter of the kext's Info.plist file. Dr Hurt's kext is fully compatible with the TouchPad PrefPane so there are things you can control from there. Same from the accessibility PrefPane.

Lost cause for BCM4313 afaik; years ago, we posted in the Wireless section that these BCM431x had been abandoned with no workaround. You'll have to replace yours. TouchPad should work perfectly with Dr Hurt's VoodooPS2Controller R6; it's available in the dedicated thread in the relevant R&D section. Use the version labeled "compiled by Bronxteck". It's also available in all recent guides I posted for the E6230. Re: the overlap behind the Dock that you mentioned, I had never noticed it but just did on me E6230 (1366x768). Nothing to worry about and not much you can do about it; it's just that the Apple Macs do not have screens with such low resolution and macOS does not cater for LoRes Hackintoshes. It's not a bug for sure and nothing driven by kexts. You could always try and see if something can be done through the Accessibility PrefPane, if possible at all.

Try and add boot arg "darkwake=no".

This type of low-power Kaby Lake laptop is fully compatible with Big Sur. The 2017 MacBook10,1 was based on that same kind of hardware platform. Compile the list of hardware components, look for appropriate kexts and follow the OpenCore guidance published at Dortania for mobile Kaby Lake platforms. Re: Intel wireless, consult the OpenIntel/Wireless itlwm Github repo.

Target macOS release: Big Sur 11.x This is a Clover-based installation using the well-known/well documented vanilla method detailed below: Working: full QE/CI with HD520 graphics (with SKL layout 0x19160000) HDMI output OOB but built-in LCD goes off on 1st cable connection. With WEG boot arg igfxonln=1, LCD picture is recovered after closing then re-opening the LID and HDMI is on at 1st boot & after wake mDP output OOB touchscreen with USB HID fix (patch of IOHIDFamily to fake single-user mode) due to Apple dropping support for old USB hardware full audio, including jack microphone input and headset output (with AppleALC kext & layout-id 11) HDMI audio (with SKL con1 connector-type patch) built-in Gigabit Ethernet (with IntelMausiEthernet kext) full CPU power management, including Turbo boost to 3.4GHz (with PlugIn type settings) sleep: Ok through Apple menu->Sleep, lid closure, power button, Fn-Insert and energy savings settings with hibernation mode set to 0 (sleep to RAM) and /var/vm/sleepimage file deleted. wake: Ok through lid opening and power button wireless & bluetooth with any compatible card/USB dongle battery management and monitoring (with ACPIBatteryManager kext) SD card reader (with Cholonan's Sineteck-rtsx kext) integrated webcam OOB keyboard backlight control OOB (for backlit models) audio volume control through Fn-F1/Fn-F2/Fn-F3 brightness control through Fn-F11/Fn-F12 touchpad basic features, incl. buttons (with Rehabman's VoodooPS2Controller kext) but not recognised in PrefPane USB3.0 ports (with Hackintool's generated USBPorts kext) Not Working: N/A Not tested: SmartCard reader GeekBench v4.4.4 (64bit) gives the following rating: 1) 11.x USB installer creation Using a USB key of 16GB minimum, create a Big Sur USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Big\ Sur.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Big Sur installation package (eg: /Applications if freshly downloaded) <USB key> = name of formatted USB volume (eg: USB_16GB) The process will take several minutes. Once completed: install Clover bootloader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI Drivers Recommended drivers FSInject SMCHelper Human Interface Devices (optional) Ps2MouseDxe UsbMouseDxe FileSystem Drivers ApfsDriverLoader Memory fix drivers OpenRuntime Additional Drivers (optional) NvmExpressDxe PartitionDxe Themes (optional) Install Clover Preference Pane (optional) you may use version r5133 attached below: Clover_r5133.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer Clover Configurator.zip add the (unzipped) HFSPlus driver attached below to the EFI/CLOVER/drivers/UEFI folder HFSPlus.efi.zip open this EFI partition and transfer/copy the files & folders from the Latitude E7270 Big Sur Clover pack below to the EFI/CLOVER folder Clover_Pack_E7270_BigSur.zip 2) 11.x installation boot the Big Sur USB installer at the Clover main menu, select the "Install macOS Big Sur" partition (but don't press [ENTER]) press [SPACE], select -v verbose option in the menu, then choose to boot with the selected options proceed with installation, creating & formatting the target Big Sur installation through Disk Utility as/if required on 1st reboot, boot off the USB installer and select the freshly created "macOS install from <target Big Sur partition>" repeat this until this partition is no longer offered and only the target Big Sur partition is left to boot Reboot the target Big Sur partition via your USB installer 3) Post-installation tuning Once the target Big Sur partition has booted, complete the 1st boot configuration tuning Once at the desktop, install Clover bootloader on the Big Sur partition/disk with the customised settings listed above Once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the Big Sur partition/disk Open this EFI partition and transfer the files & folders from the above Latitude E7270 Big Sur Clover pack to the EFI/Clover folder You may then reboot and verify that Big Sur boots off your disk through Clover Please note that: Clover config of the pack contains HDMI-audio SKL framebuffer patch. Clover config of the pack contains disabled settings for DW1820A wireless card. Enable or remove as appropriate. Edit: 22 Dec 2021 Touchscreen working after adding the USB HID fix for Big Sur and later. See details below, after Monterey guide. Edit: 17 Jan 2024 Revised bootpack with modified SSDT-GPRW patched ACPI table to fix intermittent loss of Bluetooth on wake.

@mringis Apple dropped AirPortBrcm4331 kext in Catalina; as such no support for Broadcom card 14e4:43b1 without applying some tricks. Look into our published wireless cards 2nd inventory for details.

Both work just done in Big Sur, yes; simple matter of properly setting up SMBIOS, serial numbers, ROM, MLB, etc. Ideally, though I'm not sure it's still valid, set LAN/Ethernet interface as 1st interface en0. See our FAQ topic on the matter.

Try the card in all PCIe slots: WLAN, min-PCIe and WWAN. It should at leat be reported in IOReg; also make sure all wireless features are enabled in BIOS.

Target macOS release: Catalina 10.15.x This is a Clover-based installation using the well-known/well documented vanilla method detailed below: Working: full QE/CI with HD520 graphics (with SKL layout 0x19160000) HDMI output OOB but built-in LCD goes off on 1st cable connection. With WEG boot arg igfxonln=1, LCD picture is recovered after closing then re-opening the LID and HDMI is on at 1st boot & after wake mDP output OOB touchscreen OOB full audio, including jack microphone input and headset output (with AppleALC kext & layout-id 11) HDMI audio (with SKL con1 connector-type patch) built-in Gigabit Ethernet (with IntelMausiEthernet kext) full CPU power management, including Turbo boost to 3.4GHz (with PlugIn type settings) sleep: Ok through Apple menu->Sleep, lid closure, power button, Fn-Insert and energy savings settings with hibernation mode set to 0 (sleep to RAM) and /var/vm/sleepimage file deleted. wake: Ok through lid opening and power button wireless & bluetooth with any compatible card/USB dongle battery management and monitoring (with ACPIBatteryManager kext) SD card reader (with Cholonan's Sineteck-rtsx kext) integrated webcam OOB keyboard backlight control OOB (for backlit models) audio volume control through Fn-F1/Fn-F2/Fn-F3 brightness control through Fn-F11/Fn-F12 touchpad basic features, incl. buttons (with Rehabman's VoodooPS2Controller kext) but not recognised in PrefPane USB3.0 ports (with Hackintool's generated USBPorts kext) Not Working: N/A Not tested: SmartCard reader GeekBench v4.4.4 (64bit) gives the following rating: 1) 10.15 USB installer creation Using a USB key of 8GB minimum, create a Catalina USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Catalina.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Catalina installation package (eg: /Applications if freshly downloaded) <USB key> = name of formatted USB volume (eg: USB_8GB) The process will take several minutes. Once completed: install Clover bootloader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI Drivers Recommended drivers FSInject HFSPlus SMCHelper Human Interface Devices (optional) Ps2MouseDxe UsbMouseDxe Additional Drivers NvmExpressDxe PartitionDxe (optional) Themes (optional) Install Clover Preference Pane (optional) you may use version r5119 attached below: Clover_r5119.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer Clover Configurator.zip open this EFI partition and transfer/copy the files & folders from the Latitude E7270 Catalina Clover pack below to the EFI/Clover folder Clover_Pack_E7270_Cat.zip add the following ApfsDriverLoader to the EFI/Clover/drivers folder since Clover versions of that era stopped offering this driver (Catalina disk/partition won't be seen otherwise) ApfsDriverLoader.efi.zip 2) 10.15 installation boot the Catalina USB installer at the Clover main menu, select the "Install macOS Catalina" partition (but don't press [ENTER]) press [SPACE], select -v verbose option in the menu, then choose to boot with the selected options proceed with installation, creating & formatting the target Catalina installation through Disk Utility as/if required on 1st reboot, boot off the USB installer and select the freshly created "macOS install from <target Catalina partition>" repeat this until this partition is no longer offered and only the target Catalina partition is left to boot Reboot the target Catalina partition via your USB installer 3) Post-installation tuning Once the target Catalina partition has booted, complete the 1st boot configuration tuning Once at the desktop, install Clover bootloader on the Catalina partition/disk with the customised settings listed above Once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the Catalina partition/disk Open this EFI partition and transfer the files & folders from the above Latitude E7270 Catalina Clover pack to the EFI/Clover folder You may then reboot and verify that Catalina boots off your disk through Clover Please note that: Clover config of the pack contains HDMI-audio SKL framebuffer patch. Clover config of the pack contains disabled settings for DW1820A wireless card. Enable or remove as appropriate. Caching add-on kexts from /L/E is faster than injecting them from E/C/k/O. After any kexts modification, whether to /S/L/E or to /L/E, repair permissions and rebuild cache. Edit: 17 Jan 2024 Revised bootpack with modified SSDT-GPRW patched ACPI table to fix intermittent loss of Bluetooth on wake.

Re: trackpad, I experimented with several kexts and my results were as follows: with Dinesh's ApplePS2Controller, all basic features are present but no trackpad in the PrefPane and brightness keys cannot be enabled through the usual DSDT/SSDT patching. with Dr Hurt's last beta/RC VoodooPS2Controller versions that support Alps V7/V8 trackpad, all basic features are present, trackpad is detected and configurable in the PrefPane and brightness keys can be enabled. However, trackpad is dead after wake as reported all those years ago. with Rehabman's last VoodooPS2Controller, all basic features are present t and brightness keys can be enabled but no trackpad in the PrefPane. I opted for the 3rd option.

Try and experiment with Whiskey Lake UHD620 settings: ig-platform-id 0x3EA50009 device-id 0x3EA5 The only other alternative I could suggest would be Kaby Lake R settings but I somehow doubt it would work: ig-platform-id 0x591B0000 or 0x59160009 for instance (I used latter on my previous KBL R/UHD620 Latitude 7490) or any other KBL mobile id device-id 0x5916

Target macOS release: Mojave 10.14.x This is a Clover-based installation using the well-known/well-documented vanilla manual method detailed below: Working: full QE/CI with HD520 graphics (with SKL layout 0x19160000) HDMI output OOB but built-in LCD goes off on 1st cable connection. With WEG boot arg igfxonln=1, LCD picture is recovered after closing then re-opening the LID and HDMI is on at 1st boot & after wake mDP output OOB touchscreen OOB full audio, including jack microphone input and headset output (with AppleALC kext & layout-id 11) HDMI audio (with SKL con1 connector-type patch) built-in Gigabit Ethernet (with IntelMausiEthernet kext) full CPU power management, including Turbo boost to 3.4GHz (with PlugIn type settings) sleep: Ok through Apple menu->Sleep, lid closure, power button, Fn-Insert and energy savings settings with hibernation mode set to 0 (sleep to RAM) and /var/vm/sleepimage file deleted. wake: Ok through lid opening and power button wireless & bluetooth with any compatible card/USB dongle battery management and monitoring (with ACPIBatteryManager kext) SD card reader (with Cholonan's Sineteck-rtsx kext) integrated webcam OOB keyboard backlight control OOB (for backlit models) audio volume control through Fn-F1/Fn-F2/Fn-F3 brightness control through Fn-F11/Fn-F12 touchpad basic features, incl. buttons (with Rehabman's VoodooPS2Controller kext) but not recognised in PrefPane USB3.0 ports (with Hackintool's generated USBPorts kext) Not Working: N/A Not tested: SmartCard reader GeekBench v2.4.4 (32bit) gives a good 8400+ rating: 1) 10.14 USB installer creation Using a USB key of 8GB minimum, create a Mojave USB installer through the following Terminal command: sudo <path>/Install\ macOS\ Mojave.app/Contents/Resources/createinstallmedia --volume /Volumes/<USB key> where: <path> = location of Mojave installation package (eg: /Applications if freshly downloaded) <USB key> = name of formatted USB volume (eg: USB_8GB) The process will take several minutes. Once completed: install Clover bootloader on the USB installer with the following customised settings: Clover for UEFI booting only Install Clover in the ESP UEFI Drivers -> Recommended drivers ApfsDriverLoader / AptioMemoryFix / DataHubDxe / FSInject / HFSPlus / SMCHelper UEFI Drivers -> Human Interface Devices (optional only) PS2MouseDxe / UsbMouseDxe Themes (optional only) Install Clover PrefPane (optional only) you may use version r5035 attached below or any subsequent version available at Dids' Github repo Clover_v2.5k_r5035.pkg.zip once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the USB installer Clover Configurator.zip open this EFI partition and transfer the files & folders from the E7270 Mojave Clover pack below to the EFI/Clover folder of the EFI partition Clover_Pack_E7270_Moj.zip 2) 10.14 installation boot the Mojave USB installer at the Clover main menu, select the "Install macOS Mojave" partition (but don't press [ENTER]) press [SPACE], select -v verbose option in the menu, then choose to boot with the selected options proceed with installation, creating & formatting the target Mojave partition/disk through Disk Utility as/if required on 1st reboot, boot off the USB installer and select the freshly created "macOS install from <target Mojave partition>" repeat this until this partition is no longer offered and only the target Mojave partition is left to boot 3) Post-Installation tuning Once the target Mojave partition has booted, complete the 1st boot configuration finalisation Once at the desktop, install Clover bootloader on the Mojave partition/disk with the customised settings listed above Once Clover is installed, launch Clover Configurator app and mount the freshly created EFI partition of the Mojave partition/disk Open this EFI partition and transfer the files & folders from the above E7270 Mojave Clover pack to the EFI/Clover folder of the EFI partition You may then reboot and verify that Mojave boots off your disk through Clover After that reboot, finalise post-installation tuning actions such as disabling hibernation, disabling GateKeper, changing all serial numbers, etc. Please note that: Clover config of the pack contains HDMI-audio SKL framebuffer patch. Clover config of the pack contains disabled settings for DW1820A wireless card. Enable or remove as appropriate. Caching add-on kexts from /L/E is faster than injecting them from E/C/k/O. After any kexts modification, whether to /S/L/E or to /L/E, repair permissions and rebuild cache. Edit: 17 Jan 2024 Revised bootpack with modified SSDT-GPRW patched ACPI table to fix intermittent loss of Bluetooth on wake.

Sorry, 'beats me.

From memory, it's a general behaviour... You could try the WEG optional boot arg igfxonln=1 and see if that makes any difference. https://github.com/acidanthera/WhateverGreen

Your posted IOreg shows that your Comet Lake i5-10210U is fitted with Intel UHD for 10th ten processor iGPU with id 0x9B41. But is it its native id or just the result of the property you injected (please note that injecting any device's native id is totally pointless)? According to the Intel specs which I tried to summarise here, iGPU id 0x9B41 is a 24xEUs iGPU model which can therefore be expected to be supported, but not OOB. As per the WEG user manual, I believe 2 x iGPU properties need to be injected, at minimum: ig-platform-id 0x3EA50009, not 0x3E9B0000 which is for Coffee Lake iGPUs. device-id 0x3E9B and MacBookPro16,1 (or MBP16,3 why not?) SMBIOS alongside.

I'in the process of writing here a detailed description of the manner in which brightness keys operate and how the patches apply and work. Hopefully it'll lit everyone's lantern though it'll be technical given that it's low-level ACPI stuff..

It's still a recurring topic on the fourm, understandably so, so I thought I'd write a little recap about it. Brightness keys patch has been subject to discussion and queries for many years and much has been written on the matter. Among others, Rehabman did some extensive research work on this several years go and provided substantial information and debugging material to work out fixes. The brightness keys patch for many -if not most- Dell laptops since, at least, Ivy Bridge generations can be applied through DSDT patching or through pure SSDT patching. A DSDT patch for E6230 was 1st mentioned at OSXL by @jpz4085 in our old Dr Hurt's VoodooPS2Controller kext thread; the work derived from Rehabman's research and publications. I found that the patch was fully reusable on other models of the E Series (except E6x20) and I fully detailed the DSDT patch code in my E6230, E7250 or 7490 guides. Unless I'm mistaken (happy to be corrected if required), the SSDT patch was derived from the DSDT patch by @Jake Lo and provided in various threads of his that I can't specifically remember. To successfully apply the required SSDT patch, given that a little tuning may be required depending on the target platform, it's most useful to understand that brightness keys of Dell laptops usually operate at ACPI level and according to the following reversed engineered process: brightness keys operation is handled through BRT6 method. BRT6 method is attached to IGPU device but there can be a 2nd BRT6 method under GFX0 (or whatever other name) if the laptop is fitted with a dGPU too. BRT6 is usually called from EV5 method. EV5 method is usually called from SMEE method on the condition that a call to OSID method returns a value greater or equal to 32 (0x20). OSID method returns the value set in ACOS parameter (integer). ACOS is set to different values according to the nature of the Operating System. It is set to 32 (0x20) for Win Vista, 64 (0x40) for Linux or 128 (0x80) for Win7/8/8.1. Value is under 32 for Windows versions older than Vista. I'll pass on the upstream process _Q66->NEVT->SMIE->SMEE which is of no specific interest in the context of this brightness keys patch description. Sample methods grabbed from Latitude E7270's extracted DSDT: BRT6 Method Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) // 1st arg=1 for brightness increase { Notify (LCD, 0x86) } If (And (Arg0, 0x02)) // 1st arg=2 for brigthness decrease { Notify (LCD, 0x87) } } EV5 method Method (EV5, 2, NotSerialized) { \_SB.PCI0.IGPU.BRT6 (Arg0, Arg1) // Call to BRT6 with 2 arguments } SMEE method Method (SMEE, 1, NotSerialized) { Store (Arg0, Local0) Store (GENS (0x11, Zero, Zero), Local0) If (LGreaterEqual (\_SB.OSID (), 0x20)) // If OSID returns a value >= 32 { If (And (Local0, 0x04)) { EV5 (One, Zero) // Call to EV5 with 1st arg set to 1 } If (And (Local0, 0x02)) { EV5 (0x02, Zero) // Call to EV5 with 1st arg set to 2 } } If (And (Local0, 0x08)) { Store (GENS (0x1D, Zero, Zero), Local0) EV17 (Local0, Zero) } } OSID method Method (OSID, 0, NotSerialized) { If (LEqual (ACOS, Zero)) // Check if ACOS lower or equal to 0 { Store (One, ACOS) // Initialises ACOS to 1 Store (Zero, ACSE) If (CondRefOf (\_OSI, Local0)) // Engages in tests according to OS identification { If (_OSI (WXP)) { Store (0x10, ACOS) // Sets ACOS to 16 if Win XP } If (_OSI (WLG)) { Store (0x20, ACOS) // Sets ACOS to 32 if Win Vista } If (_OSI (WIN7)) { Store (0x80, ACOS) // Sets ACOS to 128 if Win7 } If (_OSI (WIN8)) { Store (0x80, ACOS) // Sets ACOS to 128 if Win8 Store (One, ACSE) } If (_OSI (WN81)) { Store (0x80, ACOS) // Sets ACOS to 128 if Win8.1 Store (0x02, ACSE) } If (_OSI (LINX)) { Store (0x40, ACOS) // Sets ACOS to 64 if Linux } } Else { If (STRE (_OS, W98S)) { Store (0x02, ACOS) // Sets ACOS to 2 if Win98 } If (STRE (_OS, WINM)) { Store (0x04, ACOS) // Sets ACOS to 4 if Win ME } If (STRE (_OS, NT5S)) { Store (0x08, ACOS) // Sets ACOS to 8 if Win NT } } } Return (ACOS) // Value returned by OSID method } It should also be noted that, brightness keys patching only appears to work with VoodooPS2Controller kext, not with ApplePS2Controller (at least for me and the platforms I tested). To enable brightness control through the brightness keys of Dell laptops, 2 x things must be done: ensure that OSID returns a value greater or equal to 32 (0x20) for "Darwin" OS (i.e. OS X/macOS) ensure the correct key stroke codes are captured in BRT6 method (by default, BRT6 usually only operates for key stroke codes 0x86 and 0x87) 1) DSDT patch method: This is most probably the simplest of the 2 x methods because it involves very basic and very easy patching of the DSDT: 1st part of the patch is to insert a reference to Darwin OS as one of the tests used to set ACOS parameter to, at least, 32 (0x20). 2nd part of the patch is to insert the relevant key stroke codes in BRT6 method as keyboard event notifications. One code for brightness increase and another one for brightness decrease. Rehabman's ACPI debugging tools have allowed to identify various key codes, depending on laptops: brightness increase: key codes 0x10, 0x206, 0x286, 0x366, 0x0406 brightness decrease: key codes 0x20, 0x205, 0x285, 0x365, 0x0405 I have found that key codes 0x0365 and 0x0366 applied to the Latitude E6x20, E6x30, E6x40, E7x50, E7x70 or other 7x90. @Jake Lo found that codes 0x0405 and 0x0406 applied to other models such as the Precision 5510 or 7510. The DSDT patch can then be applied in the trend of the following code: OSID method Before: Method (OSID, 0, NotSerialized) { If (LEqual (ACOS, Zero)) { [...] If (CondRefOf (\_OSI, Local0)) { [...] If (_OSI (WIN7)) { Store (0x80, ACOS) } [...] } [...] } Return (ACOS) } After: Method (OSID, 0, NotSerialized) { If (LEqual (ACOS, Zero)) { [...] If (CondRefOf (\_OSI, Local0)) { [...] If (LOr (_OSI ("Darwin"), _OSI (WIN7))) // Changes test from Win7-only to Darwin or Win7 { Store (0x80, ACOS) // Thereby setting ACOS to 128 for Darwin, i.e. OS X/macOS } [...] } [...] } Return (ACOS) } BRT6 method Before: Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) } If (And (Arg0, 0x02)) { Notify (LCD, 0x87) } } After: Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) Notify (^^LPCB.PS2K, 0x0366) // Add capture of brightness-up key stroke } If (And (Arg0, 0x02)) { Notify (LCD, 0x87) Notify (^^LPCB.PS2K, 0x0365) // Add capture of brightness-down key stroke } } and that's it! 2) SSDT patch method: Over the last few years, DSDT patching has gradually and increasingly become less fashionable within the Hackintosh community in favour of alternatives in the form of dedicated and specific SSDTs, something which is considered far more efficient because: it's based on on-the-fly ACPI objects renaming in bootloaders. it's based on injection of new ACPI code through small and targeted SSDT tables that are meant for that very supplemental purpose (SSDT means Secondary System Description Table). it avoids extracting, fixing, patching, recompiling and replacing the system's original ACPI tables and most notably the DSDT, something that can be quite arduous at times. However, the process involved is a much more complicated because: it requires to have a minimum and non-negligeable skillset in ACPI coding. it requires to analyse the code of the original ACPI tables and often work out sections of code to bypass/replace (no duplicates allowed or code is useless) So, given that this method makes no change to the DSDT, it must: bypass the DSDT's BRT6 method. replace it by a new method that will include the desired keyboard notification codes; this will be done in a dedicated SSDT that can be called SSDT-BRT6. with regards to OSID and the requirement to make it return a value greater or equal to 32, there are 2 x possibilities that can be considered: as per BRT6, bypass the DSDT's OSID method and replace it by a new method that will set ACOS parameter according to "Darwin" OS replace calls to the _OSI method, that performs tests on the type of OS, by an alternative method that simulates Windows for Darwin. This allows to have the contents of the OSID method executed sequentially and set ACOS according to the last test in the list; as it stands, this happens to be the test on Linux which sets ACOS to 64, i.e. a value greater than 32 which is the minimum required. In order to replace the DSDT's BRT6 method by an alternative one, particular caution must be exercised because only the method must be replaced, not the call to it from EV5; so a little creativity is required here... To achieve this, ACPI renaming can be applied in the boot loader config to replace "BRT6,2" (as per contents of the method's definition) by "BRTX,2" rather than replace just "BRT6". This is achieved by configuring the following on-the-fly DSDT patch in the boot loader's config (the exact Hexadecimal string is found by opening the extracted DSDT in a Hex editor): Find (HEX): 4252543602 // Hexadecimal sequence for "BRT6, 2" when opening DSDT with a Hex editor Replace (HEX): 4252545802 // Hexadecimal sequence for "BRTX, 2" as replacement The replacement BRT6 method can then be defined in the dedicated SSDT-BRT6 patched table with the following code: DefinitionBlock ("", "SSDT", 2, "hack", "BRT6", 0x00000000) { External (_SB_.PCI0.IGPU, DeviceObj) // (from opcode) External (_SB_.PCI0.IGPU.LCD_, DeviceObj) // (from opcode) External (_SB_.PCI0.LPCB.PS2K, DeviceObj) // (from opcode) Scope (_SB.PCI0.IGPU) { Method (BRT6, 2, NotSerialized) { If (LEqual (Arg0, One)) { Notify (LCD, 0x86) Notify (^^LPCB.PS2K, 0x0366) // Capture of brightness-up key stroke } If (And (Arg0, 0x02)) { Notify (LCD, 0x87) Notify (^^LPCB.PS2K, 0x0365) // Capture of brightness-down key stroke } } } } As far as the OSID method is concerned, the trick is simply to rename it to XSID, rename _OSI method to XOSI and inject (Rehabman's ?) pre-existing and publicly available SSDT-XOSI that simulates Win7 or greater for Darwin (it basically returns true to the OS tests). This is achieved by configuring the following on-the-fly DSDT patches in the boot loader's config: Find (HEX): 4F534944 // OSID in Hexadecimal Replace (HEX): 58534944 // XSID in Hexadecimal Find (HEX): 5F4F5349 // _OSI in Hexadecimal Replace (HEX): 584F5349 // XOSI in Hexadecimal Contents of the SSDT-XOSI patched table is as per documented by Rehabman: DefinitionBlock ("", "SSDT", 2, "hack", "XOSI", 0x00000000) { Method (XOSI, 1, NotSerialized) { Store (Package (0x0A) { "Windows", "Windows 2001", "Windows 2001 SP2", "Windows 2006", "Windows 2006 SP1", "Windows 2006.1", "Windows 2009", "Windows 2012", "Windows 2013", "Windows 2015" }, Local0) Return (LNotEqual (Ones, Match (Local0, MEQ, Arg0, MTR, Zero, Zero))) } } And that's it too!

Could be your PS2 controller kext; which one are you using?

Calm down please! And no-one has accused you of any sort of misbehaviour, quite the contrary in fact... The method remains the same, only the PS2K notification values change, that's all. Which is why I wrote "this kind of patch"... In fact, you should be able to refine your patch by further experimenting with it in order to establish which of the 3 x values of each set (10/206/286 & 20/205/285) actually apply to your Inspiron model. I'm pretty sure only 1 of the 3 applies and you would actually find that the BRT6 SSDT provided by Jake also works once you apply the appropriate notification values. Getting the correct keystroke codes is the key here, hence why I linked to the original post/thread where it is clearly mentioned. Nothing else to it and certainly nothing dark or nasty behind my post.

We have known, detailed and used this kind of brightness keys patch for many years on laptops such as the E6xxx or E7xxx series... But thanks for this particular useful contribution for the Inspiron 5570. https://osxlatitude.com/forums/topic/8285-refined-alps-touchpad-driver/?do=findComment&comment=84779 https://osxlatitude.com/forums/topic/8285-refined-alps-touchpad-driver/?do=findComment&comment=84815 https://osxlatitude.com/forums/topic/12129-latitude-e7250-with-i5-5300u-hd5500-and-1366x768-lcd-high-sierramojavecatalina/?do=findComment&comment=93508

Seems OP is using a distro... -> "HackintoshShop.com". @truceFR We don't support distros here, far too much trouble. Please download a genuine Big Sur installation package off Apple/AppStore and follow the numerous guides we've got here for these E6x30 models.