Hervé

You run with the config you used to install Big Sur on this unsupported platform which is using MBP11,1 SMBIOS. Whilst this allows you to keep Big Sur updated, my experience is that it prevents proper CPU power management. You should therefore make a backup of this config (for future use to update Big Sur) and revert SMBIOS to MBP9,2 or MBP10,2 and add boot flag -no_compat_check of course. Also make sure you've disabled hibernation as per the dedicated thread in our FAQ section. You may also have opted for something incorrect when you applied the OCLP patch. But only you can tell us what you did in that respect... NB: There is no limitation to 4 lines for your signature; you must be confusing OSXLatitude with InsanelyMac...

No, the problem is not with your laptop, it is with your USB installer. Until you can describe what you've done and post copies of what you used, no-one will be able to help. I suggest you consult existing threads and guides about the E5440.

How what? You're gonna have to be a little more explicit in your posts...

Seems you have a corrupt USB installer. Re-create it, maybe on a different USB key if you have another one. Use a genuine macOS copy of course (they're free), not a distro...

5th gen. Broadwell... Not a natively supported Intel platform by Ventura (minimum official specs for laptops is 7th gen. Kaby Lake). You'll have to go with OCLP patching to obtain graphics acceleration.

Of course you can! It's a simple config file adjustment.

Not familiar with this OpenCore Recovery BaseSystem. Any reason why you chose that over the standard method?

Is this a vanilla installation using a USB installer built with the regular createinstallmedia command? It does not look like one to me... No problem to be expected in using a DP-to-VGA converter as long as it's an active one, not a passive one.

Some contradictory stuff in your setup. For instance: you rename method GPRW to XPRW but disable SSDT-GPRW you appear to seek to use UHD630 iGPU, yet you inject a RadeonSensor PlugIn kext which would be entirely irrelevant if you do not have an AMD Radeon dGPU. you inject CFL/CML desktop framebuffer layout 0x9BC5003 which is connector-less (meaning no output video port) so you'll never obtain anything with that unless you use a dGPU as main graphics card. In such a case, the connector-less iGPU FB is solely for video computing purposes. I suggest you consult the WhateverGreen user manual and use the recommended graphics settings: https://github.com/acidanthera/WhateverGreen/blob/master/Manual/FAQ.IntelHD.en.md#intel-uhd-graphics-610-655-coffee-lake-and-comet-lake-processors

It would appear to be a Synaptics touchpad. So you just need to look for a good old driver (kext) for such models. I'm probably not the best person to provide references on the matter because I've only ever had Dell laptops with Alps touchpad but look up our R&D/Hardware info sections where you'll find several threads related to Synaptics touchpads. You may not obtain all of the fancy features of course but basic mouse gliding + tapping + scrolling should work.

As you stated, Ventura does not officially support Skylake (SKL) platforms. To obtain graphics acceleration for Intel HD 530, you have to basically fake Kaby Lake (KBL) graphics. This is done with the following settings: inject suitable KBL framebuffer for desktop fake KBL iGPU id use SMBIOS of KBL desktop platform (iMac or Mac mini) use latest Lilu & Whatevergreen kext versions

You need to identify your Touchpad model. Please post your system's hardware specs. Ideally an IOReg extract too.

Erm... the boot arg I suggested you removed, on p1...

Did you remove the boot arg?

Configure Sleep as per our recommended settings in the dedicated topic of our FAQ section and report back.

With sleepimage file removed from /var/vm and hibernate file pointing to /dev/null ?

Can't see anything wrong with the OC setup. What are your power management settings? Sleep or hibernate? Looking at the KP info you posted, it seems graphics related. I would suggest you remove that forceRenderStandby=0 boot arg in your OC config.

No weird Github bug, no click on the wrong thing. I assume you did not verify that "Release" section, with v1.0 version... The other stuff looks correct indeed but most people will go to the Release stuff you know. The setup posted there is that of your E6530's.

Looks like you got it quite wrong somewhere... Your Aspire TC-780 is a Kaby Lake/HD630 desktop, yet the OC EFI you posted on your repo applies to a... Sandy Bridge/HD4000 laptop (with Haswell MBP11,3 SMBIOS) and it's clearly not for Ventura. I guess you posted your Latitude E6530's Big Sur setup, oops !

No, you do not delete/remove the audio device properties your inject in your OC config. Did you reset NVRAM after applying the ALC fix and adjusting your OC config with the boot args? 2 comments on your OC config by the way: you should avoid injecting your audio layout id in the audio device properties section and as a boot-arg. It's Ok as long as they're both the same but if you start experimenting with different ids, well... you're running Big Sur so you should be disabling SIP with csr-active-config value 0xFEF, not 0xFFF; latter will prevent you from getting OS updates. See our FAQ topic on disabling SIP for details.

Sorry, my mistake, I didn't read your question properly and with all due attention. Afaik, there are only 3 supported hibernation modes: 0, 3 and 25. You can check those out in the built-in manual pages through Terminal command line: man pmset

Don't hesitate to Google for this kind of things, especially as it's nothing specific to macOS or Hackintosh... Sleep -> memory contents is retained as is and computer does not shutdown. Power LED usually fades in and out as an indication. Wake is immediate. Computer still consumes a little power from the battery so it would completely drain out after a several hours/a few days, depending on battery charge level and wear. This is usually the preferred mode of operation for computers that are used on a very regular basis. Hibernation -> memory contents is dumped to disk and computer shuts down. Wake is slower because computer boots and reloads memory contents from disk. Computer consumes no battery during hibernation. This is usually preferred for computers subject to long period of inactivity. For many years, plain old sleep was recommended on Hackintosh computers because hibernation was not properly/fully supported and often caused crashes/KPs.

Could you try and run without this IOElectrify kext to see if it makes any changes? Remember to reset NVRAM on rebooting after you disable this kext in your OC config.

Not a Precision M model -> moving the to adequate section.

OP's setup is not optimised and partly contradictory. For instance: SSDT-UIAC patched table and USBPorts kext -> should only have one or the other SSDT-EC-USBX_Laptop and SSDT-USBX patches tables -> each with different power settings for USB ports SSDT-AC patched table -> really required? There are probably more patched tables than really necessary and a clean-up needed. SSDT-EC-USBX_Laptop table: Scope (\_SB) { Device (USBX) { Name (_ADR, Zero) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x04) { "kUSBSleepPortCurrentLimit", 0x0BB8, "kUSBWakePortCurrentLimit", 0x0BB8 }) } [...] } SSDT-USBX table: Scope (\_SB) { Device (USBX) { Name (_ADR, Zero) // _ADR: Address Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (LEqual (Arg2, Zero)) { Return (Buffer (One) { 0x03 }) } Return (Package (0x08) { "kUSBSleepPowerSupply", 0x13EC, "kUSBSleepPortCurrentLimit", 0x0834, "kUSBWakePowerSupply", 0x13EC, "kUSBWakePortCurrentLimit", 0x0834 }) } } } Disabling sleep functionality in BIOS is a pretty poor workaround to a broken but most useful feature on a laptop...