[Guide] Dell Latitude E6410 (Nvidia) Hackintosh: Big Sur, Monterey, Ventura, Sonoma, Sequoia & Tahoe installations with Open Core Legacy Patching

[deeveedee]

OCLP Devs have committed to providing Tahoe post-install patches for legacy metal graphics (e.g., Nvidia Kepler); however, OCLP non-metal patches are questionable, because the Tahoe graphics performance would be so bad.  See OCLP Dev post here.   Even if the OCLP Devs do implement Nvidia non-metal Tahoe post-install patches, we should set our performance expectations accordingly.  I doubt that anyone will be surprised that this 2010 laptop has reached the end of its useful life.  It really is amazing that it has continued to run macOS for this long.

 

I continue to treat this laptop as a hobby and I enjoy tinkering with it, but it is long past its utility as a "production" laptop.

 

EDIT: I'm still optimistic about non-metal Nvidia Tesla patches for this old hack.  See this.

Edited December 3, 2025 by deeveedee

[deeveedee]

Thebes Knossos, thank you for this tip: Apple has published a new update to Big Sur that extends the life of this old OS.  Update Big Sur to version 11.7.11 for new certificates that allow continued operation of FaceTime, iMessage and other services.

 

Long live Big Sur

 

 

Note that Big Sur is the most responsive and the macOS version that runs most "natively" of the macOS versions documented in this thread.

Edited February 6 by deeveedee

[verdazil]

5 hours ago, deeveedee said:

Long live Big Sur

We will hope that macOS Tahoe will receive such support in 2031!

[deeveedee]

Easy update to Sequoia 15.7.4 and Safari 26.3.  The only problem that I found is that Shift-Command-4 no longer takes screenshots.  I tried with the internal PS2 keyboard and an external USB keyboard - the problem exists on both, so this isn't a PS2 issue.  Other than that, Sequoia 15.7.4 runs very well on this very old hack.

 

EDIT: Note that Shift-Command-4 was working in Sequoia 15.7.3 as evidenced by this screenshot:

 

EDIT2: I have confirmed that the Shift-Command-4 screenshot problem doesn't happen until OCLP post-install patches are applied for NVidia Tesla (using OCLP 2.4.1 or 2.5.0n).  If I revert post-install patches, screenshot works.

 

Edited February 13 by deeveedee

[johnnyl]

Isn't it Shift-Command-3 for screenshots ? Well that's what I use.

[LockDown]

3 = Entire screen

4 = Selected portion of the screen

[deeveedee]

None of the Shift-Command screenshot key sequences work in Sequoia 15.7.4 on this old hack.  I use Shift-Command-4 as explained by LockDown for capturing partial screen shots.  Note that I don't have this problem on any of my newer hacks, so I suspect that this is a problem specific to non-metal (maybe specific to non-metal NVidia Tesla).

 

EDIT: I updated this old hack to macOS Tahoe 26.3 (25D125).  Still hoping that non-metal Tesla patches are released by the OCLP Devs.

 

EDIT2: I have confirmed that the Sequoia 15.7.4 screenshot problem doesn't happen until I apply OCLP post-install patches (using OCLP 2.4.1 or 2.5.0n).  Without post-install patches, screenshot still works.  

 

This Sequoia 15.7.4 screenshot issue may resolve itself when a newer KDK is available from Apple.

Edited February 13 by deeveedee

[deeveedee]

EduCovas has announced here that he will no longer be contributing to OCLP patches.  Say your prayers for Edu's full and speedy recovery.

 

Since Edu was one of the primary developers of the current non-metal patches (and other OCLP graphics patches), it is likely that further non-metal NVidia graphics patches for this old hack will be significantly delayed - maybe permanently.

[AlfredoM]

I didn't expect anything different from Nvidia cards.

It's not a big deal; macOS Sequoia 15.7.4 runs flawlessly on my 27-inch 2013 iMac.

[deeveedee]

The OCLP Devs already have Nvidia metal patching working in their own test environments, so I think it is reasonable to still expect OCLP Tahoe patching for metal-capable Nvidia cards.  it is the non-metal (like the one in this thread) that are at risk.

[deeveedee]

OCLP Devs have created a new version of RestrictEvents.kext (version 1.1.7) that applies the javascript patch for non-AVX platforms.  This new kext is not yet available as an Acidanthera release and is currently available only in the OCLP Payloads.

[deeveedee]

Tahoe 26.4 RC... No root patches, just keepin' the dream alive

 

[deeveedee]

Updated my HackBookPro6,2 (Intel Arrandale CPU, non-metal Nvidia Tesla) to Sequoia 15.7.5 (24G624) and applied post-install patches (Modern Wi-Fi, Nvidia Tesla Graphics) with OCLP 2.5.0n (commit b9df76e). 

Spoiler

 

All appears to be working except <Shift> <Command> screenshots. These screenshots still work until I apply the post-install patches. I suspect this is because Apple still has not published an updated KDK for Sequoia



