Hervé

2nd IOReg is indicative of progress and improvement because it now shows 2 x displays (i.e. screens): 1 off con0 (i.e. built-in display) and 1 off con1 (i.e. HDMI external screen): Things to work on now are: getting your buit-in display recognised as such ("AppleDisplay" usually mean external screen when a buit-in LCD screen normally registers as "AppleBacklightDisplay"). black screen issue; this may require you to inject your screen's EDID. You would 1st need to extract it from say Windows. There are existing and readily available tools to do that.

@svan71 Nothing to worry about the model of CPU reported; it's without any impact of any kind; you can ignore this or inject the relevant description if you feel this is necessary but it'll be cosmetic only. Several things to address in your posted config: your config indicates you use a patched DSDT table; please post it so that we try and establish what patches it contains; kinda essential here. you disable SIP with boot arg csr-active-config set to 0x0FFF; that's wrong for Big Sur and later as it prevents all macOS OTA updates; disable SIP with value 0x0FEF instead. your SKL framebuffer patching most likely needs to be revised; seems awfully complicated to me. Vanilla SKL framebuffer 0x19120000 defines the following video settings: ID: 19120000, STOLEN: 34 MB, FBMEM: 21 MB, VRAM: 1536 MB, Flags: 0x0000110F TOTAL STOLEN: 56 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 124 MB, MAX OVERALL: 125 MB (131608576 bytes) Model name: Intel HD Graphics SKL CRB Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 3, FBMemoryCount: 3 [255] busId: 0x00, pipe: 0, type: 0x00000001, flags: 0x00000020 - ConnectorDummy [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x00000187 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x00000187 - ConnectorDP FF000000 01000000 20000000 01050900 00040000 87010000 02040A00 00040000 87010000 i.e. 2 DP output ports + a dummy one: Dummy port: FF000000 01000000 20000000 DP video port: 01050900 00040000 87010000 DP video port: 02040A00 00040000 87010000 Your set of injected graphics properties is incorrect because those properties are arguable : Intel i5-6400T and i5-6500T both integrate HD 530 iGPU with id 0x1912; as such, no need to inject/fake your iGPU's own native id (though it does no harm of course) you inject some properties/values that are identical to the selected framebuffer's own default settings; harmless of course but utterly useless you inject properties for 4th connector con3 on a 3port framebuffer layout without changing portcount value; I don't believe this can work and I'm failing to see the purpose anyway macOS SKL framebuffer kext defines a raft of mobile layouts (most of them with 3 output ports, only 1 with 4 output ports) and 4 connectionless desktop layouts (i.e. no output ports). Cf. Whatevergreeen user manual. Let's look at 4port layout 0x193B0005: ID: 193B0005, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0023130A TOTAL STOLEN: 35 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 137 MB, MAX OVERALL: 138 MB (145244160 bytes) Model name: Intel Iris Pro Graphics 580 Camellia: CamelliaDisabled (0), Freq: 1388 Hz, FreqMax: 1388 Hz Mobile: 1, PipeCount: 3, PortCount: 4, FBMemoryCount: 4 [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 [3] busId: 0x06, pipe: 10, type: 0x00000400, flags: 0x000001C7 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 C7010000 02040A00 00040000 C7010000 03060A00 00040000 C7010000 You'll see that it defines the following 4 ports (with PortCount set to 4): 1 x LVDS (i.e. built-in LCD) video output + 3 x DP video outputs It's highly likely that the built-in screen of your AIO computer is LVDS type. As such, you may experiment with layout 0x191B0005 or inject the con0 properties of that layout to your existing config. You would normally expect your built-in screen to be on connector con0 and your HDMI output on con1 0105xxxx. Posting an IOReg extract (i.e. saved output from IOREgistryExplorer app) would greatly help to confirm your situation. Please note that patching a DP connector type to HDMI is only necessary to obtain HDMI audio, it's not necessary for video output. I'm highly sceptical about your connectors patching which effectively applies the following arrangements: con0: 02040A00 00080000 87010000 -> type HDMI and connector's id usually used for con2 con1: 03050A00 00080000 [87010000] -> type HDMI and unusual connector's id; unmodified flags con2: 01050900 00080000 [87010000] -> type HDMI and unusual connector's id; unmodified flags con3: FF?????? 01000000 20000000 -> dummy port? Why? Invalid anyway when PortCount remains set to 3 I would suggest that: you open up your AOI computer and identify your built-in screen type: LVDS or mDP for instance 1st test using SKL frambuffer layout 0x191B0003 with default (i.e. unpatched) connector's settings if unsuccessful, you may then return to layout 0x19120000 but inject the following connectors settings only (i.e. remove all the others): framebuffer-con0-enable 1 NUMBER framebuffer-con0-alldata 000008000200000098000000 DATA -> sets con0 to LVDS output port framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA -> sets con1 to HDMI type If your built-in screen were actually mDP (miniDP), you could try: framebuffer-con0-enable 1 NUMBER framebuffer-con0-alldata 000008000004000098000000 DATA -> sets con0 to DP output port framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA -> sets con1 to HDMI type Of course, if your AIO's default settings sets DVMT to 32MB and you've not patched this, keep your existing fbmem and stolenmem patching as it is, i.e. framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA Whatevergreen boot arg igfxonln=1 may not be useful at all but does no harm of course; it's usually useful when, say, you plug HDMI and built-in screen goes black and never recovers after unplugging HDMI; this sort of things. I'm not convinced it'll do anything in the case of your built-in screen going dark at graphics initialisation, something very common on AOI Hackintosh computers.

Released Oct. 11th, 2022. Build 22A5373b. Ok on my Skylake/HD520 Latitude E7270 with exact same/unmodified Clover r5148 setup previously used for 13.0 beta 3 to 10. Everything working as before.

Then don't even try to do anything on the matter.

You're probably mistaken re: DSDT and ACPI tables in general... There's absolutely nothing to do with the ACPI tables you extracted. They're an integral part of your computer's BIOS so they load at power-on/boot time. As such, placing unmodified tables is the ACPI folder of your bootloader's EFI folder is of no use at all. It'd be as useful as applying a Dell sticker on top of the Dell logo already present on your laptop if you get my meaning. Only patched tables are of use and are to be placed in the EFI/ACPI folder.

You just need to look them up in the various 7280 threads that exist on the forum. No-one published a specific guide here for this model unfortunately. Eg: What did you initially follow to install macOS on your laptop? @Lorys89 has a guide with all-inclusive SSDT here and brightness control is stated to be fully working. Maybe there's something not correctly set in your BIOS though I doubt it.

See my Ventura beta 3 thread.

Probably something else fishy in that all-inclusive SSDT of yours.

Try these where I've removed references to GFX0 and replaced them by IGPU in the SSDT-PNLF table + renaming of GFX0 to IGPU in the OC config. Adjusted_config_ACPI_tables.zip

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

I'm pretty sure your PNLF patched device des not attach to the iGPU. Please post a zipped copy of your bootloader's ACPI folder + config file.

You really should post your stuff because you've lost me here... Ideally, save an IOReg output from IORegistryExplorer app, zip it and attach it. You made a typo in your revised set of iGPU injected properties. It's of no consequence to your LCD display but it's likely to prevent HDMI output.

I recommend you start with a basic set of graphics properties injection rather that what you currently use and that may be inadequate. I suggest you stick to the following set of properties and comment out all the rest of your properties by placing a # character in front of the keys: AAPL,ig-platform-id 00001659 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00080000 DATA You may then consider commenting out the PNLF section of your all-inclusive SSDT and add a SSDT-PNLF standard table that you may grab off the Dortania repo.

For HD620 graphics, you should be injecting KBL frame buffer 0x59160000. 0x591b0000 is for HD630 though it's highly likely to work nevertheless. HD620 iGPU of i5-7300u CPU carries PCI id 0x5916 so no need to inject this of course (but doing it will cause no harm).

You don't even appear to have graphics acceleration in place so talking about brightness control may be a bit premature here...

Adding a separate SSDT-PNLF is not going to work because ACPI operation will probably prevent injecting a 2nd PNLF device having already a patched one. As for deleting your existing SSDT, I could not possibly recommend it because you have one of those all-inclusive SSDTs that includes several other patches that are usually provided individually through separate SSDTs; so if you remove your current patched table to replace it by a PNLF SSDT only, you'll probably break your Hack. What you may consider though in such situation is either: replace the PNLF contents of your current all-inclusive SSDT by that of a dedicated SSDT-PNLF or switch back to a more traditional set of individual SSDT patched tables which allows you to know exactly what you've got in terms of patches Whatever you choose to do, do it through a bootable USB key. Some people are fans of this sort of all-inclusive SSDTs but I'm of the opinion that they cause more trouble than good because, like distros, you never know what's inside until you carefully look at the code they contain.

PNLF section of your all-inclusive SSDT looks a bit short to me... I invite you to compare with the more "regular/usual" SSDT-PNLF recommended/available for KBL platforms. https://dortania.github.io/OpenCore-Install-Guide/config-laptop.plist/kaby-lake.html https://dortania.github.io/Getting-Started-With-ACPI/ssdt-methods/ssdt-prebuilt.html#laptop-skylake-and-kaby-lake https://github.com/dortania/Getting-Started-With-ACPI/blob/master/extra-files/compiled/SSDT-PNLF.aml

There's nothing specific about KBL HD620 graphics as far as 1920x1080 and Monterey are concerned. The graphics settings remain the same whatever the macOS version.

-> moving to correct Latitude 7xxx forum section. Plenty of thread/topics and available Clover or OpenCore bootlicks (EFI folders) for Kaby Lake Latitude 7280 on the forum. Please use the forum search facility and try and post in the correct sections.

-> moving this topic to Latitude 7xxx section and adjusting title since it's a Latitude 7420, not an E7420 (which does not exist). You won't find much topics nor guides for this model simply because it's not supported. Before the switch to Apple Silicon, last Intel MacBook computers (2020) were based on 8th/9th gen Coffee Lake hardware (MacBook Pro) and 10th gen Ice Lake hardware (MacBook Air). As such, macOS has no support for graphics/iGPUs of Intel 11th gen CPUs. Sorry for the bad news but you can forget about running macOS on your Latitude 7420 laptop. I invite you to consult the various threads we have posted in our Technical information section where you'll find lots of information about supported Intel platforms, supported GPUs, associated OS X/macOs versions, etc.

OpenCore 0.8.5 can be assumed to correct, not a typo; you're probably not looking at the right place for it or not aware of it. Acidanthera's Github repo is where the OC packages are posted every month once officially released. Version 0.8.5 will be published there in October. You may still get the pre-release builds from the Dortania Github repo. The OC reference manual has already been updated to v0.8.5. I suggest you post your E7270 pre-Ventura issues in your own thread in order to avoid polluting this one which is about an HP laptop. Closing it.

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

-> moved to Booloaders section. Your config shows you've opted for picker mode external, i.e. the OpenCore GUI. Make sure you've updated your OC Resources folder to the relevant one for OC v0.8.4. When you update OC, you have to update everything. https://dortania.github.io/OpenCore-Post-Install/cosmetic/gui.html#setting-up-opencore-s-gui https://github.com/acidanthera/OcBinaryData/archive/refs/heads/master.zip

-> Topic moved to Ventura beta section since macOS 13.0 remains in pre-release/beta stage to date. Congrats! See how simple it was? And, of course, it's full graphics acceleration on Intel HD520, not Intel HD620 since your platform is and remains Skylake not Kaby Lake; faking KBL iGPU does not change anything in that respect. As such, I'd have avoided injecting "Intel HD Graphics 620" iGPU model in your OC config. Just to avoid confusion really but it's only cosmetic... NB: you mention using a DW1560 wifi card but, on Github, you listed an Apple BCM94360CS2 in your system specifications.

Released Sept. 20th, 2022. Build 22A5352e. Ok on my Skylake/HD520 Latitude E7270 with exact same/unmodified Clover r5148 setup previously used for 13.0 beta 3 to 7. Everything working as before.