Catalina on Dell Latitude E6410 (Nvidia Graphics) With Working Sleep

[deeveedee]

I took a quick look and can look again tomorrow.  My first observations are:

 

1. Lilu.kext 1.4.2?  Where did you get version 1.4.2?
2. Where is AirportBrcmFixup.kext?  Maybe I missed it?

 

EDIT: Remove the IntelBacklight.kext that you installed.  This is not the correct backlight kext for Nvidia.  The correct backlight kext (if we find one that works) will be based on this thread.

[jande]

Hello!!
I have mojave installed on my Dell E6410 i7 thanks tonyx86 !!!
Tomorrow I will try to install Catalina again.

"tonyx86"" thanks for your help on these posts.

[deeveedee]

Congratulations!

[deeveedee]

EDIT: As I documented later in this thread, brightness key mapping does not appear to be the solution for the brightness slider.  Leaving this post for information only, but I don't believe this will lead to a working brightness slider.

 

EDIT 2: A new lid sleep solution is now attached to Post #1.  This new solution eliminates the need for the ACPIPoller.kext and the Method (LIDP) addition to the DSDT.  

 

------------------------------------------------------------------------------------------------------

 

Below is my progress on getting the Brightness Slider to work.  I would welcome any help if you're interested - specifically, find the correct brightness key mapping.  This solution is almost working.  The only issue appears to be that the brightness slider expects the brightness keys to be Fn-F12 (brightness up) and Fn-F5 (brightness down), so the slider is mapped to the wrong keys.  I suspect that if we modify the DSDT to map the slider to the correct keys, the slider will be working.  There are plenty of key mapping posts, so this should be the "easy" part.

 

My work is as follows (and attached):

• DSDT is modified as mentioned a few posts ago for the lid sleep.  Also added since my last post are "@0,backlight-control" and "AAPL,backlight-control" which are from the E6430 thread but I suspect are unnecessary.
• DSDT is modified with a new pwm-info (from a real MBP6,2).  We won't know which pwm-info to use until the slider is working and we can determine whether the slider range fully adjusts the display brightness.
• DSDT is modified with the addition of a new thermal zone (Scope (_TZ) { ThermalZone (THM) }) borrowed from the E6430 DSDT here.  This adds a new "Thermal Zone 1" to the HWMonitor temps (nothing to do with display brightness, just playing).
• AppleBacklightInjector.kext generated using @onejay09's technique here.  To make onejay09's patch.sh script work for this patched Catalina 10.15.3 installation, I needed to modify onejay09's script, replacing "AppleDisplay" with "AppleBacklightDisplay".

 

Steps to install this partial solution (still needs brightness keys mapped for slider to work):

