Hervé

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:

1. you rename method GPRW to XPRW but disable SSDT-GPRW
2. 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.
3. 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:

1. inject suitable KBL framebuffer for desktop
2. fake KBL iGPU id
3. use SMBIOS of KBL desktop platform (iMac or Mac mini)
4. 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:

1. 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...
2. 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...

That and experiment with other desktop KBL framebuffers as provided in the WEG user manual.

But, more importably, what kind of video output port are you using? KBL FB 0x59120000 defines 3 DP ports:

ID: 59120000, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000110B
TOTAL STOLEN: 39 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 115 MB, MAX OVERALL: 116 MB (122171392 bytes)
Model name: Intel HD Graphics KBL CRB
Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz
Mobile: 0, PipeCount: 3, PortCount: 3, FBMemoryCount: 3
[1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
[3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP
01050900 00040000 87010000
02040A00 00040000 87010000
03060A00 00040000 87010000

I confirm Jake's statement.

Locking this thread due to lazy folks unable to follow/read above statement and comply.

OCLP tool has evolved a lot since then so feel free to experiment with it. My advise is to:

1. 1st install Big Sur with SMBIOS of a supported MacBook Pro (eg: MBP11,4 or MBP11,2). It'll be very slow with poor performance on 1st boot setup.
2. once Big Sur is installed (without graphics acceleration), download latest version of OCLP but don't run it.
3. modify your bootloader's config to change SMBIOS to MBP8,1 and add boot arg -no_compat_check.
4. reboot Big Sur and run OCLP, applying only the SIP settings and the legacy graphics settings.
5. if you use OpenCore, make sure to apply Reset NVRAM at OC Picker when you reboot after you've changed your config file. 

On reboot, your should be running Big Sur with OpenGL-only (no Metal) graphics acceleration. But, as I said so many times, it won't be bug free and you will experiment those graphics defect everybody does. Ideally, upgrade your RAM to 8GB so that macOS allocates 512MB to VRAM.

No ASF2-ralted power off then, which is re-assuring because these are a nightmare when it comes to root cause.

So, other than the ACPI-related cause, nothing other than your own manual forced shutdown, at least for today.

Regarding ACPI Power Management shutdown, my guess would be that it's due to excessive heat causing CPU to go into protection mode. Do you have any CPU T° monitoring in place at all like with HWMonitor app? You'll have to post a zipped copy of your OC EFI folder or, at least of that SSDT-5470 patched table of yours, for us to provide further assessment. Using these single SSDTs really is best avoided as, once again, likely to be proven more problematic than beneficial...

Do you experience the same behaviour if you disable your (DW1820A) Wifi card in BIOS or physically remove it? I know you apply the required ASPM patch but...

Please don't quote messages to post replies; forum provides a Reply box at the bottom of each page.

Your code is Ok but if you renamed your table, make sure you also rename it in your OC config and Reset NVRAM at OC Picker when you reboot. I've tested the stated principle on my own E7270 (with a different SSDT of course) and it works just fine.

RTC-related issue, causing CMOS reset and BIOS settings to return to default. There are bootloaders values you can use in your config to avoid that. It's documented in the OpenCore materials (GitHub repo and probably Dortania). Failing that, you'll find it somewhere on our forum (just can't remember where); from memory it's was something that propped up with Catalina 10.15.4. I probably listed the fix under the Software Matters section so look it up. The issue really depends on the platform you try to run macOS on so please post your system's specs, ideally add them in signature.