Hervé

Try and change con1's pipe to 0x12.

Doesn't seem to be a standard disk or USB disk but some form of virtual setup. This matter is unrelated to the boot loader but your platform arrangement. A VM it would seem?

Released Mar 7th, 2024. Build 23E214 Enhancements, bug fixes ans security updates. Safe to install on our Hackintosh platforms. Note that it's important to update wireless kexts IO80211FamilyLegacy + IOSkywalkFamily to new versions tuned for Sonoma 14.4 (kexts used up to 14.3 no longer work). No wifi without those revised kexts. All details are available here in our dedicated thread on the matter. Also released at the same time: macOS Ventura Security Update 13.6.5 (build 22G621) macOS Monterey Security Update 12.7.4 (build 21H1123) View full article

No idea what you mean by colour being "funny". If colours look funny to you on screen, maybe you just need to tune/calibrate your screen profile or use a different one. IOReg shows KBL framebuffer 0x59120000, yet you still inject patches to set con0/con1/con2 to DP, which is what they natively are... 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 No harm of couse, just totally useless.

Good, thanks for the feedback.

The WEG manual details the connectors patches very clearly and as follows; I really don't know where you copied your values from... framebuffer-conX-enable (enabling patches for connector X) framebuffer-conX-index framebuffer-conX-busid framebuffer-conX-pipe framebuffer-conX-type framebuffer-conX-flags framebuffer-conX-alldata (completely replace the connector) framebuffer-conX-YYYYYYYY-alldata (completely replace the connector, if the current framebuffer matches YYYYYYYY) Where X is the connector index. Alldata patches can patch multiple connectors in sequence by putting them in a single string and specifying the index of a connector to start with. The string length should be a multiple of 12 bytes (the length of a single connector) You may have missed that 12-bytes alldata property is comprised of index + busid + pipe + type + flags. I specified the size of each element in my previous post. This parameter can cover multiple connectors as long as you specify a multiple of 12 bytes and these will cover the specified connector and the following multiple-1 connectors. For instance: framebuffer-con0-alldata AAAAAAAABBBBBBBBCCCCCCCCLLLLLLLLMMMMMMMMNNNNNNNNXXXXXXXXYYYYYYYYZZZZZZZZ DATA is the same as framebuffer-con0-alldata AAAAAAAABBBBBBBBCCCCCCCC DATA framebuffer-con1-alldata LLLLLLLLMMMMMMMMNNNNNNNN DATA framebuffer-con2-alldata XXXXXXXXYYYYYYYYZZZZZZZZ DATA and framebuffer-con1-alldata DDDDDDDDEEEEEEEEFFFFFFFFRRRRRRRRSSSSSSSSTTTTTTTT DATA is the same as framebuffer-con1-alldata DDDDDDDDEEEEEEEEFFFFFFFF DATA framebuffer-con2-alldata RRRRRRRRSSSSSSSSTTTTTTTT DATA Note that you can't patch con0 and con2 (without patching con1) in a single 24-bytes alldata injection. This being said, experiment with iGPU properties injections such as this: AAPL,ig-platform-id 00001659 DATA (-> KBL framebuffer 0x59160000) AAPL,slot-name Built-in STRING (-> this is purely cosmetic) force-online 1 NUMBER (-> same as igfxonln=1 boot-arg) Given that your screen appeared attached to connector con1 in a previous IOReg extract, it's fair to say that you may experiment with any other framebuffer that has con1 as DP by default. These include: Desktop: 0x59120000 (the recommended framebuffer for KBL desktop but does not seem to suit you) 0x59230000 0x59260000 0x59260007 (watch, max stolenmem set to 79MB so DVMT must be 96MB, else KP most probably) 0x59270000 Laptop: 0x59160000 (this is the default framebuffer if you do not inject any specific AAPL,ig-platform-id property) 0x59160009 0x591C0005 0x591E0000 0x591E0001 0x59260002 0x59270004 0x59270009 0x87C00000 0x87x00005 Mobile framebuffer 0x591B0000 defines 3 ports: LVDS + HDMI + DP so, if you use that one, you'll have to patch con1 to DP by adding the following properties: framebuffer-patch-enable 1 NUMBER framebuffer-con1-enable 1 NUMBER framebuffer-con1-type 00040000 DATA If you do not get anywhere with any of those framebuffer and default/native device id 0x5912 (that of your particular iGPU), then you may add the following property: device-id 0x16590000 DATA and start your experimentation again with all those frame buffers above. Then, you may consider doing it all again with other device ids but that's a rather unusual thing to do. Supported device ids are listed in the WEG user manual. If nothing works out to provide you 4K@60Hz, you may then consider patching connector's Flags but I'm dry on that one; never had to. This would be done with the following additional properties: framebuffer-patch-enable 1 NUMBER framebuffer-conX-enable 1 NUMBER (-> where X is target connector framebuffer-conX-flags XXXXXXXX DATA (-> where X is target connector and XXXXXXXX target flags value) NB: Please note that you never enter any space in DATA values; spaces are simply displayed by tools such as OCC or CC for ease of reading. Good luck.

