Glitches after set WhateverGreen igfxsklaskbl boot argument

[ciccio-90]

After that KBL device-id and ig-platform-id and igfxsklaskbl boot arg have been set, the UI shows some glitches.

You can find my EFI folder here:
https://github.com/ciccio-90/Lenovo_V110-15ISK_Hackintosh_OpenCore_macOS_Monterey
MacBook Pro.ioreg.zip

Moreover I attached my IOReg file.

[PMheart]

Hello! This is a known issue. For now no solution is available, unfortunately.

The general suggestion is changing ig-platform-id, but if it does not work, then I have no further ideas to test.

[ciccio-90]

Changing ig-platform-id the situation has not improved.

[Lorys89]

Changing ig-platform-id the situation has not improved.

describe the glitches encountered

[ciccio-90]

The screen flickers intermittently.

[PMheart]

Hello! From your ioreg I saw that you are using our official WhateverGreen 1.6.0 release. While I am still unsure whether 1.6.1 actually helps with anything, please give it a try. You may download the binaries at https://github.com/acidanthera/WhateverGreen/actions/runs/2651164278.

[ciccio-90]

Using WhateverGreen 1.6.1 the situation has improved. Now glitches have shrunk. The screen flickers intermittently much less.

[PMheart]

Thanks for reporting. Yet the problem has not been fully resolved, I will leave the issue opening.

[PMheart]

@ciccio-90 Could you please try another test version at https://github.com/acidanthera/WhateverGreen/actions/runs/2687063664? I am not sure whether it helps, but basically it overrides the VTRating key to SKL settings as well. Thanks @dhinakg for the comparison between SKL and KBL kexts.

UPDATE - If the previous one does not help, please try https://github.com/acidanthera/WhateverGreen/actions/runs/2687133985 too; this one also overrides IOGVAHEVCDecode and IOGVAHEVCEncode to SKL settings.

[ciccio-90]

@PMheart I'm sorry but neither version solves the problem.

[PMheart]

Thanks for reporting. For now I have no further ideas to test!

UPDATE - @ciccio-90 Could you please upload your ioreg again? I am curious about something; maybe I could give something else to test later.

[Lorys89]

@PMheart I'm sorry but neither version solves the problem.

Do you use all data method or normal in the igpu patch?

[Lorys89]

Example for ig platform id 591b0000
framebuffer-con0-alldata 00000800 02000000 98000000
framebuffer-con1-alldata 02040A00 00080000 87010000
framebuffer-con2-alldata 03060A00 00040000 87010000

Obviously if you use this method you will have defined index and busid

[ciccio-90]

@PMheart I'm sorry but neither version solves the problem.

Do you use all data method or normal in the igpu patch?

I use all data because the normal patch did not work.

[ciccio-90]

@Lorys89 You can inspect my config.plist here:
https://github.com/ciccio-90/Lenovo_V110-15ISK_Hackintosh_OpenCore_macOS_Monterey/blob/main/EFI/OC/config.plist

[ciccio-90]

Thanks for reporting. For now I have no further ideas to test!

UPDATE - @ciccio-90 Could you please upload your ioreg again? I am curious about something; maybe I could give something else to test later.

With what version of kext you want that I upload the ioreg?

[PMheart]

Thanks for reporting. For now I have no further ideas to test!
UPDATE - @ciccio-90 Could you please upload your ioreg again? I am curious about something; maybe I could give something else to test later.

With what version of kext you want that I upload the ioreg?

https://github.com/acidanthera/WhateverGreen/actions/runs/2687133985 please.

[PMheart]

Hello! I made another test: https://github.com/acidanthera/WhateverGreen/actions/runs/2696198138 Please attach your ioreg and Lilu dump log.

[ciccio-90]

Thanks for reporting. For now I have no further ideas to test!
UPDATE - @ciccio-90 Could you please upload your ioreg again? I am curious about something; maybe I could give something else to test later.

With what version of kext you want that I upload the ioreg?

https://github.com/acidanthera/WhateverGreen/actions/runs/2687133985 please.

MacBook Pro.ioreg.zip

[ciccio-90]

Hello! I made another test: https://github.com/acidanthera/WhateverGreen/actions/runs/2696198138 Please attach your ioreg and Lilu dump log.

MacBook Pro.ioreg.zip

[PMheart]

Hello! I made another test: https://github.com/acidanthera/WhateverGreen/actions/runs/2696198138 Please attach your ioreg and Lilu dump log.

MacBook Pro.ioreg.zip

Thanks. Looks like all patches are correctly applied. Do you still have glitches now? If so, did it improve anything compared to our 1.6.1 on master?

