Hervé

I've no idea what you're doing or what you're talking about with programs for AMD and programs for Intel. I think you're completely off track here, most likely not knowing what you need to do and/or what you're doing. If you use OpenCore, follow the Dortania Guidance, at least read it. Or you may simply use OpenCore Configurator app or Clover Configurator app, go to the PlatformInfo or SMBIOS tab, select your target SMBIOS model and click on the Generate buttons a few times to regenerate random numbers. Copy/paste those numbers in your existing config on the relevant Hack and you'll be good to go after an NVRAM reset and a reboot. As simple as that. We've a dedicated thread on this very matter for years in our FAQ section, may be you should consult it too... At least next time you have a query.

It should be obvious that if you re-use the same EFI on several Hacks, you should change the serial numbers so that you use a unique one on each of them. Think of it like the postman trying to deliver mail in a street where several physically identical houses have the same number! Just plain common sense, really.

Released Aug 8th, 2022. Build 22A5321d. Ok on my Skylake/HD520 Latitude E7270 with exact same/unmodified Clover r5148 setup previously used for 13.0 beta 3 & 4. Everything working as before.

If you use a desktop Capri framebuffer, you most probably need to patch 1st connector con0 to LVDS/eDP type. Example: ID: 0166000A, STOLEN: 32 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000 TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB, MAX STOLEN: 32 MB, MAX OVERALL: 33 MB (34615296 bytes) Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz Mobile: 0, PipeCount: 2, PortCount: 3, FBMemoryCount: 2 [2] busId: 0x05, pipe: 0, type: 0x00000400, flags: 0x00000107 - ConnectorDP [3] busId: 0x04, pipe: 0, type: 0x00000400, flags: 0x00000107 - ConnectorDP [4] busId: 0x06, pipe: 0, type: 0x00000800, flags: 0x00000006 - ConnectorHDMI 02050000 00040000 07010000 03040000 00040000 07010000 04060000 00080000 06000000 ID: 0166000B, STOLEN: 32 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000 TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB, MAX STOLEN: 32 MB, MAX OVERALL: 33 MB (34615296 bytes) Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz Mobile: 0, PipeCount: 2, PortCount: 3, FBMemoryCount: 2 [2] busId: 0x05, pipe: 0, type: 0x00000400, flags: 0x00000107 - ConnectorDP [3] busId: 0x04, pipe: 0, type: 0x00000400, flags: 0x00000107 - ConnectorDP [4] busId: 0x06, pipe: 0, type: 0x00000800, flags: 0x00000006 - ConnectorHDMI 02050000 00040000 07010000 03040000 00040000 07010000 04060000 00080000 06000000 Capri FB 0x01660004 or 0x01660009 do offer such LVDS/eDP output out by default because they're mobile layouts: ID: 01660004, STOLEN: 32 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000 TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 16 MB, MAX OVERALL: 17 MB (18354176 bytes) Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz Mobile: 1, PipeCount: 3, PortCount: 1, FBMemoryCount: 1 [5] busId: 0x03, pipe: 0, type: 0x00000002, flags: 0x00000230 - ConnectorLVDS 05030000 02000000 30020000 ID: 01660009, STOLEN: 64 MB, FBMEM: 16 MB, VRAM: 1536 MB, Flags: 0x00000000 TOTAL STOLEN: 16 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 48 MB, MAX OVERALL: 49 MB (51916800 bytes) Camellia: CamelliaUnsupported (255), Freq: 1808 Hz, FreqMax: 1808 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [1] busId: 0x00, pipe: 0, type: 0x00000002, flags: 0x00000030 - ConnectorLVDS [2] busId: 0x05, pipe: 0, type: 0x00000400, flags: 0x00000107 - ConnectorDP [3] busId: 0x04, pipe: 0, type: 0x00000400, flags: 0x00000107 - ConnectorDP 01000000 02000000 30000000 02050000 00040000 07010000 03040000 00040000 07010000 Try and patch Capri FB 0x0166000A or 0x0166000B connector con0 with: framebuffer-con0-enable 1 NUMBER framebuffer-con0-alldata 010000000200000030000000 DATA or things like that, i.e. the LVDS/eDP connector of a Capri mobile framebuffer. Refer to the Whatevergreen User Manual for the list of Capri FB and their settings. Ideally, you'd need the IOReg of a 2013 HD4000 Education iMac13,1 to look at, 2012 iMac13,1 models with nVidia Kepler graphics using headless Capri FB 0x01620006.