Those connector patches are somehow incorrect; if you opt for alldata connector patches, know that it's a 12byte value as stated in the WEG user manual. You inject 14, so... Maybe you should opt for the specific individual patches like index (8bit), busId (8bit), pipe (16bit), type (32bit), flags (32bit). You may find this less confusing. You need to read the WEG user manual with all due attention, all these are thoroughly explained at the bottom of the document. Framebuffer layout and iGPU device id are not aligned, meaning that if you opt for, say, framebuffer 0x59260000 (AAPL,ig-platform-id 00002659), you do not have to set iGPU device id to 0x5926 (device-id 26590000). Start with default/native device id (i.e. remove the injected property), then experiment with different layouts. You may then fake a different iGPU id and start all over with framebuffers. Proceed in an orderly and logical manner. If you're able to boot without the stolenmem and fbmem patches, then DVMT is already set to, at least, 64MB and you can forget about it. Nothing prevents you from checking if you have an option in your computer's BIOS settings to adjust this. But as long as it's set to 64MB minimum, you're Ok for graphics acceleration and should be Ok for 4K. More than 64MB is a plus but rarely necessary. See our dedicated thread on DVMT in our FAQ section. My Skylake E7270 gives me 4K@60Hz with DVMT patched to 64MB, KBL framebuffer 0x59100000 and fake device id 0x5916. Make sure to consult the KBL framebuffers information detailed in the Whatevergreen user manual re: connectors and DVMT. Careful if you experiment with framebuffer 0x59260007 because that one is stipulated with 79MB total stolen memory. With DVMT set to 64MB, I expect you'll encounter KP. Ok if DVMT is set to 96MB.

You only patch connectors if you want/need to. And if you do, you need the framebuffer-conX-enable properties set to true. Property framebuffer-patch-enable is to patch framebuffer general properties, not connectors characteristics. I think you're all over the place in your attempts to obtain 4K@60Hz and doing things wrong. Why do you increase NVRAM to 2GB? It's not really necessary and won't help towards getting 4K@60Hz. I see a commented property (thank God!) for EDID injection! Only laptops may require this, not external screens. You may have other items such as boot args that now cause your graphics-related KP. Make sure to proceed cautiously with a bootable USB key and to experiment with suitable parameters not just anything you can throw at the Hack. I would invite you to read the Whatevergreen manual + Github information for details about patches and boot-args.

So you have a desktop computer with 7th gen Kaby Lake CPU i5-7500. Integrated HD 630 graphics support 4K as follows: You use KBL framebuffer 0x59120000 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 which defines 3 DP ports by default. You patched these to HDMI type through your "alldata" patches. It's unnecessary if you use a DP video port, wouldn't you say? Your IOReg shows that your screen gets attached to connector con1 so I would remove the connector type patch for that connector at a minimum. I don't know why you changed busId of con2 from 0x06 to 0x00 but it doesn't really matter. Now, if this does not resolve the issue of not obtaining 4K@60Hz, you can always try and experiment with other KBL frame buffers, even mobile ones such as 0x59160000, 0x591b0000 or 0x591e0000 for instance. Latter was what @quartz38 recently used to obtain HDMI output on his KBL R desktop platform as described here. I assume you do proceed with clearing NVRAM at OC Picker after you reboot following a config change. NB: injecting hardware's own native id is unnecessary (as is the case for your iGPU) but harmless of course; you only need to do that when you want to inject/fake a different device id. You may also experiment with device id 0x5916.

I would remove the patches you use to set all your connectors to HDMI type since you're using DP outputs.

