search

acidanthera / bugtracker

Acidanthera Bugtracker
381 stars 43 forks source link

Glitches after set WhateverGreen igfxsklaskbl boot argument #2088

Closed ciccio-90 closed 1 year ago

ciccio-90 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Lorys89 commented 2 years ago

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

describe the glitches encountered

ciccio-90 commented 2 years ago

The screen flickers intermittently.

PMheart commented 2 years ago

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 commented 2 years ago

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

PMheart commented 2 years ago

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

PMheart commented 2 years ago

@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 commented 2 years ago

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

PMheart commented 2 years ago

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 commented 2 years ago

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

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

Lorys89 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

ciccio-90 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Yes, I’m having the same glitches.

abenraj commented 2 years ago

@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:

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 commented 2 years ago

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

PMheart commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

abenraj commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 1 year ago

@\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 commented 1 year ago

@\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 commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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

m0d16l14n1 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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