Jump to content

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

intruder16

By intruder16,
in General Discussion

 Share
130 posts in this topic

Recommended Posts

intruder16
intruder16
Posted
Posted

[sOLVED] - Look at the end of this post for solution.

 

Hi all,

 

I have a Lenovo IdeaPad Y510p with Intel HD 4600 graphics as shown in my signature. Now, as the title says, I am having issue with my graphics. When i put the display to sleep or do anything that switches display off, like, changing resolution, putting display / system to sleep etc., after waking up it seems like there are 16-bit colours instead of normal 32-bit.

 

Pardon the low quality capture of the glitch, as I was not able to capture the details in my {censored} camera. Anyway, this is how the bands/gradients/16-bit colours look :

 

gkvxhCe.jpg

 

These are not exactly like 16-bit but they do seem like it in translucent areas (like launchpad, notification center), shadows, desktop wallpaper etc. Again, it only happens after turning display off then on.

 

Also, just for the record, I do have QE/CI, and everything else like Power Management, Sleep, etc working perfectly.

 

Other posts about same issue:

 

It seems like those having Lenovo Y510p and Y410p are suffering from these problems, also a guy having an Asus K550JK, all of them having same IGPU HD4600 of course. You can see the posts linked below regarding this issue :

 

Y510p reference here (under "Not Working" section)

Asus K550JK reference here.

Y410p reference here.

I also made some posts regarding this issue in a thread dedicated to "Fixing IGPU"  here and here.

 

Things i've tried so far :

  • different ig-platform-id's with patched framebuffer data.
  • changing DVMT pre-alloc memory in BIOS and patching framebuffer to match.
  • custom EDID Injection

and all of them didn't help.

 

