Hervé

You will only be able to download Sierra off AppStore now and you may refer to my E6230 guide for installation. The process is exactly the same as for El Capitan.

Well, distros have always been trouble, so who knows...

Assuming you indeed have the HiRes LCD, are you sure you've used the pack for the D630 X3100 HiRes (LCD res=1440x900) not the LoRes (LCD res=1280x800)?

Well, yes you were initially missing something (you were copying kext to SLE but repairing permissions of LE!) but it appears you're doing it the correct way in your screenshot. I use this VoodooPS2Controller kexts throughout on all my Latitude E Series under Mavericks & Yosemite and up to El Capitan 10.12.3. VoodooPS2Controller.kext.zip

Great, speed is much better; totally useable for me. Your PS2 controller v4.0.0 is now spot on and perfect for all my Latitude E Series. Thanks again.

The VoodooPS2Controller v1.8.9 (~328Ko) from my E6220/E6440 Yosemite/Mavericks guides works also on the E6230 under Yosemite. Well, it does for me... Do not use the version modified for El Capitan. And check that you do not have a rogue kext in /L/E or elsewhere.

Make sure you do not have multiple PS2 controller kexts installed. Stick to the manual method, you can see that the tool does not report on errors...

@dlonewolf86 1) Your DSDT injects the wrong iGPU id 0416 (mobile HD4600); it must be 0412 (desktop HD4600) 2) Your DSDT injects Azul FB 0x0a260006 so you do not need to add it to Clover config plist 3) Your Clover config plist injects PCIRootUID 1; I'm pretty sure that's wrong and I would recommend you get rid of it 4) Your Clover config plist does not inject Intel for Graphics; I think it should 5) Your Clover config plist has a binary patch for IntelHD5000 kext (commented "full QE/CI for HD4400"); is that necessary? What does it do? 6) same for the Azul FrameBuffer kext so same quesion; I would remove those patches 7) Your Clover config plist has Asus AICPUPM patch enabled; it's not required on a Haswell platform; you only need KernelPm patch 8) Your Clover config plist has no BooterConfig parameter and no CsrActiveConfig parameter; you need them for El Capitan and Sierra 9) Your Clover config plist contains a strange SMBIOS profile that bears no board id/serial number/BIOS version; re-inject the MBP11,1 profile using the magic wand I would not expect your system to run well until you fix those defects.

Dr Hurt, we got a winner with RC3. Congratulations! At the risk of being a pain in the backside (but it's probably due to my lack of practice), the trackstick might be a little bit too quick now that it works Ok. Which speed is it set at? If I lower the tracking speed in the PrefPane, I can use the trackstick much better... Sorry, sorry, sorry. Trackstick_RC3.mov

Please use the pack I posted here. Older versions of Chameleon seem to have disappeared from InsanelyMac. You may use attached version r2468. Install with default settings after you've installed the Lion pack from above link (the Chameleon installer will then re-use the pack's Chameleon settings). Chameleon-2.3svn-r2468.pkg.zip

Considering the regularity at which kextcache command ends up with errors when rebuilding cache, I'm recommending NOT to use those tools any more but to revert to good old manual line commands: For kexts placed in /L/E: sudo chmod -Rf 755 /L*/E* sudo chown -Rf 0:0 /L*/E* sudo touch -f /L*/E* sudo kextcache -Boot -U / For kexts placed in /S/L/E: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo touch -f /S*/L*/E* sudo kextcache -Boot -U / If an error 77 is returned, repeat the last 2 x commands (touch + kextcache) or replace the kextcache command by: sudo kextcache -system-prelinked-kernel ` Caution: placing the PS2 controller in /E/E will probably not get it loaded, unlike placing it in /L/E or /S/L/E. myHack uses /E/E as a source location from where it retrieves kexts that are subsequently upped to version 999 and then copied as PlugIns to a kexts called myHack.kext placed in /S/L/E.

You may use the PS2 controller kexts available in the pack of my E6220 guide. It'll work no problem on the E6230.

Indeed, it's unsupported afaik.

Dr Hurt, Release 4 RC2 is nearly perfect on my E6440 with Rushmore V3. Trackstick working nearly Ok, yeah! Just one "little" issue which, I'm sure, will be easy to fix: pushing the tracktstick up moves the pointer down on screen and vice-versa. Other than that, everything is great, including speed. Thank you so much for your brilliant work.