Please post computer's CPU specs/model and an IOReg too. Issue must be related to video output type. What do you use? What kind of video connection on the screen? Assuming you have KBL CPU with HD630, it's highly likely that: your iGPU only supports 4K@24/30Hz out of HDMI your iGPU supports 4K@60Hz over DP only If you use a DP-to-HDMI adapter/converter, it must a 4K-specific model to obtain 4K@60Hz.

You need to have DVMT set at 64MB minimum to obtain 4K@60Hz. If DVMT is set at 32MB, you'll only obtain 4K@24/30Hz.

Hi. I’ve encountered this behaviour on all my recent Dell Hackintosh laptops. Never found a fix. Initiating sleep and interrupting it by an action like moving the mouse fixes it. Possibly an IRQ or HPET-related matter.

Did you try and experiment with other CFL mobile framebuffers? For instance FB 0x3EA50004: ID: 3EA50004, STOLEN: 57 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00E30B0A TOTAL STOLEN: 58 MB, TOTAL CURSOR: 1 MB (1572864 bytes), MAX STOLEN: 172 MB, MAX OVERALL: 173 MB (181940224 bytes) Model name: Intel Iris Plus Graphics 655 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: 0x00000498 - ConnectorLVDS [1] busId: 0x05, pipe: 9, type: 0x00000400, flags: 0x000003C7 - ConnectorDP [2] busId: 0x04, pipe: 10, type: 0x00000400, flags: 0x000003C7 - ConnectorDP 00000800 02000000 98040000 01050900 00040000 C7030000 02040A00 00040000 C7030000 or 0x3EA50006: ID: 3E9B0006, STOLEN: 38 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x00131302 TOTAL STOLEN: 39 MB, TOTAL CURSOR: 512 KB, MAX STOLEN: 39 MB, MAX OVERALL: 39 MB (41422848 bytes) Model name: Intel UHD Graphics 630 Camellia: CamelliaV3 (3), Freq: 0 Hz, FreqMax: 0 Hz Mobile: 1, PipeCount: 1, PortCount: 1, FBMemoryCount: 1 [0] busId: 0x00, pipe: 8, type: 0x00000002, flags: 0x00000498 - ConnectorLVDS 00000800 02000000 98040000 Latter would need to be patched for 3 ports and injection of con1+con2 as additional connectors of course. Or change con1/con2 flags of FB 0x3EA50009 from C7010000 to 87010000 or C7030000? Try and post an IOReg extract when HDMI is plugged in.

You should have been able to set DVMT to 64MB or more through Grub. Other reading that would have been of value to you:

Congrats. So KBL mobile framebuffer 0x591e000 it is then! ID: 591E0000, STOLEN: 34 MB, FBMEM: 0 bytes, VRAM: 1536 MB, Flags: 0x0000078B 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: 0x00000400, flags: 0x00000187 - ConnectorDP 00000800 02000000 98000000 01050900 00040000 87010000 02040A00 00040000 87010000 with con1 patched for Pipe=0x12 and Type=HDMI, at least according to your IOREG because it sure ain't in your last posted config. For some reason you also inject this and it really is not necessary (and incorrect) but it's just cosmetic, so... model Intel HD Graphics CFL CRB DATA Injecting "Intel Graphics UHD 620" would be much more appropriate. con0 patches can also be removed with this mobile frame buffer, con0 being for an eDP/LVDS built-in screen. Try and add boot arg igfxonln=1 to your OC config to force all displays online.

Widows and macOS do not operate the same way at all; you'll find nothing in Windows re: Index, BusId, connectors or flags; that's all specific to macOS.

Increasing VRAM will not help. Didn't you mean DVMT? Check your BIOS settings, they may support setting this directly. Otherwise, yes, re-instate the fbmem/stolenmem patches.

Try the following additional properties in your iGPU settings: framebuffer-con0-enable framebuffer-con0-pipe 12000000 DATA framebuffer-con0-type 00080000 DATA framebuffer-con1-enable framebuffer-con1-pipe 12000000 DATA framebuffer-con1-type 00080000 DATA I verified the old bootpack of the (Kaby Lake R / UHD 620) Latitude 7490 I had a few years ago and I had patched HDMI connector con1 that way. Then monitor your framebuffer connectors live in IOReg as you plug and unplug your HDMI cable.