[ciccio-90]

Yes, I’m having the same glitches.

[abenraj]

@ciccio-90 Hello there! What's the native resolution of laptop display in question? My best guess would be 1366 x 768? If so, then I strongly suspect this factor to be the root cause of these display issues reported when spoofing to KBL. Based off similar reports from users of SKL laptops, it looks like displays with native resolutions below FHD (1080p) seem to exhibit compatibility issues (flickering, no output) when using KBL profiles; especially displays connecting to Port 0 (LVDS).

I tried looking into this further, and from what I could possibly gather, it looks like KBL framebuffer supports up to 19 resolution modes for Port 0 connectors compared to SKL's 30. Details of these modes can be found under property keys IOFBConfig and IOFBDetailedTimings with values formatted as 160-byte structures. I've had no luck with getting to decode these values, but I suppose the structure conforms to display specifications as outlined under Apple's IOGraphicsTypes

Unfortunately I have no access to relevant hardware to further help test above theory, however, the least I could do is suggest possible workarounds:

• Switch resolution to 1920 x 1080 and see if any improvement.
• Patch laptop display EDID to override display profiles/fix monitor ranges. Hackintool can help with this.
• ADVANCED: Modify EDID using an EDID editor and inject via AAPL00,override-no-connect - experimenting with detailed-timings specs (see Detailed Timing Descriptor) should most likely help with compatibility around supported resolutions)
• Upgrade/Switch panel to FHD (not quite the practical option but given the behavior here is an effect of hardware limitation)

I'm also not sure whether it's practical to try and implement a patch for this, from WEG's perspective; since this will most likely require a ton of work + time to test, just to support a niche use-case. @PMheart any thoughts on this?

[PMheart]

To be honest, I have no experience with Intel Graphics myself, so I will unlikely work on this. PR is always welcomed, however.

[PMheart]

@ciccio-90 Would you please help me with another test https://github.com/acidanthera/WhateverGreen/actions/runs/2704490597? This will completely disable HEVC, while I wonder if it helps with the flickering.

[ciccio-90]

@ciccio-90 Hello there! What's the native resolution of laptop display in question? My best guess would be 1366 x 768? If so, then I strongly suspect this factor to be the root cause of these display issues reported when spoofing to KBL. Based off similar reports from users of SKL laptops, it looks like displays with native resolutions below FHD (1080p) seem to exhibit compatibility issues (flickering, no output) when using KBL profiles; especially displays connecting to Port 0 (LVDS).

I tried looking into this further, and from what I could possibly gather, it looks like KBL framebuffer supports up to 19 resolution modes for Port 0 connectors compared to SKL's 30. Details of these modes can be found under property keys IOFBConfig and IOFBDetailedTimings with values formatted as 160-byte structures. I've had no luck with getting to decode these values, but I suppose the structure conforms to display specifications as outlined under Apple's IOGraphicsTypes

Unfortunately I have no access to relevant hardware to further help test above theory, however, the least I could do is suggest possible workarounds:

• Switch resolution to 1920 x 1080 and see if any improvement.
• Patch laptop display EDID to override display profiles/fix monitor ranges. Hackintool can help with this.
• ADVANCED: Modify EDID using an EDID editor and inject via AAPL00,override-no-connect - experimenting with detailed-timings specs (see Detailed Timing Descriptor) should most likely help with compatibility around supported resolutions)
• Upgrade/Switch panel to FHD (not quite the practical option but given the behavior here is an effect of hardware limitation)

I'm also not sure whether it's practical to try and implement a patch for this, from WEG's perspective; since this will most likely require a ton of work + time to test, just to support a niche use-case. @PMheart any thoughts on this?

@abenraj The laptop display resolution is 1366 x 768 but I'm using also an external display which has the resolution equals to 1920x1080 and I'm having the glitches/flickering also on it.

[ciccio-90]

@ciccio-90 Would you please help me with another test https://github.com/acidanthera/WhateverGreen/actions/runs/2704490597? This will completely disable HEVC, while I wonder if it helps with the flickering.

@PMheart I'm sorry but unfortunately also this does not resolve the problem. I'm continuing to have the glitches/flicks.
MacBook Pro.ioreg.zip

[abenraj]

@ciccio-90 Have you tried setting the external monitor as the main display? i.e, without mirroring the built-in laptop display?

Also, just to further confirm the issue: glitches are completely absent when using SKL framebuffer, i.e, without spoofing to KBL, on macOS Monterey, is this correct?

Could you please post an ioreg of system using SKL kexts when booting same macOS volume? Thanks!