Now, i have dumped the Intel Registers in both Linux and Mac. I've been trying for hours to make sense of them but i couldn't right now (but I'm trying hard). I'd appreciate it very much if somebody would take a look.

 

Attached is the whole folder containing dumps before and after system sleep (and display sleep too) in both Linux and Mac.

 

 

I could not find any solution for this issue, and if anybody has this issue or solved it or any ideas, please post here. It would be great to hear from you guys. Thanks in advance.

 
=======
Solution :
=======
 
Thanks to @RehabMan and @vusun123 for their suggestions coz of which the issue is fixed. @ahmed_ais, thanks for the hard work mate. You are making OS X experience in Y510p more awesome day by day.
 
Also, thanks to all i forgot to add for their contribution and suggestions.
 
So it turns out the solution is actually an easy one. The EDID info needed to be customised for proper functioning of the display. Specifically:
  • Change EDID version from 1.3 to 1.4
  • Change basic parameter from 80 -> 90
  • Fix the checksum

 

Original EDID from Darwin Dumper:


header:          00 ff ff ff ff ff ff 00
serial number:   30 e4 16 04 00 00 00 00 00 17
version:         01 03
basic params:    80 23 13 78 0a
chroma info:     15 d5 9e 59 50 98 26 0e 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    1a 36 80 a0 70 38 1f 40 30 20 35 00 59 c2 10 00 00 19
descriptor 2:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3:    00 00 00 fe 00 4c 47 20 44 69 73 70 6c 61 79 0a 20 20
descriptor 4:    00 00 00 fe 00 4c 50 31 35 36 57 46 31 2d 54 4c 43 32
extensions:      00
checksum:        7d

Modified EDID:

header:          00 ff ff ff ff ff ff 00
serial number:   30 e4 16 04 00 00 00 00 00 17
version:         01 04
basic params:    90 23 13 78 0a
chroma info:     15 d5 9e 59 50 98 26 0e 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    1a 36 80 a0 70 38 1f 40 30 20 35 00 59 c2 10 00 00 19
descriptor 2:    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
descriptor 3:    00 00 00 fe 00 4c 47 20 44 69 73 70 6c 61 79 0a 20 20
descriptor 4:    00 00 00 fe 00 4c 50 31 35 36 57 46 31 2d 54 4c 43 32
extensions:      00
checksum:        6c

As you can see, the changes are in "version:" from 03 to 04, "basic params:" from 80 to 90 and the calculated checksum from 7D to 6C which might be different for you.

 

 

Source if you need it.

Intel Reg Dumps.zip

Intruder’s MacBook Pro.ioreg.zip

config.plist.zip

  • Like 3
eplightning
eplightning
Posted
Posted

Was looking into disassembled AppleIntelFramebufferAzul.kext trying to find some way to fix that PIPE_DDI_FUNC_CTL_EDP register value. Here's my first try if someone is brave enough to try that patch:

<dict>
    <key>Name</key>
    <string>AppleIntelFramebufferAzul</string>
    <key>Comment</key>
    <string>First try</string>
    <key>Find</key>
    <string>488b8b98000000ba00000080</string>
    <key>Replace</key>
    <string>488b8b98000000ba00002080</string>
</dict>

What this does is replacing single instruction in AppleIntelAzulController::hwSetPanelFitter(AppleIntelFramebuffer *, DISPLAYPATH *)

00000000001A42A                 mov     edx, 80000000h
with
00000000001A42A                 mov     edx, 80200000h
ahmed_ais
ahmed_ais
Posted
Posted

 

Was looking into disassembled AppleIntelFramebufferAzul.kext trying to find some way to fix that PIPE_DDI_FUNC_CTL_EDP register value. Here's my first try if someone is brave enough to try that patch:

 

Thanks for giving time on this. I gave it a try but nothing changed visually so nothing to report yet. Unless you expect other form of information then let me know what you are after so i can report back.

eplightning
eplightning
Posted
Posted

Thanks for giving time on this. I gave it a try but nothing changed visually so nothing to report yet. Unless you expect other form of information then let me know what you are after so i can report back.

I would need GPU registers dump (like in the OP) to see if there are any changes. But if nothing changed then I'll probably need to look somewhere else.

ahmed_ais
ahmed_ais
Posted
Posted

I tried that patch. Did not work as expected. No change in registers. Attached the dump.

 

I found you are using AICPUPMI v1.0 but cannot find this anywhere. I also gave version 3.3 a try but it does not dump registers as supposed to .. is there any trick here?

intruder16
intruder16
Posted
  • Author
Posted

I found you are using AICPUPMI v1.0 but cannot find this anywhere. I also gave version 3.3 a try but it does not dump registers as supposed to .. is there any trick here?

 

Oh no no. I am using "AppleIntelInfo" by Pike R Alpha. By version 3.3 i think you mean "AppleIntelCPUPowerManagement.kext" which is not useful here (cannot dump intel registers). 

 

You can find the git of AppleIntelInfo here. Just need to compile it afterwards. Load the kext on demand (sudo kextload) and it will dump the registers.

ahmed_ais
ahmed_ais
Posted
Posted

Oh no no. I am using "AppleIntelInfo" by Pike R Alpha. By version 3.3 i think you mean "AppleIntelCPUPowerManagement.kext" which is not useful here (cannot dump intel registers). 

 

You can find the git of AppleIntelInfo here. Just need to compile it afterwards. Load the kext on demand (sudo kextload) and it will dump the registers.

 

Oh sorry I forgot to mention I downloaded AppleIntelInfo and built it. But I did not load it on demand as you said instead used it as normal kext and unfortunately it did not show all the info like yours. I will try loading on demand instead. I'm not sure though why do you have AICPUPMI v1.0 in your log because this is related to AppleIntelCPUPowerManagementInfo.kext as you said.

eplightning
eplightning
Posted
Posted

Here's another attempt at patching that register:

<dict>
    <key>Name</key>
    <string>AppleIntelFramebufferAzul</string>
    <key>Comment</key>
    <string>Second try</string>
    <key>Find</key>
    <string>0600498b85980000008b4010</string>
    <key>Replace</key>
    <string>0600b8020020829090909090</string>
</dict>

This time it's hardcoding register value in AppleIntelAzulController::EnablePipe(AppleIntelFramebuffer *, DISPLAYPATH *) method

 

Edit: updated, not sure if clover requires hex strings to be lowercase, but just in case

intruder16
intruder16
Posted
  • Author
Posted

Here's another attempt at patching that register:

 

Edit: updated, not sure if clover requires hex strings to be lowercase, but just in case

 

Still didn't work. Something happened though. Unfortuntely, display didn't come back on. It stayed blank after i put it to sleep.

 

About the clover hex strings, both lower and upper case is fine. Hex strings are needed while using Clover Configurator (which btw i don't use) which in turn converts it to base64. base64 format is needed in config.plist.

 

EDIT: attached dump before putting display to sleep.

Before_Sleep_2nd_Try.txt.zip

eplightning
eplightning
Posted
Posted

Still didn't work. Something happened though. Unfortuntely, display didn't come back on. It stayed blank after i put it to sleep.

 

About the clover hex strings, both lower and upper case is fine. Hex strings are needed while using Clover Configurator (which btw i don't use) which in turn converts it to base64. base64 format is needed in config.plist.

 

EDIT: attached dump before putting display to sleep.

 

Hmm, could you try if this one doesn't break sleep:

<dict>
    <key>Name</key>
    <string>AppleIntelFramebufferAzul</string>
    <key>Comment</key>
    <string>Second try</string>
    <key>Find</key>
    <string>0600498b85980000008b4010</string>
    <key>Replace</key>
    <string>0600b8020000829090909090</string>
</dict>
intruder16
intruder16
Posted
  • Author
Posted

Yep I know it wouldn't work but just wanted to confirm it for sure (for all I know it might have been mistake in my assembly).

 

Looks like we'll need to look into other registers.

 

I still don't know which register would cause the issue. What do you think?

 

Is there any way to debug more (IGDebug for example) and possibly pin-point the source of problem?

Oh sorry I forgot to mention I downloaded AppleIntelInfo and built it. But I did not load it on demand as you said instead used it as normal kext and unfortunately it did not show all the info like yours. I will try loading on demand instead. I'm not sure though why do you have AICPUPMI v1.0 in your log because this is related to AppleIntelCPUPowerManagementInfo.kext as you said.

 

You'll also need Xcode 6.1 beta or greater to build.

brutalMac
brutalMac
Posted
Posted

I have this problem too on my y510p. And it affects only mobile HD4600 version. I've done hackintosh on my work desktop pc recently. It has desktop Haswell processor with HD 4600. And it works perfect with the same clover injects and patches. Fluent gradients after and before sleep. Apple did some tricks with mobile chips in kexts i guess.

  • Like 1
intruder16
intruder16
Posted
  • Author
Posted

.... Apple did some tricks with mobile chips in kexts i guess.

 

No tricks. Apple doesn't make any Mac's with mobile HD4600 gpu. So there's no support obviously. We hacked the kext to make our mobile HD4600 (0x04168086) look like a desktop one. That's why the clover/dsdt patch to inject FakeID of 0x04128086 which is for HD4600 on desktops.

I have this problem too on my y510p. And it affects only mobile HD4600 version...

 

Only our (y510p's) HD4600 unfortunately.

eplightning
eplightning
Posted
Posted

I still don't know which register would cause the issue. What do you think?

 

Is there any way to debug more (IGDebug for example) and possibly pin-point the source of problem?

 

I'm not sure, but I think it has something to do with the bpp hack present in Linux i915 driver (linked in Y510p) thread which is obviously not present in OSX. Currently I'm trying to find correct place to fix this in framebuffer driver, which is not that easy (still need more experience with x86_64 assembler code :( ).

 

Here's another try (2 patches this time): should force bpp to be detected as 6

<dict>
    <key>Name</key>
    <string>AppleIntelFramebufferAzul</string>
    <key>Comment</key>
    <string>Take Three - Patch #1</string>
    <key>Find</key>
    <string>BE18000000EB643D00000100</string>
    <key>Replace</key>
    <string>BE18000000EB073D00000100</string>
</dict>

<dict>
    <key>Name</key>
    <string>AppleIntelFramebufferAzul</string>
    <key>Comment</key>
    <string>Take Three - Patch #2</string>
    <key>Find</key>
    <string>0000180000001E0000001200000024000000F1FCF6FB</string>
    <key>Replace</key>
    <string>0000120000001E0000001200000024000000F1FCF6FB</string>
</dict>
ahmed_ais
ahmed_ais
Posted
Posted

Hi, I tested your latest patches (third try). Unfortunately still no change: 6 bpc before display off and 8 bpc after display on.

 

Dumps are attached, thanks for your attempts.

IGPU Dumps (Third Try).zip

intruder16
intruder16
Posted
  • Author
Posted

 

I'm not sure, but I think it has something to do with the bpp hack present in Linux i915 driver (linked in Y510p) thread which is obviously not present in OSX. Currently I'm trying to find correct place to fix this in framebuffer driver, which is not that easy (still need more experience with x86_64 assembler code :( ).

 

Here's another try (2 patches this time): should force bpp to be detected as 6....

 

That's not a valid patch.

 

The "Find" strings in both patches are not present in AppleIntelFramebufferAzul binary.

ahmed_ais
ahmed_ais
Posted
Posted

That's not a valid patch.

 

The "Find" strings in both patches are not present in AppleIntelFramebufferAzul binary.

 

Correct. I didn't even check. Also these patches are still in HEX right? I don't think this is Base64.

Edit: @intruder16 I find your dumps have higher value for IGPU Current Frequency than mine (750 vs 550). Do you know why is that? same graphic card and same driver so I think it is a bit weird.

intruder16
intruder16
Posted
  • Author
Posted

....Also these patches are still in HEX right? I don't think this is Base64.

 

Right.

 

...Edit: @intruder16 I find your dumps have higher value for IGPU Current Frequency than mine (750 vs 550). Do you know why is that? same graphic card and same driver so I think it is a bit weird.

 

That's "Current Freq". It might be different due to speedstep. Check if you are generating enough P-states for IGPU. Keep in mind, it might take a lot of time to show them all.

ahmed_ais
ahmed_ais
Posted
Posted

Edit2: The IGPU Current Frequency doesn't even seem to change anytime although it is supposed to vary between 200-1150 (in Turbo)

AICPUPMI: IGPU Current Frequency.............:  550 MHz
AICPUPMI: IGPU Minimum Frequency.............:  200 MHz
AICPUPMI: IGPU Maximum Non-Turbo Frequency...:  400 MHz
AICPUPMI: IGPU Maximum Turbo Frequency.......: 1150 MHz
AICPUPMI: IGPU Maximum limit.................: No Limit

 

Check yours now and I guess you will still have 750 MHz (fixed) no matter P-states of IGPU.

ahmed_ais
ahmed_ais
Posted
Posted

Okay .. I take all these back! ... I stressed the graphics and it changed finally to max 1150 MHz ... 


Try running OpenCL benchmark tools like Cinebench.

 

Yea I just ran some HTML5 graphics tests in browser and the frequency bumped up ..

 Share
Go to topic listing
×
×
  • Create New...