Ok, then you have to experiment with patching of connectors: index, BusID, possibly Pipe and highly likely Flags. Did you try to monitor your iGPU connectors real-time in IOReg as you plug/unplug an HDMI cable? With regards to DVMT, if you try and boot without fbmem and stolenmem patches, do so on a bootable USB Key so that you don't mess out your bootable installation on the SSD. Or vice versa; if you modify the SSD on the EFI partition of your SSD, make sure to have a bootable USB key as backup.

You may find what you seek through basic "Clover versions" and "Hackintool" Google search... Both have their own official repositories which you should fall upon within seconds. Why would you want clover r5157 specifically though? You found my E6230 guide and it provides a copy of Clover r5058 that worked perfectly for Catalina, so... But rest assured that I could still boot Catalina with more recent versions of Clover such as r515x. As for VoodooHDA + AppleHDADisabler kexts, do as you wish: either inject them through Clover's kexts folder or install them in /L/E knowing that latter will require you to set correct permissions to kexts and repair cache. I invite you to consult our old but dedicated thread on the matter in our FAQ section if required. Arguably, caching from /L/E is better. I realise testing can be a little painful but, hey, that's Hackintoshing. Remember that it was never meant to be. You may want to consider a bootable USB key with only Clover on it for testing, that'll save you the hassle of taking your SSD out and back in all the time. Just boot off the USB key, select your maOS partition and off you go.

If you boot without proper graphics settings, you're in what is called VESA mode, i.e. basic graphics without any form of acceleration but system more or less unusable because running slow and lots of graphics defects/glitches. Black screen means that you are getting there but there is another issue along the way. What kind of video output port do you use? VGA, DVI, HDMI?

Does your Latitude 5491 have the nVidia GeForce MX130 dGPU? If so, it's highly likely that HDMI output is actually wired to it and you won't be able to use it under macOS.

Hello, you're using the recommended CFL framebuffer layout for sure. I've noticed 2 things: your IOReg shows MBP15,1 in use, yet your OC config uses MBP15,3 SMBIOS; there is discrepancy here. you patch iGPU fbmem and stolenmem with recommended values but this can occasionally impact HDMI output. If you can patch your BIOS through the documented GRUB process to set DVMT to 64MB (or higher), you could get rid of the fbmem/stolenmem patches. Did you try the igfxonln=1 boot arg? It's sometimes required to get HDMI working alongside the built-in screen. Then, of course, no harm in experimenting patching con1 and/or con2 to HDMI type. Yes, it's usually only required for HDMI audio but, on occasion, it can fix issues with HDMI video issues.

Intel i5-8250U is Kaby Lake R with UHD 620 graphics (iGPU id 0x5917). Looking at your posted IOReg + OC config, your injected graphics settings are incorrect: iGPU id 0x5917 is not natively supported. Please note that injecting hardware's own/native ids is useless and therefore totally unnecessary. Vendor id not to be specified in device id. No such thing as framebuffer layout 0x17590000 (or 0x59170000 which is presumably what you intended to use). Make sure to specify ids in the correct format and byte order; it needs to be from least significant to most significant. 0x80865917 must be entered as 17598680 and 0x59170000 must be entered as 00001759. You need to refer to the KBL/ABL section of the WEG user manual for guidance. You must fake a supported KBL/ABL iGPU id (ideally 0x5916) and call on a valid KBL/ABL framebuffer layout (ideally supported desktop id 0x59120000). In a nutshell, you need to modify your graphics injected as follows: AAPL,ig-platform-id 00001259 DATA device-id 16590000 DATA You may experiment with other desktop values of course; please note that if you do not specify one, the default framebuffer layout id is 0x59160000 and it's a mobile layout (i.e. for laptops). If you're game, you may experiment with laptop values too but this will require you to patch the framebuffer layout (no LVDS/eDP connector on a desktop) and you'll probably have to change your SMBIOS to that of a MacBook too. But I see no reason why desktop settings would not work. KBL framebuffer 0x59120000 defines 3 x DP ports (i.e. connectors). Adjust as required if you have other types of video outputs (eg: DVI, HDMI) 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 Once you've fixed the injected iGPU properties of your OC config, cleared NVRAM at OC picker and rebooted, your IOReg will show you something that will look a bit like this, where your injected values should be reflected (laptop's settings below):