One more thing: have you, by any chance, noticed an orange box that flashes for a second around Apple logo, right before boot into macOS?

[ciccio-90]

@abenraj Yes, I tried etting the external monitor as the main display without mirroring the built-in laptop display and the glitches/flicks are most intensive. Moreover I confirm that glitches are completely absent when using SKL framebuffer without spoofing to KBL on macOS Monterey and that there is no orange box that flashes for a second around Apple logo right before boot into macOS. I will post the ioreg tomorrow or Saturday because I'm not at my Laptop now.

[ciccio-90]

@abenraj The following is the ioreg of system using SKL kexts.
MacBook Pro.ioreg.zip

[abenraj]

@ciccio-90 Thanks! Could you please try testing this build: https://github.com/abenraj/WhateverGreen/actions/runs/2722939169? Not sure if it helps, but if no dice still, then I'm afraid I'm out of ideas to offer, for the moment.

[ciccio-90]

@ciccio-90 Thanks! Could you please try testing this build: https://github.com/abenraj/WhateverGreen/actions/runs/2722939169? Not sure if it helps, but if no dice still, then I'm afraid I'm out of ideas to offer, for the moment.

@abenraj I'm sorry but also using this build I'm having the same glitches.
MacBook Pro.ioreg.zip

[ciccio-90]

I want to add that using the latest official version of the kext (WhateverGreen 1.6.1), the glitches only occur when the laptop is connected to the external monitor via HDMI cable.

MacBook Pro.ioreg.zip

[null2264]

@\ciccio-90 Hello there! What's the native resolution of laptop display in question? My best guess would be 1366 x 768? If so, then I strongly suspect this factor to be the root cause of these display issues reported when spoofing to KBL. Based off similar reports from users of SKL laptops, it looks like displays with native resolutions below FHD (1080p) seem to exhibit compatibility issues (flickering, no output) when using KBL profiles; especially displays connecting to Port 0 (LVDS).

I tried looking into this further, and from what I could possibly gather, it looks like KBL framebuffer supports up to 19 resolution modes for Port 0 connectors compared to SKL's 30. Details of these modes can be found under property keys IOFBConfig and IOFBDetailedTimings with values formatted as 160-byte structures. I've had no luck with getting to decode these values, but I suppose the structure conforms to display specifications as outlined under Apple's IOGraphicsTypes

Unfortunately I have no access to relevant hardware to further help test above theory, however, the least I could do is suggest possible workarounds:

* Switch resolution to 1920 x 1080 and see if any improvement.

* Patch laptop display EDID to override display profiles/fix monitor ranges. Hackintool can help with this.

* **ADVANCED**: Modify EDID using an EDID editor and inject via `AAPL00,override-no-connect` - experimenting with detailed-timings specs (see [Detailed Timing Descriptor](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data)) _should_ most likely help with compatibility around supported resolutions)

* Upgrade/Switch panel to FHD (not quite the practical option but given the behavior here is an effect of hardware limitation)

I'm also not sure whether it's practical to try and implement a patch for this, from WEG's perspective; since this will most likely require a ton of work + time to test, just to support a niche use-case. @\PMheart any thoughts on this?

Patching EDID with Monitor Ranges Fix from Hackintool actually fixed it for me (or at least reduced those glitches by a lot, it only comes back after waking up from sleep).

[rudironsonijr]

@\ciccio-90 Hello there! What's the native resolution of laptop display in question? My best guess would be 1366 x 768? If so, then I strongly suspect this factor to be the root cause of these display issues reported when spoofing to KBL. Based off similar reports from users of SKL laptops, it looks like displays with native resolutions below FHD (1080p) seem to exhibit compatibility issues (flickering, no output) when using KBL profiles; especially displays connecting to Port 0 (LVDS).
I tried looking into this further, and from what I could possibly gather, it looks like KBL framebuffer supports up to 19 resolution modes for Port 0 connectors compared to SKL's 30. Details of these modes can be found under property keys IOFBConfig and IOFBDetailedTimings with values formatted as 160-byte structures. I've had no luck with getting to decode these values, but I suppose the structure conforms to display specifications as outlined under Apple's IOGraphicsTypes
Unfortunately I have no access to relevant hardware to further help test above theory, however, the least I could do is suggest possible workarounds:

* Switch resolution to 1920 x 1080 and see if any improvement.

* Patch laptop display EDID to override display profiles/fix monitor ranges. Hackintool can help with this.

* **ADVANCED**: Modify EDID using an EDID editor and inject via `AAPL00,override-no-connect` - experimenting with detailed-timings specs (see [Detailed Timing Descriptor](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data)) _should_ most likely help with compatibility around supported resolutions)

