Hervé

Nothing wrong with PCI list being empty, it's the case on most Apple Macs; If you want hardware to be listed here, you have to inject the data in your DSDT through _DSM methods; but that's entirely cosmetic. You can look at my E6440 guide and grab one of the posted DSDT to check this out. Re: HEVC, are you aware of its implementation details? Maybe you can refer to the standard and check Haswell iGPU capabilities (HD4400 has no support for HEVC if that still eluded you). https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding http://hevc.info/

I've no issue with my modified DSDT from BIOS A19 and based on the above exchanges, your issue is clearly not DSDT related. Something else has changed. Did you check your hibernation configuration? What mode are you on? Please post output of Terminal command pmset -g Refer to the FAQ forum section for Sleep configuration.

You simply edit your 1st post...

Oh and can you please modify the title of this thread? Because it seems we're getting quite far from just keyboard & trackpad matters...

Wasn't everything sorted out as per discussed at IM ?

Yes, you're right about the DSDT, my compiler must have opened my local table at some point. My apologies, your table does indeed inject the correct info so I've removed my incorrect statement above. With regards to USB ports, you could try the injector I had prepared for my E6440 but I don't know if it'll match the port setup of your E6540. You can't break much by trying it out anyway. If not, you could always build your own using the same process I had detailed in my E6440 guide. I'd also advise you to double check your Clover patch for USB port increase so that you ensure it's the relevant one for 10.13.6.

You don't seem to have the FakePCIID_XHCIMux kext installed in /L/E alongside the other FakePCIID kexts. Add it and see how it goes. All seem Ok on the patched DSDT front. NB: Your Clover config file carries an incorrect IOGraphicsFamily patch for High Sierra so I suspect you experience the boot screen glitch at startup. The correct patch for High Sierra is: Find: 0100007522 Replace by: 010000EB22

Cancelling the restoration midway sure wasn't the brightest idea... Make a fresh install and once done, restore your TM backup from macOS. You don't need to worry about the EFI partition, it's not as if you modified it anyway...

Fitted the Mojave SSD of the E6220 in my D630 and added the necessary modifications for MBP7,1 model: patched PlatformSupport plist (already in place for MBP8,1 SMBIOS on E6220) posted above installation of nVidia kexts/pack from High Sierra 10.13.6 to /S/L/E 10.13.6_nVidia_kexts.zip replacement of Mojave's /S/L/UserEventsPlugins/com.apple.telemetry.plugin by High Sierra 10.13.6's version com.apple.telemetry.plugin.zip The results are similar to what's achieved on the E6220 with HD3000: full graphics acceleration with minor defects (more visible in light mode than dark one). Other than the above small graphics limitations, D630 appears fully functional (sleep/wake, LAN, wifi, WWAN, audio, dGPU throttling/AGPM, etc.)

Update your Clover version through CC and re-install the updated version over your existing one. Make sure to select all the necessary drivers through the options offered by the installation package.

Since Beta #2 or #3, patching does bring back support for HD3000 with minor graphics defects (especially on translucency) that are more visible in light mode than dark mode. Details have been published at MacRumors and/or InsanelyMac but all that's required is: Patch the PlatformSupport plist in /S/L/CoreServices to add those models that are officially unsupported (eg: MacBookPro8,1) or replace it by attached modified version PlatformSupport.plist.zip Install the HD3000 + SNB kexts from a previous macOS version (10.12.6 or 10.13.6 for instance) to /S/L/E SNB_Graphics_kexts.zip Once permissions are repaired and cache rebuilt, HD3000 should be supported as before (with above limitations). Tested and verified on my E6220 with DP4/PB3 (above changes only lead to black screen with DP1): E6220 appears fully functional (sleep/wake, network, audio, etc).

Try and replace the kexts by the afore mentioned version.

Which version of the kext did you use? I run with Bronxteck's R6 (without any mods) and have not experienced those issues at all, neither on my E6220 nor on my E6230.

At today's stage (beta 4), official support for Intel iGPUs in Mojave still starts at Ivy Bridge HD4000 with no support for HD3000. So l can only recommend you wait for 10.14. If you have further queries on Mojave beta, please head over to the section dedicated to that version or check the MacRumors thread on running Mojave on unsupported Macs. Thanks.

Updated BCM5722D LAN kext available in D620/D630 packs thread.

All existing links posted in my old threads are functional, I've just verified them.

Update directly from the AppStore. Then remember to reboot the "install from ..." partition until update has completed. From experience, I can tell I had trouble with Clover r4586 (E6220 would reboot to black screen) whereas no issue with older version r4081 of my initial High Sierra USB installer + original E6220 EFI folder. boot_r4081.zip E6220_EFI.zip (minimised to E6220's applicable files)

I assume that Broadwell iGPU requires the same kind of framebuffer patching as Ivy Bridge and Haswell iGPUs in order to get the DP/HDMI/DVI ports supported. Note that there's a very high chance that only DP and HDMI will work. Lookup for your applicable layout-id in the BDW FB kext and try the same sort of patches I described in my Haswell iGPU guide.

Sierra 10.12.6 it would seem... Screenshot shows -x boot flag anc CPU panic. Was safe mode desired and was AICPUPM patch activated?

You need a BT4.0 compatible Bluetooth module to get Handoff working. It will not work with DW380 which will only get you basic BT functionality. If you want BT, handoff or AirDrop to work like on a Mac, I can only suggest/recommend you got for an Apple BCM94360CD or similar. That's what I've fitted to my E6220/E6230 laptops and I never need to worry about anything anymore.

Impossible to say. Go and do it if you want. With regards, to the IOReg, I assume you still run with dGPU disabled in BIOS because I'm not seeing it in the IOReg. On the other hand, I'm seeing RP05 root device with nothing attached to it. To me this confirms my suspicion of bad ACPI coding... RP05.PEGP is definitely NOT the dGPU, it's PEG0.NVID or PEG0.PEGP.

I'm not sure your Clover config is mot appropriate (I see you Inject Intel + ATI + nVIDIA in your graphics section for instance...) but start by updating your PCIIDxxx + USBInjectAll to the latest versions. You'll get them off Rehabman's usual repo. Then I would revisit your Clover config, especially the ACPI section... Can you post and extracted/saved SysProfiler?

In that case, yes, revert to EC; or use a USB dongle compatible with High Sierra.

According to your DSDT: HD5500 iGPU is ACPI device GFX0 at usual IOReg addresss 0x00020000 nVidia dGPU is ACPI device PEG0.NVID or PEG0.PEGP at usual address 0x00010000 We can try and disable the dGPU by patching the DSDT and/or SSDT tables. Could you post a compressed IOReg saved from IORegistryExplorer app? This would help to confirm the ACPI device used for the nVidia dGPU. What's weird is that SSDT tables #5 and #6 appear to show the dGPU as if it were attached to RP05 parent device and that clearly differs from the DSDT; functions to enable and disable a dGPU device are clearly defined there. In addition SSDT table #4 clearly defines functions for PEG0 and PEG0.PEGP. So we need to clarify the matter as it would not be the 1st time ACPI tables are terribly/poorly coded by the manufacturer...

I'd start by rebuilding the cache.