• Replace your DSDT in EFI/Clover/ACPI/patched with the attached DSDT
• Remove FakeSMC_LPCSensors.kext (it doesn't appear to add any info in HWMonitor for the Latitude E6410)
• Keep FakeSMC_ACPISensors.kext (it is required to read the new Thermal Zone temp which is now available because of the DSDT mod borrowed from the E6430 DSDT - again, nothing to do with brightness)
• Generate and install your own AppleBacklightInjector.kext using the instructions below.
• Install Rehabman's ACPIPoller.kext for lid sleep (as per my previous post)
• Make sure kexts are properly installed and reboot

 

AppleBacklightInjector.kext

You should generate your own AppleBacklightInjector.kext by following onejay09's instructions here.  Make sure you replace "AppleDisplay" with "AppleBacklightDisplay" in his patch.sh script.  My AppleBacklightInjector.kext is attached as an example.

 

After completing the steps above, press Fn-F12 (brightness up) and Fn-F5 (brightness down) and you will see that the slider "works" but is connected to the wrong keys.

 

Note that when you close the lid, you'll need to wait 30 seconds for the laptop to sleep.  Also note that the laptop wakes properly when the lid is opened.  Looks like this lid sleep/wake solution works perfectly.

 

EDIT: Here a good read about brightness keys: https://www.insanelymac.com/forum/topic/305030-guide-how-to-fix-brightness-hotkeys-in-dsdt/

 

 

ACPIPoller.kext.zip

DSDT.zip

AppleBacklightInjector.kext.zip

Edited February 17, 2020 by tonyx86
No longer need ACPIPoller.kext and Method (LIDP)

[unilock]

@tonyx86

Yes, looks like IntelBacklight.kext was the issue. Wi-Fi and sleep on lid close are both working as intended now, and the brightness slider appears in System Preferences.

Generating my own AppleBacklightInjector.kext, it does appear to differ from yours in Info.plist only -- see the attached comparison via Meld.

 

I got Lilu 1.4.2 from this kext repository, which distributes "nightly" builds of popular kexts.

I don't have AirportBrcmFixup.kext installed because my Wi-Fi card is natively supported by macOS. It works fine without any extra work (though Bluetooth does require BrcmPatchRAM).

[deeveedee]

You indicated that Wi-Fi is working as intended.  Do you mean that the delay is fixed?  If so, what did you change to fix this (from your previous post)?

 

Also, I'll continue to recommend that you stay with the same baseline (including Lilu.kext), since it will help to minimize variables as we're chasing problems.  If you do make a change from the baseline, it would be best to clearly note the change when you post requests for help (explaining why you made the change).

[deeveedee]

My observed lid-sleep times are as follows. These are the times (in seconds) that it takes for my Dell Latitude E6410 to sleep after closing the lid.

• Catalina 10.15.3: 32 seconds
• Mojave 10.14.6: 5 seconds
• High Sierra 10.13.6: 5 seconds

[deeveedee]

If you have been attempting to fix the brightness slider by following my key mapping suggestion, you have probably found that the Dell E6410 brightness up and down keys always invoke the same DSDT method _Q66 (for both brightness up and brightness down), so a simple key mapping is not likely to be the solution.  If you traced beyond _Q66 (using Rehabman's ACPI debugging technique), you traced the brightness key into DSDT methods NEVT and EV8 and WMNF.

 

Long story short ... it's going to take more work to get macOS brightness slider (in System Preferences > Displays) working than I want to spend on this.  I'm content with using the Dell brightness up and down keys.

 

I'll be happy when someone else implements the brightness slider.

[deeveedee]

EDIT: A new lid sleep solution is now attached to Post #1.  This new solution eliminates the need for the ACPIPoller.kext and the Method (LIDP) addition to the DSDT.  This post is still relevant for the darkwake=0 fix.

 

-------------------------------------------------------------------------------

 

A new E6410-Catalina-3v4.zip is attached to Post #1.  This new zip file includes the following changes (all documented in previous posts in this thread with credits where credit is due):

 

• EFI/CLOVER/config.plist
  • Changed boot arg darkwake=8 to darkwake=0
• EFI/CLOVER/ACPI/Patched/DSDT.aml
  • Added elements for Lid-polling / Sleep
• LE
  • Removed FakeSMC_ACPISensors.kext and FakeSMC_LPCSensors.kext (don't add new information to HWMonitor for Latitude E6410).  You will need to keep FakeSMC_ACPISensors.kext if you choose to implement the Thermal DSDT patch that I discussed earlier (copied from Latitude E6430 DSDT).
  • Added ACPIPoller.kext (required for Lid-polling / Sleep)

Edited February 17, 2020 by tonyx86
no longer need ACPIPoller.kext and Method (LIDP) for lid sleep

[deeveedee]

EDIT: In addition to my statement below, it appears that there was more to the Lid Sleep solution than I first thought.  In addition to my Method (BTNV) fix below, it also appears that Device (PNLF) and the addition of pwm-info to the GFX0._DSM may be required as well.  I haven't spent enough time on this to know exactly what is required for working Lid Sleep, but it does appear that multiple changes that I made at the same time have resulted in the working Lid Sleep solution for this Latitude E6410.

 

---------------------------------------------------------------------------------------

 

CORRECTION: Rehabman's Lid Polling solution is not needed to enable lid sleep for the E6410.  A new DSDT is included in E6410-Catalina-3v5.zip attached to Post #1 with details as follows.

 

It bothered me that I needed to add Rehabman's lid polling solution to the Latitude E6410, since lid sleep should happen natively.  After reviewing the DSDT for the Latitude E6430, I found the culprit: A Notify (LID0) event was missing from Method (BTNV) in the E6410 DSDT.  Adding the following to Method (BTNV) in the E6410 DSDT enables sleep on lid closure without needing Rehabman's ACPIPoller.kext / Method (LIDP):

 

                If (LEqual (Arg0, 0x03))
                {
                    Notify (LID0, 0x80)
                }

 

It shouldn't surprise anyone that the Dell Latitude E6410 DSDT is missing this after finding that sleep was fixed by adding the missing ACPI implementation to _PTS and _WAK.  I'm sure we could learn other things by comparing the E6410 DSDT to the E6430 DSDT and invite others to examine them.

Edited February 27, 2020 by tonyx86

[deeveedee]

Earlier this week, I discovered that @Slice has his own thread for the Latitude E6430 here.  Since I derived the E6410 sleep solution from an E6430 DSDT from the thread here, Slice's E6430 thread may offer clues, too.  For example, Slice has his own fork for the VoodooPS2 kext for ALPS trackpad.  For those who want to solve the E6410 brightness slider, I believe that looking at solutions for the E6430 (both E6430 threads) may lead to a brightness slider solution for the E6410.

[deeveedee]

I have Mojave 10.14.6 running perfectly on a Thinkpad T61. Both brightness slider and brightness keys work on the T61, so I compared the IORegistries of the Latitude E6410 and the Thinkpad T61 and tweaked the Latitude E6410 DSDT (updated version attached) with the changes below.  These DSDT changes did not fix the brightness slider on the Latitude E6410, but for those who are trying to fix the brightness slider, the attached DSDT may give you a better chance at succeeding.

 

The changes in the attached DSDT (changes from the DSDT attached to Post #1) are:

• Add "Name (_ADR, Zero)" to Device (PNLF).  I had removed this after seeing Slice's PNLF for his E6430.
• Minor changes/additions to attributes injected in GFX0._DSM

Note that the "@0,built-in" attribute in GFX0._DSM is required in order for the display to be detected as an "AppleBacklightDisplay" (which is required for the display slider to be visible).

DSDT.zip

[deeveedee]

I noticed something that may help us understand why the brightness slider doesn't work on the E6410:  If you examine the connector-type for NVDA,Display-A@0 in IORegistryExplorer (see attached screenshot), the connector type is detected as 0008 0000 which is HDMI according to @Hervé's post here (scroll down to Herve's 2nd post on the page).  If I'm correct about the Latitude E6410, the internal LCD has an eDP connector, so the connector-type should be 0400 0000 (not 0008 0000).

 

It may be that we can't rely on Clover's Inject Nvidia option and may need to manually inject Nvidia attributes in order to correctly define the display.

 

 

Edited February 21, 2020 by tonyx86

[unilock]

@tonyx86

A bit late now, but uninstalling IntelBacklight.kext is what fixed the Wi-Fi delay for me. Around the same time, I discharged my E6410 (held the power button for 30 seconds with the battery unplugged), as you suggest after changing the DSDT, so that may have been the actual solution.

The E6410 does connect to the internal LCD via an eDP interface, although the display itself uses an LVDS port, if that's at all relevant.

Edited February 22, 2020 by unilock

[deeveedee]

@unilock - Glad your laptop is working without the Wi-Fi delay!  Are you using AppleALC or VoodooHDA?

Edited February 22, 2020 by tonyx86

[unilock]

@tonyx86

At the time I wrote my last reply, VoodooHDA. Though, I've just finished updating to 10.15.3, so I think I'm going to try AppleALC before installing VoodooHDA again. I'll let you know how it goes.

EDIT: Still no luck with AppleALC; the Wi-Fi delay remains on 10.15.3.

Edited February 22, 2020 by unilock

[unilock]

After updating to 10.15.3, along with updating the EFI, I'm still unable to use my modular bay drive. As stated before,

1. macOS reports disk I/O errors during verbose boot
2. Finder claims it's unable to recognize the disk and asks to initialize it
3. Disk Utility fails to erase the disk (see attached screenshot)
4. After a while with the drive plugged in, the screen goes white. Sometimes the laptop will automatically reboot from here; other times I'll need to manually force it to power off and on again

I've generated several debug reports of this issue, and linked to them in this post.

What I find bizarre about this issue is that it doesn't occur in literally any other circumstance:

• Connecting the bay drive to my desktop (through a frankly horrifying configuration), which is also a hackintosh, works fine
• Accessing the bay drive within another OS works fine (e.g. Linux)
• Even Clover properly recognizes the partitions on the disk in the drive
• The stock DVD bay drive works fine in macOS

I've tried multiple HDDs in the drive; the problem is the same amongst all of them.

@tonyx86 - you say you have a modular bay drive that works with macOS? I wonder if there's an internal difference between our drives. If you wouldn't mind, could you take photos of the internals of your drive? I've attached some of my own to this post.

[deeveedee]

@unilock I originally thought SATA 3 vs SATA 2 might be an issue, but my adapter also indicates SATA 3 like yours.  Pix are attached.

 

Also, there's a switch on the side that I've never played with.  I see your board has one, too.  Does the switch position matter?  I don't know what it does.

Edited February 24, 2020 by tonyx86

[deeveedee]

There is a new VoodooHDA package V15 with fixes specifically for Catalina.  https://github.com/chris1111/VoodooHDA-2.9.2-Clover-V15/releases/tag/V15

 

I am using Chris1111's VoodooHDA installers and selecting "Classic Mode" for installation.

[unilock]

@tonyx86

From the casing, it looks like we have the same model of modular bay drive. Though, based off what it says on the circuit board, you seem to have a slightly newer revision than I do. But I can't see any visual differences, other than that yours has a disk activity indicator LED soldered on while mine does not. If you want to disassemble the drive further, there are screws under the stickers on the side where you would insert the HDD (one on the white/black transition line under the cylinder in the top-left corner, one on the text under the book with the "i" in it in the bottom-left corner, and one on the left side of the cylinder in the bottom-right corner).

The switch enables/disables the diags pin, whatever that means. The ON state is towards the laptop-size SATA connector; the OFF state is towards the full-size SATA connector. The state of the switch doesn't seem to have any effect my problem.

I don't think a difference in SATA speed (SATA2 vs. SATA3) is part of the issue, as I believe the bay drive acts only as a passthrough between SATA port standards.

[deeveedee]

@unilock I'm not sure that further disassembly of my aux bay adapter is going to reveal anything helpful.  I was comparing my IORegistry  to the one you last posted and quickly realized that your last debug files do not reflect your current installation.  Could you please post a new set of debug files (generated with black.dragon74's gen_debug tool) for your 10.15.3 installation with the aux bay populated with your data drive (one set of debug files)?  Please make sure that you're running the same file versions as those posted in Post #1 (including the same FakeSMC) as file differences generate different IORegistry attributes that complicate the comparison for me.

 

This will make the comparison easier for me.  Also, I imagine you have at least one BIOS config that is different from the config I specified in Post #1 (e.g. enabling your cellular modem).  Can you provide a list of the differences between your BIOS config and the BIOS config that I have recommended in Post #1?

 

Short of the detailed comparisons of the configs which I'm willing to do after seeing your updated post, I'm not sure what else to consider except for a new aux bay adapter.

 

EDIT: One other thing... When I was examining your last-posted IORegistry dump (I still need an updated set of debug files as explained earlier in this post), I noticed that your IORegistry (as viewed with IORegistryExplorer) has at least one device that I don't (e.g. RP04@1C,3).  It's possible that the presence of other hardware in your laptop (like the cellular modem) requires additional ports to be active, so your BIOS config is different and thus you need a slightly different DSDT.  You may need to try:

 

1. My DSDT attached to Post #1 in this thread emulates Linux for running macOS.  Attached is a DSDT that emulates Win7 instead of Linux (see more details about this in the Mojave thread).  Try this DSDT to see if this helps.
2. *** Deleted - no longer believe that you need to extract / patch your own DSDT.

DSDT.zip

Edited February 26, 2020 by tonyx86
deleted DSDT extract / patch suggestion

[deeveedee]

@unilock I just did a quick compare of your unpatched ACPI to mine and don't see any relevant differences, so I don't think you need to create your own patched DSDT.  I hope I posted this before sending you on a wild goose chase.  I'm stumped.  While it's strange that your aux drive caddy works with other OSes and not macOS, the only thing I can think is to get another caddy.

[deeveedee]

@unilock After I posted my comment below, I realized that the additional SATA ports may be a port expander / docking station or that you have enabled eSATA ports in BIOS.  Are you performing your testing with your laptop in a docking station or with eSATA enabled?  If so, this would be a big difference between your configuration and mine.  I never examined the DSDT (let alone tested) with a docking station or with eSATA enabled.  If that's the case, try testing "undocked" and/or with eSATA disabled in BIOS to see if that affects operation of your aux bay drive.

 

-------------------------------------------------------------------------

 

 

@unilock I finished reviewing your posted files to see if there's anything I can learn from your previously posted configurations.  I'm not sure if those configurations accurately represent your current state, but if they do, this might offer a clue about your SATA problem.  There's one IORegistry difference that leads me to believe we have different BIOS settings, so I'd encourage you to review the BIOS settings I listed in Post #1 and compare to yours.

 

If you look at the two IORegistry screenshots attached to this post, the screenshot of my IOReg lists only two SATA PRT "ports": PRT0 (my primary SSD) and PRT1 (my aux bay SSD).  Your IOReg lists two additional SATA "ports" that I don't have listed on my laptop: PRT4 and PRT5.

 

It's possible that if you can determine the difference between your SATA configuration and mine, this might provide a clue for you.

 

Edited February 27, 2020 by tonyx86
Added comment about docking station

[unilock]

@tonyx86

Apologies for the late response.

I tested your DSDT that emulates Win7 instead of Linux, but no change in bay drive behavior.

I've been testing the laptop undocked. While I believe my BIOS settings are identical to yours, this may not be the case. I'll disable eSATA in BIOS if it is indeed enabled, then upload a new debug report.

 

EDIT:

Looks like disabling the eSATA ports in BIOS did get rid of the extra SATA entries. Unfortunately, it didn't solve the bay drive issue. Attached is the output of black.dragon74's tool.

If you need me to list the changes I've made from the "baseline" specified in post #1, I'd be glad to do so later, but I have a killer headache right now.
Thanks for taking the time to look at this.

debug_2020-02-27.zip

Edited February 28, 2020 by unilock
add debug files

[deeveedee]

@unilock I see the obvious differences between our configs (listed below) of which you are already aware.  I'm not sure how these would affect the aux drive bay (probably they don't), but I have no other guesses.  If you have already tried the baseline that I've posted and it produces the same result, I have no other guesses.

• Different version of FakeSMC
• Different version of Lilu.kext
• Kexts in E/C/k/O instead of /L/E

Just to clarify the way I'm using the aux drive,

• I do NOT have an EFI installed on the aux bay drive
• Aux bay drive is MBR formatted
• Windows 10 is installed on aux bay drive in Legacy mode
• I installed Windows 10 on the aux bay drive WITHOUT any other drives installed in the laptop (to be sure that the Windows 10 installer did not modify my macOS drive in any way)
• I installed Windows 10 on a 100GB partition of the aux bay drive, initially leaving the remainder of the 256GB aux bay drive unformatted
• On the remaining unformatted portion of the aux bay drive, I created an HFS+ partition on the aux bay drive using "Paragon HardDisk Manager Basic" running IN WINDOWS 10
• I added the aux bay partitions to Spotlight Privacy tab in macOS so that macOS does not try to index the aux bay drive
• To boot Windows 10 from the aux bay drive, I press F12 at boot and select the aux bay drive

Edited February 28, 2020 by tonyx86