* Upgrade/Switch panel to FHD (not quite the practical option but given the behavior here is an effect of hardware limitation)

I'm also not sure whether it's practical to try and implement a patch for this, from WEG's perspective; since this will most likely require a ton of work + time to test, just to support a niche use-case. @\PMheart any thoughts on this?

Patching EDID with Monitor Ranges Fix from Hackintool actually fixed it for me (or at least reduced those glitches by a lot, it only comes back after waking up from sleep).

I'm facing the same issue.
These glitches are only happening after my Dell XPS 9350 (Intel HD 520) wake up from sleep/hibernation.

I'm running Ventura.

[andreszerocross]

I am using Lenovo Thinkpad X270 with Skylake Processor. But i didn't face this issue in ventura.

My processor is Intel Core i5 6300U + Internal Display is 1366 x 768.

Cold Boot and Warmboot = No glitch
External display plugged = No Glitch
Wake from Sleep without external monitor = no Glitch
Wake from sleep with external monitor = No Glitch.

Just for information

[null2264]

I'm not entirely sure, but adding AAPL,GfxYTile (with the value 01 00 00 00) property somehow fixes it entirely even after waking up from sleep/hibernation (I even test rendering a video with Fusion on DaVinci Resolve, since that's where I get a lot of glitches before). I'll try to keep this reply up-to-date with new findings I get while using it for work.

My setup: Lenovo Thinkpad L460 (i5-6300U, HD 520) - 1920x1080

EDIT: From my testing, the glitches only came back when:

• [17 Jan 2023]: HiDPI is used (Even if it's 1080, still refuses to work)
• [20 Jan 2023 / 13 Feb 2023]: An external monitor is connected (probably because the (native) resolution is lower than 1920x1080, I don't have a monitor with 1080 resolution so I couldn't test it further)
• [13 Feb 2023]: Resolution is set lower than native resolution

---

Unrelated, but may help you decide whether you want to stay in Monterey or not: Spoofing to KBL may cause colour banding, which happened to some KBL devices for some reason (the only solution I found is to spoof KBL to SKL, which is obviously not an option), it could also be the monitor's limitation. You could check if it's your monitor's limitation if you still have Windows (On-the-go probably works) by going to Advanced display settings, if color depth says 6-bit then that's probably why.

[ciccio-90]

I'm not entirely sure, but adding AAPL,GfxYTile somehow fixes it entirely (at least for now) even after waking up from sleep/hibernation (I even test rendering a video with Fusion on DaVinci Resolve, since that's where I get a lot of glitches before). I haven't tested it thoroughly, but I'll comment again if the glitches come back.

My setup: Lenovo Thinkpad L460 (i5-6300U, HD 530) - 1920x1080

Amazing! That property works perfectly also for me!

[PMheart]

For the value of AAPL,GfxYTile, is 1 (Number) injected here? If so, I can integrate this in WEG. Thanks!

[m0d16l14n1]

For the value of AAPL,GfxYTile, is 1 (Number) injected here? If so, I can integrate this in WEG. Thanks!

yes, in Ice Lake iGPU we had the same glitching issues, if we use HiDPi settings and some other stuff.

[rudironsonijr]

For the value of AAPL,GfxYTile, is 1 (Number) injected here? If so, I can integrate this in WEG. Thanks!

Hi, @PMheart! Thank you for your attention here!
I'm using it as Data instead of a Number:

<key>AAPL,GfxYTile</key>
<data>
AQAAAA==
</data>

I know that "AQAAAA==" is the same as "01 00 00 00", just wanted to let you know.
And, by the way, this solved the graphical glitches I was facing after sleep/hibernation.

[PMheart]

Thanks for the info. I am not sure if we should handle this automatically for SKL now, to be honest. Since the other generations also need this (manually), there is a good reason not to add it.

UPDATE: It is probably better to leave the current code as is, and add the property manually for all generations. I will mention this in the doc, but at least we have finally found a workaround.

[rudironsonijr]

Thanks for the info. I am not sure if we should handle this automatically for SKL now, to be honest. Since the other generations also need this (manually), there is a good reason not to add it.

UPDATE: It is probably better to leave the current code as is, and add the property manually for all generations. I will mention this in the doc, but at least we have finally found a workaround.

@PMheart, this link will be of interest to you:
https://pikeralpha.wordpress.com/2016/10/30/aapl-properties-for-skylake-graphics/

[PMheart]

Thanks. Actually I found the same post, and realized that this property was not exclusive to SKL. I added the notes instead.