LVDS or eDP, it's the same thing for a Capri framebuffer. Makes no difference. There's a chance you'll need to inject your screen's EDID because the actual display is not natively supported/recognized. You can look this up, plenty of ways to get this through Windows or Linux. You then inject this in your bootloder's iGPU device properties set through DATA property AAPL00,override-no-connect for which you specify the hexadecimal value of your EDID (without any space or comma characters, just the Hex value).

So it's an i3-10300H Comet Lake CPU with UHD620 iGPU (device id 9BC4) which is natively supported. See the Whatevergreen User Manual. The GTX 1650 Ti is totally unsupported as explained in previous post. I've noticed a few incorrect settings in your Clover config: I don't thing you need that CpuTscSync kext at all your iGPU + audio property injections are erroneously duplicated. Remove those incorrect custom properties (Arbitrary) of yours, just keep the regular Properties remove the iGPU id faking; as stated above CML id 0x9BC4 is natively supported you should probably use framebuffer 0x3EA50009 rather than 0x3E920000 as per the WEG manual remove those connector patches to begin with, stick to the vanilla settings you'll need to disable your nVidia dGPU to save your battery (-wegnoegpu boot-arg to begin with, patched SSDT thereafter) Comet Lake (CML) graphics are handled through Coffee Lake (CFL) framebuffers. CFL FB 0x3EA50009 defines the following characteristics: ID: 3EA50009, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00830B0A TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel HD Graphics CFL CRB Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000001C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 which should do just fine.

There's no such thing as a GTX 1350 Ti ! If you meant a Turing dGPU like the GTX 1650 Ti fitted to this model of Asus TUF gaming F15, that has no support whatsoever in macOS. You could only run maOS on the Intel CML iGPU. So, until you post your full system's specs, you're wasting your time... and ours. If you have a CML i5-10200H CPU, you're screwed; its iGPU is unsupported too. See here. Follow one of the main basic rules of Hackintoshing: https://dortania.github.io/OpenCore-Install-Guide/prerequisites.html#prerequisites

Ok, we'll probably have to make adjustments on the graphics properties injection side. AIO computers usually have an LVDS type built-in screen, just like laptops. This will need to be taken into consideration. Capri mobile framebuffer 0x0166004 is probably a good one to start with, without any of those connector patches you currently have in your config. Also remove the stolenmem patch, it's not applicable to HD4000 graphics. On the CPU power management side, you've correctly applied the CpuPm quirk (patch) but you're missing the generated CPU PM SSDT for your Ivy Bridge CPU. You'll need that as it'll define the correct settings for your particular CPU. Use the good old generator script from Pike R Alpha to that effect.

Brightness usually requires injecting a SSDT-PNLF patched table. We'll see if you've included that in your bootloader's pack once you've posted your system's specs + zipped EFI folder.

Renaming the kexts is indeed sufficient. For instance: itlwm_mojave -> min kernel = 18.0.0, max kernel = 18.99.99 itlwm_monterey -> min kernel = 21.0.0, max kernel = 21.99.99 With Clover, you would have placed the different itlwm kexts in the dedicated macOS version folders (eg: 10.14, 12), leaving the other ones in Other folder.

Hi, please specify the bootloader and bootloader version you're using. Post a zipped copy of the EFI folder. What's the screen resolution on this AIO?

Ha Ok, missed that completely: Thing is OP has no RP01 bridge in his IOReg so, indeed, I'm not sure this patched SSDT does anything at all... And does he have TB3 devices that he'd want to HotPlug???

You did not provided the require SysInfo extract. Open System Information from Apple menu whilst pressing [Option], save it as a .spx file, zip it and post it. Anyway, it's confirmed: it's the Thunderbolt3 hardware. I don't know how or why these get reported as ExpressCards. Possibly a Ventura beta bug...

Do you have CodecCommander kext in your existing kexts set? Obviously you must only use 1 x audio layout-id in your config: either as a property injection against you audio device or as a boot arg in the NVRAM section. But not both or, at least, not 2 with different values. From memory, E7440 is fitted with same ALC292 codec as other Haswell E6x40 models and requires layout id 12 (or 0x0c in Hex). JakeLo's guide does mention a fix in both his 2018 Clover guide and his 2020 Opencore guide to sort out the very issue you mention. Did you download it and run the shell script?

