Hervé

Make sure to repair kexts permissions to /L/E before you rebuild the cache or it'll be ineffective. There's a dedicated thread to that matter in the FAQ section...

I'd say it's your installation package that's dodgy here. Maybe you should download it again...

Arf! You simply edit the entry in your Clover config.plist. Either through a text editor or Clover Configurator app (ACPI tab). But I don't think this is the cause of your issue because that table appears CPU power related...

Webcam are internal USB connected on those laptops and will work OOB when/if supported. If the camera worked before and no longer does under Sierra, then your USB ports are probably not all recognised. Make sure you've applied the usual ACPI patches (renaming of EHCx devices to EH0x) and installed a USB injector kext. If you want further assistance, please post a zipped copy of your Clover EFI folder so that your settings can be examined.

No, you misunderstood. AppleIntelBDWGraphicsFramebuffer is an existing kext that is currently being used on your system to handle/control your integrated iGPU. You do not install any other version or anything of the sort. Once you have identified the port used by HDMI display through an app like IORegistryExplorer, apply the patch as described above through Clover. Use Clover Configurator app to that effect (in Kernel and Kexts Patches tab).

HDMI audio usually requires a binary patch of the graphics framebuffer layout so that the associated display port is set to HDMI connector-type 0008 0000. Please refer to the R&D->Graphics subsection of the forum for guidance (guides for Haswell HD4600 and/or IvyBridge HD4000 for instance) since we're dealing with integrated GPU here, not discrete GPU. You run on Broadwell HD5500 graphics with BDW framebuffer layout-id 16260006. If you look into your IOReg, you'll notice: Framebuffer@0 on port 0 with connector-type 02000000 (LVDS). You'll see the built-in LCD connected to that display port. Framebuffer@1 on port 5 with connector-type 00040000 (DP). Framebuffer@2 on port 6 with connector-type 00040000 (DP). Plug your HDMI display and check in IOReg which framebuffer/port it registers against. Then, in the Broadwell (BDW) framebuffer kext, patch layout-id 16260006 to change the port connector-type from 0004 0000 (DP) to 0800 0000 (HDMI). In 10.13.3, the layout-id is coded as follows: 06002616 01030303 00002002 00005001 // Layout 16260006 (06002616) 00000060 D90A0000 D90A0000 00000000 00000000 00000000 00000800 02000000 30020000 // FB #0/port #0 (0000), type LVDS (02000000) 01050B00 00040000 07050000 // FB #1/port #5 (0105), type DP (00040000) 02040B00 00040000 07050000 // FB #2/port #6 (0204), type DP (00040000) FF000000 01000000 40000000 0B0B0000 01010500 00000000 05000000 00000000 04000000 00000000 00000000 00000000 ` If HDMI is on FB@1/port 5, patch the layout as follows: \/ Find: 01050B000004000007050000 Replace by: 01050B000008000007050000 /\ If HDMI is on FB@2/port 6, patch the layout as follows: \/ Find: 02040B000004000007050000 Replace by: 02040B000008000007050000 /\ ` You can either binary mod the actual BDW framebuffer kext directly with a hex editor (HexFiend for instance) or apply the patch, as described above, in Clover. Kext file is: AppleIntelBDWGraphicsFramebuffer.

What's the reason why legacy boot mode cannot be kept?

Are you latest Clover version? Should be something like r4411 or thereabout.

You can have a look at Jake's post #2 in this recent E6440 thread. Compare your own Clover settings and kexts lists with the contents of the E6440 folder and adjust if necessary.

The E6440 cousin crashes if you plug an HDMI cable without having previously patched the Azul Framebuffer. Could be the same for this mini-DP port on the E7440. You can refer to my HD4600 patching guide and, for DP output, post #2.

High Sierra USB installer is about 8GB, not under 6GB. Which is why you need a 16GB USB key, 8GB models being usually too small. If your own USB installer is just over 5GB, it's not properly made.

Follow the same principles as detailed in the illustrated Ivy Bridge HD4000 and/or Haswell HD4600 patching guides available here: look-up the framebuffer corresponding to your layout-id look-up the output display port in IOReg apply the patch, either as a direct kext binary mod or as a Clover on-the fly patch

Bootloader (Clover) settings problem. You can also Google for this.

You can download the package off the AppStore. Can be done from a VM. Once you have it, there are tutos to create a USB installer from a VM or from Windows. You can Google for it.

"Full QE/CI with HD 3000" means you'll get full graphics acceleration/support with the built-in Intel HD 3000 graphics of the i7-2620M CPU. There is no support for the discrete/add-on nVidia GPU and, since VGA and HDMI display ports are wired to the nVidia chip, these will not work either under OS X/macOS.

You appear to be using a High Sierra installation package of unknown origin or a distro. That's not advisable since you have no idea what modifications were made to that image. Try and obtain a genuine High Sierra installation package and proceed with a vanilla installation.

Use VoodooPS2Controller-R6Bronxteck version posted here. Either place the kext in Clover kexts/Other folder or install it in /L/E (which will require to repair permissions and rebuild the cache). Make sure you do not have any other PS2 controller kext installed anywhere (in /S/L/E, /L/E or Clover kexts folder).

Nothing wrong in that config. Regarding SMBIOS profile, you should really give the MBP11,1 a try. Sometimes the closest SMBIOS in terms of hardware specs does not offer the most adequate CPU power management. I posted my own Haswell experiments in my E6440 guide. You may notice that I only ever obtain a single intermediary step between LFM and HFM. It's much better with the Turbo speeds though. It's older hardware but to give you an example, please know that our good old C2D Dell Latitude Dx20 or Dx30 laptops only gain native CPU SpeedStep with MB5,x/MBP5,x/MPB7,x SMBIOS. If you consider the MB2,1 (GMA950) or MB3,1/MB4,1 (GMA X3100), they're all quasi-perfect match re: hardware specs, yet those SMBIOS do not support CPU SpeedStep at all. Only the other SMBIOS natively provide this, yet they're based on a different generation of chipset and CPUs...

What's the difference between those listed "DeviceN" and "Built-in output" audio devices? I would have expected the latter, not the former, to support built-in speakers. What do you have listed as audio outputs? These will be listed in the "Sound effect" tab:

My E6440 specs are posted in my signature...

Indeed, you should be. What you envisage is not exactly very serious for the targeted professional/working purpose. Who would you be calling for support? Your local IT or good souls on Internet forums?

Make sure to use an appropriate Haswell SMBIOS profile such as MBP11,1.

Understand, we're not going to give you any such commitment for such purposes here. Maybe you ought to look for a MacPro on the 2nd-hand market.

Afaik, you MUST fake desktop id 0412. OS X/macOS just bears no support for mobile HD4600 (id 0416). But, as Bronxteck stated above, it would appear that IntelGraphicsFixup kext does that transparently. Hence the 0412 id in IOReg.

I can confirm this pack works.