Hervé

RC #2 released Oct 20th, 2022. Build 22A380. Must be a bug fix. No loss of installed printer after this update! Ventura will be officially released on October 24th.

Trying to think, of possible/potential issues: ACPI patches: you patch HPET's IRQ through CRS but did you check how HPET was coded in the vanilla DSDT table? I'm not familiar with the method of HPET patching you've deployed. It'd be interesting if you posted your extracted DSDT. HPET patching is often only required to fix audio issues. Was that the case for you? trim patches: try to disable them (NVRAM parameter + kext patch) ? add-on kexts: HoRNDIS, FeatureUnlock, VerbStub. Try to disable them?

Released Oct. 18th, 2022. Build 22A379. Ok on my Skylake/HD520 Latitude E7270 with exact same/unmodified Clover r5148 setup previously used for 13.0 beta 3 to 11. Everything working as before. NB: the annoying bug that removes printers after each Ventura (beta) update remains present in this RC.

Looks like a graphics-related issue but difficult to be certain. Check your settings. For reference, Intel i5-5200U includes HD5500 iGPU with id 0x1616 (natively supported) and, with WEG, default BDW framebuffer for MBP12,1 laptop is 0x19260006 (see WEG user manual). As such, in terms of graphics properties, you do not require to inject anything in your boot loader config but the eventual framebuffer DVMT-related patches if you haven't patched (or were not able to patch) your BIOS directly to that effect (through Grub shell commands for instance). AAPL,ig-platform-id 06002616 DATA -> not required, it's the default mobile layout device-id 16160000 DATA -> never required unless faking id is mandatory framebuffer-patch-enable 1 NUMBER -> patching required if default DVMT value=32MB framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA framebuffer-con1-enable 1 NUMBER -> patching con1 for HDMI type only ../.. fraùebuffer-con1-type 00080000 DATA -> ../.. required for HDMI audio I also recommend you execute an NVRAM Reset at OC Picker.

Forget about con1 and con2, these would typically be for eternal displays. You'll probably have to experiment with type and flags of con0; for instance, you may simply try to set con0 to DP/mDP framebuffer-con0-enable 1 NUMBER framebuffer-con0-type 00040000 DATA Do you have any BIOS option to set DVMT at all? Did you try to boot without fbmem + stolenmem patches?

Your graphics settings are perfectly Ok but your screen is not detected. IOREg shows no screen at all. Are you able to identify the type of connector for that built-in screen?

This IOReg shows you're faking iGPU id 0x5917 so it's never going to work... If you have another macOS system, you could try to access this Surface Book 2 remotely but you'd have to setup screen sharing to begin with. You can do that when you boot with one of those invalid ids. You may need to inject your screen EDID if screen goes black when graphics initialize.

Plenty of tools to grab your EDID info but I can recommend Monitor Asset Manager. I've used it several times in the past. Very simple and works without failure. You'll get the EDID info at the very bottom of the application's main window where it is displayed as a long string of comma separated hexadecimal values. This is what you need to collect and edit to remove all commas and spaces. You may then inject the resulting raw long string of hexadecimal characters as device property in the iGPU settings of your bootloader's config: AAPL00,override-no-connect <EDID's hexadecimal string> DATA See the WEG User Manual for reference

It's perfectly normal that you booted without acceleration when injecting an incorrect iGPU id such as 0x9016. You'd have experienced the same result with id 0x1234 or 0x5678. When such parameters are invalid (same applies to framebuffer layout), macOS boots in VESA mode, i.e. a very basic graphics mode without graphics driver that you could compare to Windows safe mode. Try booting with only -disablegfxfirmware boot arg alongside the revised properties injection. You stated that the dGPU was disabled in BIOS so I assume this is an option for this Surface Book 2 which is presumably fitted with nVidia Optimus technology. Usually, disabling Optimus limits the laptop to its dGPU only, voiding dual GPU operation. If you want to run on the UHD 620 for Hackintosh purposes, you probably need to re-enable Optimus but disable the dGPU through patched SSDT. To prove this, do try to re-enable dGPU in BIOS but boot with boot arg -wegnoegpu.

-> moved to Latitude E7xxx section where this thread belongs. Monterey retains native support for HD4600 graphics so you should have no issue installing it on your Haswell E7240; I'm pretty sure we have existing guides and threads on the forum for this. Compared to Big Sur, it's usually just a matter of choosing the correct SMBIOS because Monterey dropped 2013/2014 Haswell MacBook like the MBP11,1 or MBA6,1/MBA6,2 which are typical SMBIOS models used for Haswell Hackintosh laptops. Instead, make sure to use a suitable Haswell model like 2015 MBP11,4 for instance. This is all explained in the Dortania OpenCore guide. NB: Monterey is last macOS version to support Haswell graphics. 'dropped in Ventura so patching will be required.

Legacy computers need specific OC setups. Check the Dortania OpenCore GitHub repo (Legacy/Penryn). Your setup must obviously be inappropriate in its current state. You may also look at my Vostro 200 guide for reference. It's an old C2D Wolfdale system (i.e. same Penryn generation as your Yorkfield platform) that runs Big Sur/Monterey with Opencore. I'm wondering if you wouldn't need the Bootstrap folder with Bootstrap.efi module. Quirks and NVRAM settings need careful examination too. Here are yours: Here are mine:

Yes. Don't hesitate to consult our Hardware Technical Info section (and/or FAQ section) before posting:

No, EDID's information is a long string of hexadecimal characters.

@Hack.intosh The OC config and IOReg you attached in post #1 show that you were: injecting KBL framebuffer layout 0x591B0000 faking iGPU device 0x9016 using SMBIOS MBP15,2 using boot args -igfxlspcon -igfxmlr -igfxdvmt -disablegfxfirmware I believe only #3 to be correct, #1 and #2 being totally wrong with #4 most likely unnecessary. If you look at my old Latitude 7490 guide (i7-8650U CPU with UHD 620 graphics) or other Latitude 7x90/5x90 guides, you would see that the expected properties to inject are: KBL framebuffer layout 0x59160000 or 0x87C00000 iGPU device id 0x5916 (not sure about 0x87C0) As such, your injected properties should look like this: AAPL,ig-platform-id 00001659 DATA device-id 16590000 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA or AAPL,ig-platform-id 0000C087 DATA device-id 16590000 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA or possibly AAPL,ig-platform-id 0000C087 DATA device-id C0870000 DATA framebuffer-patch-enable 1 NUMBER framebuffer-fbmem 00009000 DATA framebuffer-stolenmem 00003001 DATA but framebuffer layout 0x87C00000 and device id 0x87C0 usually are for Amber Lake platforms. Did you try such settings combination without your -igfx---- boot args at all?

Most probably; you'd have to look that up.

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.