I'm still amazed that this old laptop can run Sequoia and receive updates from Apple. Posting this with Safari Version 26.4 (20624.1.16.18.1). Continuing to keep this hack alive as a hobby and not much else. Sequoia is surprisingly responsive on this 2010 laptop.

 

Edited April 11 by deeveedee

[jackacc]

On 12/13/2022 at 3:26 AM, deeveedee said:

The ssdtPRGen exercise was informative, but after running my hack with a CPU SSDT-PM, I have found that performance and responsiveness is worse with the SSDT-PM than without.  I have removed the SSDT-PM from my ACPI patches.  Also, I revisited NVCAP generation with NVCAP Calculator and have assigned the two DVI (DP) ports to Head 2 with the Analog (VGA) port.  I am using the new NVCAP value (no noticeable difference since I'm not using and haven't retested the DP port) with the NVCAP Calculator values as follows:
ssdtPRGen 练习提供了丰富的信息，但在使用 CPU SSDT-PM 运行我的 hack 后，我发现使用 SSDT-PM 的性能和响应能力比不使用 SSDT-PM 时更差。 我已从 ACPI 补丁中删除了 SSDT-PM。 此外，我使用 NVCAP 计算器重新审视了 NVCAP 生成，并将两个 DVI (DP) 端口分配给具有模拟 (VGA) 端口的 Head 2。 我正在使用新的 NVCAP 值（没有明显差异，因为我没有使用也没有重新测试 DP 端口）和 NVCAP 计算器值，如下所示：

 

NVCAP Calculator - revised values
NVCAP 计算器 - 修订值

  Hide contents 隐藏内容

 

I have a notebook ASUS K40ID.t6670 gt320m ,Unable to extract vbios using GPU-Z and AIDA64，Cannot use NVCAP generation without vbios.

 

[jackacc]

On 12/15/2022 at 10:04 PM, deeveedee said:

Setting pci10de,be3.class-code = <FF FF FF FF> causes AppleHDA to ignore the device, thus eliminating the boot delay.  Leaving the post below for historical purposes.  At the time of this writing, I am overwriting class-code with SSDT-HDAU.

 

=====================================

 

I'm still trying to figure out why naming pci10de,be3 -> HDAU causes significant boot delays (because AppleHDA detects HDAU).  As I investigate this, I found something that is confusing me:  HDEF and pci10de,be3 audio are forced to have property hda-gfx="onboard-1" no matter what I do to patch ACPI.  I would think that HDEF would have property hda-gfx="onboard-1" and pci10de,be3 would have hda-gfx="onboard-2" but any attempt that I make with ACPI patching to set hda-gfx="onboard-2" results in hda-gfx="onboard-1" in IOReg.  Note that if I attempt to set HDEF's hda-gfx="onboard-2," something is forcing it to hda-gfx="onboard-1"

 

Can anyone confirm that the two audio devices should have different hda-gfx values ("onboard-1" and "onboard-2") and if so, what could be forcing both audio devices to have the same hda-gfx="onboard-1" value?  Could it be because I don't have Intel iGPU and only have a single enabled graphics device?

 

For the attached screen shots, I am injecting WhateverGreen.kext (which my Nvidia patching makes unnecessary and WhateverGreen.kext only renames AGP.VID to AGP.GFX0 and it makes no difference regarding the value of hda-gfx) and I am naming pci10de,be3 to HDMI (a cosmetic renaming via SSDT that attempts to set hda-gfx="onboard-2").  My SSDT-HDMI is attached.

 

GFX0 IOReg (hda-gfx = "onboard-1")

  Hide contents

 

HDEF IOReg (hda-gfx = "onboard-1")

  Hide contents

 

HDMI (pci10de,be3) IOReg (hda-gfx = "onboard-1")

  Hide contents

 

SSDT-HDMI (cosmetic naming of pci10de,be3 -> HDAU, unsuccessfully attempts to set hda-gfx="onboard-2")

SSDT-HDMI.aml.zip 696 B · 10 downloads

 

EDIT: My original OC EFI for this hack includes SSDT-IGPU which sets IGPU._STA=0.  This is unnecessary, since the iGPU is already disabled (only Nvidia dGPU is enabled).  I have removed SSDT-IGPU from my current EFI since it doesn't do anything.  As expected, there is no change in IOReg (including no change in hda-gfx values) and no change in system behavior.

 

EDIT2: If I drop my SSDT-HDEF (allowing AppleALC to perform exclusive patching of HDEF), AppleALC does not assign a value of hda-gfx to HDEF IOReg.

  Reveal hidden contents

 

Upon reading this, the idea was to boot into the desktop from clover<key>NVidia</key><true/> by using the IOReg tool to inject the graphics card parameters into OC, and it succeeded.

All the graphics card properties in Clover have been transferred to OC, possibly including some unnecessary ones. If any expert could remove the redundant entries and list the retained items, that would be great.

[deeveedee]