@Hecatomb A word of advice when you want to post a copy of your EFI folder: remove the itlwm kext(s). Your EFI has no less than 4 x different copies of it, totalling in excess of 64MB ! You don't need to post that. 8086:15d2 is an Intel TB3 controller; can't say why it gets registered as an ExpressCard in Ventura. No idea what that 2nd PCI device listed as XHCI controller (i.e. USB3 controller) really is, no visible PCI ids. You were asked for a SysInfo extract + an IOreg extract but so far...nothing. I presume previous macOS versions did not register such hardware as ExpressCards. Ventura is only at fairly early beta stage so you may want to consider this a bug... If you delete the icon by holding [Command] whilst dragging the icon out of the menu but it keeps coming back at subsequent reboot, I've no idea how to remove it permanently if there's no option in Systems Settings to that effect. Good luck.

Please specify your computer model and its specs. Ideally, publish those in your signature like most people do.

OP's obviously got a 7480 with the QHD touchscreen... See the product's documentation on Dell web site.

You should also remove these kexts found in the original pack you got from Github: IOGraphicsFamily -> can't imagine what this would do; a patched version used to be required many years ago to fix the garbled Apple logo at boot time but it's long been deprecated CPUFriend + CPUFriendDataProvider -> the data kext would be specific to the OP's i5-8265U and should therefore be re-generated for your own CPU. Then, of course, update all other kexts to latest version.

Yup, just download latest OC version and make your own EFI using the guidance posted at Dortania. All required kexts are known by now, the E6440 is an old Haswell laptop with all fitted hardware fully documented. Tons of threads about this model on the forum too.

Seeing what you currently inject for iGPU properties, did you try the settings recommended in the Whatevergreen User Manual instead? Probably a good starting point as an alternative to this which clearly is incorrect: And experiment with other framebuffers such as 0x3EA50009 to begin with.

Please post your laptops spec, ideally add them in signature. Several people encountered difficulties with Whiskey Lake models/platforms.

For your signature: click on your account name at top of forum Window, then go to Account Settings->Signature. About your graphics setup: Strange that you opted for MBP15,2 (a Coffee Lake model) on your Kaby Lake/HD620 laptop when you'd be expected to use MBP14,1 (a Kaby Lake model)l. I invite you to try it out. KBL framebuffer 0x59160000 certainly is correct for KBL HD620 and your connector patches are all good though con0's is not required since you inject the exact same thing as what's natively defined in the framebuffer. You correctly swap connector's type for HDMI and DP given that, in the vanilla FB, con1 is DP and con2 is DP: ID: 59160000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00000B0B TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 103 MB, MAX OVERALL: 104 MB (109588480 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00080000 87010000 You could also experiment with KBL FB 0x591B0000 (it's the recommended one for KBL HD620). It requires patching con1 alldata to same as FB 0x59160000 or you won't get HDMI output of course: ID: 591B0000, STOLEN: 38 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000130B TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 136 MB, MAX OVERALL: 137 MB (144191488 bytes) Model name: Intel HD Graphics KBL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000098 - ConnectorLVDS [2] busId: 0x04, pipe: 10, type: 0x00000800, flags: 0x00000187 - ConnectorHDMI [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 02040A00 00080000 87010000 -> Needs to be patched to 01050900 ... 03060A00 00040000 87010000 -> can stay as is afaik, no need to patch to 0204... I've never seen anyone injection a pci-asm-default value for an iGPU. Did you try HDMI output without injecting this parameter? Where did you get the idea to inject a different framebuffer-flags value from? How did you choose the value?

What's your CPU/iGPU? What SMBIOS do you use? What iGPU properties do you inject?

Indeed, once you increase DVMT to 64MB or 96MB in BIOS, the fbmem + stolenmem patches become irrelevant and even counter productive since they usually aim to reduce the default values of the selected framebuffer so that the sum of them remains below 32MB. In your case, it looks like 64MB is the max value you can set for DVMT pre-allocated memory. May be you can experiment with DVMT total values (256/128/Max).

Did you check the default DVMT settings of your 7480? Under macOS, DVMT must usually be set to 64MB or 96MB to obtain 4K output; afaik, you won't get it if DVMT is set to 32MB even if you patch the DVMT settings (fbmem + stolenmem) through properties injection. With DVMT set to 64MB or 96MB (BIOS mod through Grubshell, see our FAQ topic on the matter or my E7270 guide), I can get 4K @24-30Hz out of HDMI and 4K@60Hz out of mDP on my Skylake/HD520 E7270 laptop. Can't see why it'd be different on your 7480, unless it's the TB port that's causing the issue under macOS of course. Don't hesitate to post a zipped copy of your bootloader's EFI folder so that we can check your settings. Do post your system's specs in signature since they're are 6th gen and 7th gen 7480...