Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by deeveedee

  1. @bartl I'd love to have your help with resolving sleep. My Mojave thread is here: https://www.insanelymac.com/forum/topic/339102-mojave-on-dell-latitude-e6410/ I haven't had time to work on it lately and hope to get back soon.
  2. @black.dragon74 Thank you for your black screen fix guide - your guides are always so clear and well written. And I've always meant to thank you for your problem reporting tool - outstanding! I believe that I have followed your EDID injection procedure (using CLOVER (Legacy) R4961) and am finding that CLOVER always injects its own EDID regardless of my config.plist. I have also tried injecting EDID via DSDT with EDID Inject = FALSE in CLOVER, but CLOVER still appears to inject its own EDID. My problem reporting files are attached. My configuration includes both EDID Inject = TRUE in config.plist and EDID defined in DSDT so that you can see what's happening in both cases. The actual scenarios that I have tested are listed below. Note that I have tried injecting EDID with and without "Inject Nvidia" = TRUE in config.plist, but EDID injection still doesn't work for me. I am currently Injecting my Nvidia attributes via DSDT, so Inject "Nvidia" = FALSE in config.plist. My system is as follows: CLOVER (Legacy): R4961 MacOS: High Sierra 10.13.6 Dell Latitude E6410 (I7-620m, Nvidia GeForce 3100m, 8GB DDR3) Scenarios and Results: No EDID injected via CLOVER nor via DSDT: IORegistryExplorer reveals an "edid" for GFX0 > NVDA,Display-A@0 (see attached screenshot: default-edid) EDID injected via CLOVER (Legacy, R4961) with no EDID defined in DSDT: wrong "edid" shown in IORegistryExplorer (see attached screenshot: default-edid) "EDID" (all upper case) injected via DSDT with Inject EDID = FALSE in CLOVER config.plist: two EDIDs are visible in IORegistryExplorer for GFX0 > NVDA,Display-A@0 (see attached screenshot: two-edids) "edid" (all lower case) injected via DSDT with Inject EDID = FALSE in CLOVER config.plist: wrong edid visible in IORegistryExplorer (see attached screenshot: default-edid) I'm sure this is something I'm doing wrong. Thank you very much for your help. debug_19623.zip
  3. deeveedee


    @dragasoni You're going to be very pleased with High Sierra on the E6410. It runs GREAT! If you get sleep working, let us know I'm currently running Mojave 10.14.5 and am very pleased. Like Herve said, start with High Sierra. I found this thread to be very helpful: https://www.insanelymac.com/forum/topic/308765-guide-dell-latitude-e6410-nvidia-el-capitan-clover-eng/. The same basic principles apply for High Sierra. Keep reading in that thread until the end and you'll see where I pick up with installing Mojave. Good luck and be patient (unlike me).
  4. I'm extremely new to the "Refined ALPS Touchpad" driver and just recently installed Version 5 on my Latitude E6410. I haven't tested all the keys (especially Fn combinations), but I was able to fix the obvious issues by changing the keyboard type from ANSI to ISO European (System Preferences > Keyboard > Keyboard Type) and switching the Command and Option keys (System Preferences > Keyboard > Modifier Keys).
  5. Good to know. I can relate to keeping one's opinions to one's self. Will do. Thanks.
  6. @Hervé, I know this is an old thread, but it's a good one. Earlier in this thread, you suggested experimenting with control-id 17 and 18 for AGPM on a MacBookPro 6,1 or 6,2. I'm new to this, so forgive what is probably a dumb question. The MacBookPro6_2.plist in /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/Plugins/ACPI_SMC_PlatformPlugin.kext/Contents/Resources does not contain a GPU_RANGE_CONTROL_EXTERNAL entry for control-id 18. In your opinion, wouldn't the only valid control-ids be those present in the ACPI_SMC_PlatformPlugin.kext/Contents/Resources/*.plist for the associated platform, and if so, wouldn't 18 be an invalid control-id for MacBookPro6,2 (with the only valid options being 16 and 17)? Or are the valid control-id values defined by ControlIDArray, in which case, 16, 17 and 18 are valid control-ids?
  7. @itsworkingI know this is an old thread, but I'm thinking of using your DSDT debugging technique to resolve the sleep issue on my Latitude E6410 running Mojave10.14.5. The only thing not working on my Latitude E6410 / Mojave is sleep - everything else is perfect as far as I can tell. When you observed that you "never see _PTS," did you try your test with and without the AC adapter connected? I have made some progress on my Latitude E6410 DSDT mods to fix sleep and found that the behavior is different when the AC adapter is connected and when the laptop is running on battery. With my DSDT mods, my laptop "shuts down" when it sleeps and is on battery power (which is closer to sleep than freezing with the power light on).
  8. After switching the Command and Option keys on my Latitude E6410, I had only one key that was misbehaving: the [ ` ~ ] key to the left of the "1" (one) key. Changing my keyboard to ISO European (from ANSI) fixed this. Now it appears that all of the keys on my Latitude E6410 are working correctly with Refined VoodooPS2Controller R5. I have to say that I'm finding the ALPS Touchpad performance on my Latitude E6410 to be absolutely fantastic while running both High Sierra and Mojave. GREAT JOB to all who contributed to this. With the modifier key switch and the keyboard type change to ISO European, this solution seems perfect. Thank you!
  9. @Jake Lo and @Hervé - I have been able to modify my DSDT to get close to a working sleep solution for the Latitude E6410. It looks like I was on a wild goose chase with the _OFF and _ON methods. I now believe that the solution will combine a change to _PTS and a change in _EJD (Ejected Device notification). Search for _PTS and _EJD in my attached DSDT.aml and you will see what I mean. With these changes in the attached DSDT.aml, the USB device at EHC1.PRT1 generates the Ejection Device notification (not the device at EHC2.PRT3 which doesn't exist). The original DSDT has the _EJD notification in EHC2.PRT3 which doesn't have a device present and thus doesn't trigger an _EJD notification. With this change, the laptop shuts down on sleep. I feel that this is very close and I could use your expert opinion and advice. I suspect that SLPE should only be set to zero in _PTS for shutdown and that something else should be done for sleep. If I move Store (Zero, SLPE) back into the if condition (so that SLPE is only set to Zero on shutdown), the laptop does not shutdown (or sleep) when I attempt to put it to sleep, so something similar to Store (Zero, SLPE) is still required for sleep. Hopefully this makes sense. Please ask questions if it doesn't. Thank you for your help and expertise. DSDT.zip
  10. I switched to this "Refined VoodooPS2Controller" from the "original." With the original kext, I was using SSDT-DisableTrackpadProbe.aml to disable search for the unused Synaptics and Sentelic devices. Does this "Refined" version also benefit from the SSDT-DisableTrackpadProbe.aml? EDIT: My Refined VoodooPS2Controller configuration on my E6410 is as follows: Kext release 5 VoodooPS2Controller.kext installed in CLOVER/kexts/other and /L/E with CLOVER > Inject Kexts > Detect CLOVER boot flag vps2_findmousedelay=500 (left over from original kext) SSDT-DisableTrackpadProbe.aml in CLOVER > ACPI > patched with only ALPS Glidepoint enabled (left over from original kext) Command and Option keys switched (System Preferences > Keyboard > Modifier Keys) (to compensate for key switch caused by the new kext)
  11. Using this VoodooPS2Controller.kext on my Latitude E6410 dual-booting High Sierra and Mojave. Outstanding!
  12. I traced the _PTS shutdown fix back to the beginning of Hackintosh time. I should have noticed that the same fix appears on my Thinkpad T61 (also running Mojave). The fix was only ever intended to be for shutdown (to be conditional on LEqual (Arg0, 0x05)). SLPE appears to be a register that controls NVidia dGPU and can be in one of two places on older laptops: On the Latitude E6410 (NVS 3100m): OperationRegion (PMRS, SystemIO, 0x0430, One) Field (PMRS, ByteAcc, NoLock, Preserve) { , 4, SLPE, 1 } On the Thinkpad T61 (NVS 140m) OperationRegion (PMRS, SystemIO, 0x1030, One) Field (PMRS, ByteAcc, NoLock, Preserve) { , 4, SLPE, 1 }
  13. @Hervé Thanks for your patience with me. My digging indicates that you are clearly one of the experts in this area. Do you know how the E6410 _PTS shutdown patch was discovered and do you know where I might look to learn more about it? Also, in this thread you don't reference the _PRW 0x0D patch. Do you stil believe that the _PRW 0x0D patch is necessary (I've implemented it, but not sure I did it correctly given that _PRW generates its returns with Method (GPRW). Thanks for any help / advice / insight.
  14. @Jake Lo Thanks for your help, but I'm reluctant to try your suggestion, because the _OFF and _ON methods work with registers/memory locations that are very different from the Latitude E6410 / 3100m. I did some digging and believe that @v3ct0r 's Yosemite thread was the first to implement the _PTS shutdown patch. If I can understand how this shutdown patch was determined, it would help. EDIT: @Hervé also provided this _PTS shutdown patch in this thread.
  15. @Jake Lo - Thank you for your reply. I will look at your solution before applying, since I can already see I need to make one change (PEG0 -> AGP in my DSDT). It will also help me to refine my AGP.VID._DSM. While I'm digesting your solution, do you know how duduclx came up with his _PTS shutdown fix? He identified a register (SLPE) which he defined as: OperationRegion (PMRS, SystemIO, 0x0430, One) Field (PMRS, ByteAcc, NoLock, Preserve) { , 4, SLPE, 1 } and then he set SLPE to Zero in _PTS Store (Zero, SLPE) I'm guessing that he found this in an SSDT from another system? It would help me to know how he discovered this, since I'd like to understand the solution in addition to implement it. Thank you.
  16. @Jake Lo - You suggested duduclx's _PTS patch for working sleep. It turns out that with a minor modification, his patch almost addresses shutdown and sleep. If I remove the conditional in _PTS (as shown below), the E6410 sleeps and then wakes immediately with a black screen. I suspect that duduclx's _PTS logic requires some minor modification and that the "inverse" logic is required in _WAK. Method (_PTS, 1, NotSerialized) { Store (Zero, SLPE) Sleep (0x10) }
  17. @Jake Lo This thread suggests that adding _OFF and _ON method calls was the trick to working sleep for another Dell Latitude. I couldn't find _OFF and _ON methods in DSDT or any SSDTs (nor could I find any analogous methods, but I don't know what I'm looking for). I'd be open to trying the _OFF / _ON trick if anyone can suggest how to find or create these methods.
  18. @Jake Lo If I should start a new thread for this, let me know. My system files are attached. Note some differences from other E6410 configs that you may have seen: LPCB._DSM patched with device-id "3b09" for native Nehalem power management with MacBookPro 6,2 ECDV renamed to EC so that AppleBusPowerController loads AGP.VID._DSM patched with device-id "0a29" so that AppleGraphicsPowerManagement loads No CLOVER option to Generate P or Generate C States (With the correct LPCB._DSM and MacBookPro 6,2, these CLOVER are NOT necessary for this architecture and only result in reduced number of P states and lower max multiplier). Note that sleep still doesn't work if Generate C and Generate P states is enabled in config.plist. EDIT: Added HDAU device to PCI0.AGP (device-id 0x0be3) which is not currently reflected in the attached debug files. Note that my DSDT patches include Rehabman's _PRW 0x0D patch suggested by @Hervé and duduclx's _PTS shutdown patch. Shutdown works great, but sleep does not. When attempting to sleep, screen goes black and system enters a frozen (still on) state that can only be recovered by forcing power-off with the power button. Also note that I started patching AGP.VID._DSM for backlight slider. The slider appears in Display Settings, but moving the slider doesn't change brightness. Will look at this again when I have time. debug_7519.zip
  19. @Jake Lo Thank you for the reply! duduclx's prepare-to-sleep patch resolves the shutdown problem (can't use CLOVER's on-the-fly shutdown patch), but it doesn't resolve sleep. I'd love to know how he figured out that patch. In that same thread on page 9, duduclx indicated that @Hervé recommended Rehabman's _PRW 0x0D patch, but I have not found that that changes my laptop behavior in any way (including sleep). Since the fix is intended to fix the instant wake problem, it just might work (if I can get my laptop to sleep ). I really appreciate your help / suggestions. Thank you! EDIT: I'm dual-booting the E6410 with High Sierra and Mojave. Sleep behavior is identical in both. Other than sleep, performance on this laptop is outstanding. Since my Mojave solution is based on DosDude's Mojave patcher (a solution I've found to be surprisingly controversial even though it works great), I'm doing all my testing in High Sierra.
  20. I know this is an old thread, but I'm trying to solve the same sleep problem on my Latitude E6410. Attempts to sleep result in black screen, but system is still on and can't wake back up. Must force shutdown by holding power button. My E6410 thread is here: https://www.insanelymac.com/forum/topic/339102-mojave-on-dell-latitude-e6410/
  21. I'm using DosDude's Mojave Patcher on 4 systems with Nvidia (non-metal) graphics and video is working perfectly on all with Mojave 10.14.5: Dell Latitude E6410 (Nvidia NVS 3100M), Thinkpad T61 (Nvidia NVS 140m), DIY Desktop Socket 1156 / (GeForce 9800GT), DIY Desktop Socket 775/771 (GeForce 8600GT). DosDude's patcher (currently using version 1.3.3) has extended the life of these old system. All running Xcode 10.2 and graphics acceleration works perfectly.
  22. For anyone installing Mojave on a system with previous generation Intel HD Graphics, this might give you some hope... I am installing Mojave on an old Biostar TH55HD (Socket 1156) with Intel I5-660 CPU (Clarkedale) and 8GB DDR3. I created a Mojave Installer USB and installed CLOVER Bootloader (Legacy) R4769. I extracted the DSDT (CLOVER F4) and performed minor edits to resolve compile errors. I then applied some very basic DSDT patches and saved the DSDT in the USB EFI/CLOVER/ACPI/patched folder. Without any kexts or CLOVER flags, Mojave recognized the I5-660 HD Graphics. My display resolution is 1280x1024. I plan to install a Radeon Graphics Card, but to get started, I am using the Intel HD Graphics on the I5-660.
  • Create New...