Is it Intel graphics HD 4600? If so, graphics acceleration is obtained through: 1) DSDT injection or Clover faking of desktop HD4600 device id 0412 + Azul framebuffer #12 0x0a260006. For example: Device (IGPU) { Name (_ADR, 0x00020000) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { Store (Package (0x06) { "device-id", Buffer (0x04) { 0x12, 0x04, 0x00, 0x00 // fakes Desktop HD4600 id }, "AAPL,ig-platform-id", Buffer (0x04) { 0x06, 0x00, 0x26, 0x0A // injects Azul framebuffer #12 }, "hda-gfx", Buffer (0x0A) { "onboard-1" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } [...] 2) Use of Rehabman's FakePCIID + FakePCIID_Intel_HD_Graphics kexts If you want HDMI audio, you'll also have to patch HDEF + HDAU devices in DSDT, use patched AppleHDA and Rehabman's FakePCIID_Intel_HDMI_Audio kext.

Which BIOS version do you run? It's usually better to stick to versions A16 or A17, not the very last ones which only brought BIOS security changes. I cannot explain your HDD behaviour, I've never encountered it, yet I've used many different HDDs and SSDs on the various D630 I got into my hands. Disk mode was always set to AHCI and I do not recall ever using ATA mode. If you can advise on the HDD model, we can try and have a look but I'd be very surprised if you had a SATA HDD that did not support AHCI mode. D630 supports SATA-II (3.0Gb/s) by the way. You are talking about an internal HDD by the way, right? Not the USB disk you're apparently using? If you have a Merom CPU (T7xxx), make sure IDA is disabled. If enabled with a non-Penryn CPU, it causes problems under OS X. Re: hanging, when is this happening? At startup or is it a KP? If you're still running the Chameleon version installed by myHack, update the bootloader to something like r2395 or r2401. Those work perfectly. You may use the Chameleon Wizard tool to update or download the relevant package off InsanelyMac for instance. I haven't tried recent Enoch versions on the D630 X3100 with SL or Lion but I would also expect those to work since they work Ok on the D630 nVidia.

With lastest RC, trackstick still operates same way as reported with previous versions. Once trackstick is used, TouchPad dies. Happy to (re)test bpedman's driver if you can remind me which one. Edit: TouchPad actually randomly dies after a few minutes.

much faster than what?

If you're building an Enoch-based USB installer with the manual process I've detailed in all that guide, then yes (of course) you need to manually add the kernel to your USB installer. And yes, you can use the kernel files I posted. Just follow the process listed in the guides.

If you could specify exactly what you've tried/done rather than let us guess...

You need to pay attention to the commands you were provided with... You were given: sudo chmod -Rf 755 /S*/L*/E* sudo chown -Rf 0:0 /S*/L*/E* sudo touch -f /S*/L*/E* sudo kextcache -Boot -U / You typed: sudo -Rf 755 / S * / L * / E * sudo chown Rf 0:0 / S * / L * / E * sudo contact -f / S * / L * / E * sudo kextcache -Boot -U / That ain't gonna work... ever. If in doubt, copy/paste the commands posted on the forum...

I'm afraid that version kills TouchPad after TrackStick.

Can't remember and I don't have that old lappy at hand any more. Which telco are you with?

What's this "Boot Graphics" boot option? 'never seen that before... Make sure you use the PS2Controller posted here.

Try to revert to patched CellPhoneHelper.kext and make sure to patch your current vanilla kext (it varies slightly between OS X versions and releases). Your injector header is a little different from the full header of the vanilla kext, though I cannot say if that's an issue per sé. One other thing. You have: <key>AccessPointName</key> <string>connect</string> when El Capitan 10.11.6 vanilla kext has: <key>AccessPointName</key> <string>Obtain From Service Provider</string> Why don't you try the vanilla settings instead? One last thing. Although it only happened to me once and under ML when I 1st played with WWAN modules a few years ago, I had to specify a username + password in the WWAN module PrefPane tab. I never had to do it again with subsequent installations. You could be in that same situation. All details are here. Check your telco/service provider's published APN settings, they're usually available on the web. Examples here or here.