Jump to content

Intel HD4600 banding/gradient/16-bit colors issue Y510p


Go to solution Solved by vusun123,
130 posts in this topic

Recommended Posts

@intruder16
 

There is one thing that gets broken when this glitch appears, the restart functionality. Meaning, after restart the screen stays blank with cpu, fans etc still running. Not even the BIOS (pre-boot logo) shows up (coz of which i think it's a serious issue).


Actually, I found there is not a problem with the restart functionality. Previously we thought -- at least I did -- that the laptop would halt once we go for display off/on sequence and choose to reboot with the symptoms you mentioned. However, the reboot process works as usual but the graphics does not work correctly. I made myself sure of that using couple of simple procedures:

  • Boot OS X
  • Reproduce the graphics issue (set display off then on)
  • Restart, wait for a few moments (that are usually enough to get you in Clover again)
  • Use keyboard to choose and boot into Windows
  • Wait a few moments (that are usually enough to get logged into Windows desktop)
  • Use keyboard keystrokes that would shut down the PC (or actually make any feedback like logging a text file)
  • Windows will shutdown (or the feedback text file will be created)

Another thing I tried, which is interesting BTW:

  • Boot OS X, set the system to auto login, and set one of the hot corners to perform display sleep.
  • Reproduce the graphics issue (set display off then on)
  • Restart, wait for a few moments (that are usually enough to get you in Clover again)
  • Use keyboard to choose and boot into OS X
  • Wait a few moments (that are usually enough to get logged into OS X desktop)
  • Move the mouse cursor to the predefined corner then move it away
  • Display will wake up and you have a usable desktop as usual (but of course with the gradients as expected)

So basically no problem with restart itself after graphic re-initialization but the problem is with the wrongly configured graphics and how to display while restarting. Therefore, I believe if we are able to force OS X to initialize (and be able to re-initialize) the graphics in the correct way, the graphics data will be handled correctly across OS's and POST too. Currently, only the graphics is the problem.

While I was searching around I came across these slides of AMD presentation on graphics with UEFI, and I quote that to allow dual boot (booting in UEFI or Legacy):
 
The industry needs to provide both legacy VGA BIOS and GOP for a transition period.

 

And of course this is the case and Intel provides both since Windows works flawlessly in either mode. However, the problem is to find the driver for OS X that can work with both. Especially since there is one major disadvantage of using Graphics Output Protocol (GOP) with UEFI:

 

OS or OS applications lose capability of changing display resolution and configuration if OS high performance display driver is not installed or functional.

 

In light of this, I strongly think the problem is with the the driver and nothing to do with anything else. The following is a diagram summarising the problem and I hope it make the whole situation clearer:

 

graphics.png

 

For now, Mobile HD4600 works in Yosemite disguised as Desktop HD4600. We need to check if people with actual Desktop HD4600 are having the same issue or not. If so, then Desktop HD4600 is not fully supported out of the box as thought of. Otherwise, Mobile HD4600 may need some more work (on driver) than just dressing it like its Desktop brother.

 

Just my two cents ...

  • Solution

If you haven't solve the 16bits color problem yet, EDID edit might save you here. Comparision between a real Mac's EDID and many laptops shows that common laptops's EDID version is 0103 or lower, while real Mac uses 0104. Also the 1st value of basic param on real Mac is 90, while on common laptops are 80. Try edit those out, and recalculate the checksum. Fix yellow gradient issues on laptops with AMD GPUs and Nvidia GPUs's 16bit color issue, like this one

If you haven't solve the 16bits color problem yet, EDID edit might save you here. Comparision between a real Mac's EDID and many laptops shows that common laptops's EDID version is 0103 or lower, while real Mac uses 0104. Also the 1st value of basic param on real Mac is 90, while on common laptops are 80. Try edit those out, and recalculate the checksum. Fix yellow gradient issues on laptops with AMD GPUs and Nvidia GPUs's 16bit color issue, like this one

 

Thanks for this. Although the OP stated he tried custom EDID and I was about to say that it is tried and proven not to work. however, I thought to give it a try myself and it worked like a charm and the gradients are all gone now.

 

With that said, still there is a problem with driver I guess. The re-initialized graphics after display off/on are still not correct and render BIOS without display after restart.

 

But this a good advance I must say, thanks!

Thanks for this. Although the OP stated he tried custom EDID and I was about to say that it is tried and proven not to work. however, I thought to give it a try myself and it worked like a charm and the gradients are all gone now.

 

With that said, still there is a problem with driver I guess. The re-initialized graphics after display off/on are still not correct and render BIOS without display after restart.

 

But this a good advance I must say, thanks!

Glad to hear it work. Hope OP update the 1st post

Glad to hear it work. Hope OP update the 1st post

 

Yea really thanks. I sent him a PM, he is away for sometime I believe. 

 

Anyway, I see that custom EDID fixed one of the registers related to 16-bit color behaviour. The register PIPE_DDI_FUNC_CTL_EDP used to change from 0x82000002 (this is normal colours) to 0x82200002 (this appears as 16-bit colours) once display is set off then on (and driver initialise). Now that register does not change upon driver re-initialisation which is good. There are other registers that still does change though and I think they are related and I will start investigating them. Any more tricks you know about? Thanks.

Yea really thanks. I sent him a PM, he is away for sometime I believe. 

 

Anyway, I see that custom EDID fixed one of the registers related to 16-bit color behaviour. The register PIPE_DDI_FUNC_CTL_EDP used to change from 0x82000002 (this is normal colours) to 0x82200002 (this appears as 16-bit colours) once display is set off then on (and driver initialise). Now that register does not change upon driver re-initialisation which is good. There are other registers that still does change though and I think they are related and I will start investigating them. Any more tricks you know about? Thanks.

 

Oh wow, I'll have to give this a shot. Thanks for all the work, ahmed, and for the EDID suggestion vusun.

 

So if I'm understanding, the EDID injection will solve the gradients problem, but upon reboot what happens?

First of all, sorry for being away for so long. Now onto topic.

 

@vusun123,

 

I did try custom EDID injection before but didn't notice anything. More specifically here. Maybe i was just looking for the end result i.e. 16-bit color fix.

 

@ahmed_ais,

 

Great Work!

 

Did you set the basic parameters frm 80 -> 90 and recalculated checksum? Anything else you changed? I'll try to reproduce it.

 

EDIT : My source : here.

@intruder16

 

Using a custom EDID fixed the value of the register PIPE_DDI_FUNC_CTL_EDP and it does not change its value after display off/on. This resulted in fixing the 16-bit colour problem. The customisations made are based on vusun123 advice:
  • Change EDID version from 0103 to 0104
  • Change first value of basic param from 80 to 90
  • Fixing EDID checksum (last value from 7d to 6c)
 
The custom EDID is converted to Base64 and injected in Clover so this have to be added to Graphics section.
<key>Graphics</key>
<dict>
<key>InjectEDID</key>
<true/>
<key>CustomEDID</key>
<data>
AP///////wAw5BYEAAAAAAAXAQSQIxN4ChXVnllQmCYOUFQAAAABAQEBAQEB
AQEBAQEBAQEBGjaAoHA4H0AwIDUAWcIQAAAZAAAAAAAAAAAAAAAAAAAAAAAA
AAAA/gBMRyBEaXNwbGF5CiAgAAAA/gBMUDE1NldGMS1UTEMyAGw=
</data>


.. .. .. .. .. 
</dict>

 

 

EDIT:

 

This fixed the 16-bit color issue so now changing resolutions, connecting external display, display sleep, system sleep, are all hypothetically works in acceptable mode. The restart functionality is working as I previously found although without display as there are more to be fixed. However, I believe we can skip restart and go for shutdown for the time being until we know for sure what is the problem with the driver.

If you haven't solve the 16bits color problem yet, EDID edit might save you here. Comparision between a real Mac's EDID and many laptops shows that common laptops's EDID version is 0103 or lower, while real Mac uses 0104. Also the 1st value of basic param on real Mac is 90, while on common laptops are 80. Try edit those out, and recalculate the checksum. Fix yellow gradient issues on laptops with AMD GPUs and Nvidia GPUs's 16bit color issue, like this one

 

Funny...

 

I have this in my hackintosh notes...

 

investigate:

 

changing Basic Param in EDID from 90 to 80 to fix gradient issues?

Funny...

 

I have this in my hackintosh notes...

 

 

Yea and I followed a conversation between you, intruder16, and the-darkvoid on the other forum and this fix was suggested. However, I think changing Basic Param in EDID alone was not enough here, I also changed EDID version to 0104. (I assumed it was not enough as I read that the OP already tried changing Basic Param only and it did not work).

 

BTW, when I edited my EDID I changed from 80 to 90 not the other way around.

 

Thanks for your help

I think I used the wrong checksum, I need to fix that ... I hope it does not affect anything!

EDIT1: even the native EDID has invalid checksum according to http://www.edidreader.com/

 

EDIT2: It turn out the mentioned website is buggy and the checksum is correct actually. I checked with this script https://github.com/mochikun/EDID_checksum after converting the code to work with text file instead of binary and the checksum matched. All good!

Oh wow, I'll have to give this a shot. Thanks for all the work, ahmed, and for the EDID suggestion vusun.

I believe you have G510 right? If so, I advice you to extract your own EDID and customise it as in post #84. This because I am not sure Y510p and G510 displays are having the same EDID.

Holy fcking {censored} !!!! It fcking worked !!!!

 

Can't believe it ! No more 16-bit {censored} !

 

@RehabMan,

 

All we had to do is change EDID version from 1.3 to 1.4 and basic parameter from 80 to 90 and fix the checksum. We did all that before except changing EDID version.

 

@vusun123,

 

Thanks a lot for the heads up mate! 

 

@ahmed_ais,

 

Thanks for all the hard work. Great!

 

 

I don't know how i overlooked this crucial info, but in my source of info linked in post #83, he also changed the EDID version. I tried without this.

 

 

Anyway, thanks all very very much. Time for me to update OP.


@mattcurtis,

 

Please try the suggestions as @ahmed_ais suggested. I'm sure it'll work. If any problems post here.

Holy fcking {censored} !!!! It fcking worked !!!!

 

Can't believe it ! No more 16-bit {censored} !

 

@RehabMan,

 

All we had to do is change EDID version from 1.3 to 1.4 and basic parameter from 80 to 90 and fix the checksum. We did all that before except changing EDID version.

 

@vusun123,

 

Thanks a lot for the heads up mate! 

 

@ahmed_ais,

 

Thanks for all the hard work. Great!

 

 

I don't know how i overlooked this crucial info, but in my source of info linked in post #83, he also changed the EDID version. I tried without this.

 

 

Anyway, thanks all very very much. Time for me to update OP.

@mattcurtis,

 

Please try the suggestions as @ahmed_ais suggested. I'm sure it'll work. If any problems post here.

Glad that worked out mate

@Rehabman change both EDID version and basic param, and you are writing the fix in the wrong order

Glad that worked out mate

@Rehabman change both EDID version and basic param, and you are writing the fix in the wrong order

I'll add it to my notes. But since I don't have this issue on any of my machines, I never investigated further.

 

I suppose 80->90 or 90->80 depends on what you find in your existing EDID.

 

My notes now read:

investigate:

 

changing Basic Param in EDID from 90 to 80 to fix gradient issues?

or changing Basic Param in EDID from 80 to 90?

Depends on what you find in your native EDID?

 

also update version from 1.3 to 1.4.

I'll add it to my notes. But since I don't have this issue on any of my machines, I never investigated further.

 

I suppose 80->90 or 90->80 depends on what you find in your existing EDID.

 

My notes now read:

That would be 80 to 90, since 90 is from real Macs. But trust me on that one

That would be 80 to 90, since 90 is from real Macs. But trust me on that one

I'll leave my notes as-is. Obviously, if you already have one value it can't hurt to try the other one (hackintosh requires using your brain)...

 

What would be neat here is a DSDT patch that could automatically inject the modified EDID. I did a little bit of work on it in the past, but haven't found a reliable way to retrieve the panel EDID from DSDT code at _INI. I'm sure it is possible though, but will require more reading of the PRMs.

....What would be neat here is a DSDT patch that could automatically inject the modified EDID. I did a little bit of work on it in the past, but haven't found a reliable way to retrieve the panel EDID from DSDT code at _INI. I'm sure it is possible though, but will require more reading of the PRMs.

 

That would be great indeed!

Holy fcking {censored} !!!! It fcking worked !!!!

 

Can't believe it ! No more 16-bit {censored} !

 

 

@ahmed_ais,

 

Thanks for all the hard work. Great!

 

 

I don't know how i overlooked this crucial info, but in my source of info linked in post #83, he also changed the EDID version. I tried without this.

 

 

Anyway, thanks all very very much. Time for me to update OP.

 

...

LOOL .. yeah it feels so good without that $hit!

 

Thanks for your words, everyone did his best.

 

That said, I think you should also edit this part of the OP:

There is one thing that gets broken when this glitch appears, the restart functionality. Meaning, after restart the screen stays blank with cpu, fans etc still running. Not even the BIOS (pre-boot logo) shows up (coz of which i think it's a serious issue).

 

Because as I mentioned earlier, the restart functionality is all fine but with no display. This is related to another graphics driver issue that is yet to be fixed if someone is interested. I would prefer if you remove this part all together so we can start a new thread dedicated for that issue only using the diagram I made in post #77 for example. 

Sure. I'll do it right away.

 

EDIT: Done.

 

Good. And just for the record I want to add this:

 

Once display is set OFF then ON and something change in IGPU memory. Upon restart in this case the system loses the display until further instruction but proceeds from POST to Clover in darkness.

  1. If we blindly choose OS X and hit Enter, we can get the display back on with ease. By pressing Fn+F2 to turn off display via hardware then pressing them again (immediately) the display will return.
  2. If we blindly choose Windows and hit Enter, we can get the display back on with ease too. Once Windows is loaded in the dark, pressing Fn+F1 will set Windows to sleep, then pressing any key will wake up the machine and display will be back on.

These are just some workarounds but of course the problem have to be solved from the root.

×
×
  • Create New...