@jackacc This thread is for the Dell Latitude E6410.  Please start a new thread for your laptop so that this thread is not cluttered with posts not related to the primary subject.  After you create your own thread, please ask your questions in that thread.  The result will be a thread that solves problems for the ASUS K40ID.t6670 in the same way that this thread solves problems for the Dell Latitude E6410.

 

Thank you.

[jackacc]

19 hours ago, deeveedee said:

@jackacc This thread is for the Dell Latitude E6410.  Please start a new thread for your laptop so that this thread is not cluttered with posts not related to the primary subject.  After you create your own thread, please ask your questions in that thread.  The result will be a thread that solves problems for the ASUS K40ID.t6670 in the same way that this thread solves problems for the Dell Latitude E6410.

 

Thank you.

 

On 11/4/2022 at 2:39 AM, MacNB said:

 

@deeveedee Thank you but I don't have the problem. I was just helping others to show how to Inject Nvidia GPU settings with OC. 
 

Your thread (great BTW), uses SSDT and I do the same too but can you just use OC to inject Device Properties just as effectively and it's all contained within one file...the config.plist just like this:
 

 

Both methods have their uses.
 

Thank you but I don't have the problem. I was just helping others to show how to Inject Nvidia GPU settings with OC. 

[deeveedee]

@jackacc I'm sorry I misunderstood.  Thank you for offering the suggestion.

[deeveedee]

The new RestrictEvents.kext 1.1.7 (which includes the revpatch=jsc option to patch javascript for non-AVX Macs/Hacks) is in a separate branch that is not yet merged with the main RestrictEvents branch at the time of this post.  Thank you to @Pri-est over at MacRumors for pointing me in the right direction.

[deeveedee]

I manually installed KDK 15.7.4 in Sequoia 15.7.4 on my HackBookPro6,2. <Shift> <Command> screen captures are working again. The problem was the missing KDK and not OCLP. For some reason, the Dortania KDK mirror did not pull KDK 15.7.4 from Apple.

I rebooted and <Shift><Command> screenshots are not working again.  Not sure what happened, but the KDK isn't the whole story.

 

Edited April 11 by deeveedee

[deeveedee]

Very smooth upgrade to Sequoia 15.7.6 RC with one small hurdle...  After upgrading to Sequoia 15.7.6 RC, OCLP 2.5.0n did not detect the need for Nvidia Tesla root patches (only detected the need for Modern Wireless).  After reverting root patches and rebooting, OCLP 2.5.0n detected the need for both Modern Wireless and Nvidia Tesla root patches.  The root patches installed with KDK 15.7.4 (which I manually installed).  All that I tested appears to be working well with the exception of <Shift><Command> screen shots (as was the case with 15.7.5).

 

KDK 15.7.4

Spoiler

 

 

Sequoia 15.7.6 RC is very responsive on this old hack.  Amazing.  I'm still not using this for anything more than a hobby and bragging rights and am very pleased to be running macOS Sequoia on this 2010 laptop.

 

EDIT: KDK 15.7.4 is now included in the Dortania KDK mirror for OCLP.

Edited April 23 by deeveedee

[deeveedee]

I manually modified my OC EFI to include the new RestrictEvents.kext 1.1.7 (javascriptcore branch) and revpatch=jsc. macOS Sequoia 15.7.6 still boots 🙂. I don't test many websites with OCLP, but MacRumors and InsanelyMac are working just fine in Sequoia 15.7.6 with Safari Version 26.4 (20624.1.16.18.1).  I've also upgraded my EFI with OC 1.0.7 and the latest Acidanthera kexts.  If Tahoe is ever officially supported by OCLP on this hack, I'll upload my latest EFI to this thread.

Edited April 14 by deeveedee

[deeveedee]

Smooth upgrade to Sequoia 15.7.7 Beta (24G716). Posting this with Safari Version 26.5 (20624.2.4.18.2). This old laptop is running Sequoia amazingly well.

 

My OCLP patching specs are as follows:

• Booting with Open Core 1.0.7
• Updated RestrictEvents.kext to javascriptcore branch version 1.1.7 (revpatch=jsc)
• Applied root patches for Nvidia Tesla graphics and modern Broadcom Wi-Fi with OCLP 2.5.0n. OCLP used KDK 15.7.4
  Spoiler

  

   

The native macOS Sequoia screenshot app is still not working, so I'm using a 3rd-part app from the AppStore.

 

[deeveedee]

This is kind of amazing (to me)... I am posting this in Firefox 151.0 on my HackBookPro6,2 running macOS Tahoe 26.5. Booting with Open Core 1.0.7. No OCLP root patches, no Wi-Fi, no audio. Surprisingly responsive! I wouldn't use this for anything other than creating this post 😂

 

 

EDIT: I am editing this post in Safari 26.5.

Spoiler

 

Note that my Open Core EFI has dhinakg's RestrictEvents.kext 1.1.7 (javascript core branch) with revpatch=jsc.

Edited May 20 by deeveedee

[deeveedee]

OCLP Devs have provided an update.  See here.