Jump to content
intruder16

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

130 posts in this topic

Recommended Posts

[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

Share this post


Link to post
Share on other sites
Advertisement

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

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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>

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

.... 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.

Share this post


Link to post
Share on other sites

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>

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

....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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Announcements

  • Similar Content

    • By amin321
      since the installation of macOS, the most observable problem is awaking from sleep failure, I almost tried every related thing like mapping USB ports, appropriate ig-platform-id and disabling dgpu , all of those does not help at all that report on panic gets triggered after force shutdown and reopening the system (as the system does not wake from sleep) dell g3 3590 intel core i7 9750h *iGPU : Intel UHD 630 *RAM : 16GB, 2x8GB, DDR4, 2666MHz *Storage : 256GB M.2 PCIe NVMe Solid Stat e Drive (Boot) + 1TB 5400 rpm 2.5" SATA Hard Drive (Storage) can anybody give me a tip on that
    • By james2058
      Hello guys!
      I have a Asus Zenbook with the following characteristics:
      Model: ASUS Zenbook UX310UQ
      CPU: Intel Core i7-7500U CPU @ 2.70GHz
      IGPU: Intel HD Graphics 620
      RAM: 8GBx2 => 16GB RAM Bus 2133
      Wifi: Replaced with DW1560.
      Clover: Clover 5120
      OS: 10.15.6
      UEFI/LEGACY: UEFI
      Storage: SSD Crucial 500GB
      Everything works fine!

      I have the WiFi/Bluetooth chipset DW1560 (DCM20702A) and a Logitech K380 Keyboard and magic mouse. My Hackintosh is sleeping fine only problem is that it won't wake from sleep on key presses. I already tested this USB port with a normal keyboard and the result was that it wakes up my Hackintosh on key presses. And in system settings the Bluetooth wake option is enabled, too.
      Has someone an idea where the problem could be or which additional settings I have to verify?
      Thank you all
       
    • By amin321
      hello there, I have finished almost everything in my laptop Dell G3 15 3590 intel core i7 9750h UHD630, and everything is okay right now followed dortania (Open core guide) with all my ssdts patches including the USB port, the strange problem that I am facing which is in sleep awake functioning 
      sometimes it sleeps okay and when I am trying to wake it wakes properly, and sometimes it does not wake from sleep at all and then I have to force shut it down with the power button, and it gives me that Report, I wish anyone can help me please as I almost finished everything about 2 months ago and from then I am trying to figure out what makes that issue, please anybo dy help me 

    • By k.panic
      Hi to all, i've installed High Sierra (with Clover) on:
       
      Asrock H110 BTC+
      Intel G3900 (with FakeCPUID 0x0106E0)
      GeForce 710
       
      but he can't go in sleep. what should i fix? Thanks!
    • By dmpcoke
      Hi,
       
      I followed the OC guide, and installed Catalina 10.15.5 on my PC.
      The installation went very well. Most parts also work well after I login to the desktop except the following
      issue:
      Each time I tried to log back into the desktop from sleep, I would get a black screen very shortly after I entered the desktop.
      And black screen will last from a few seconds to a few minutes, no exact lasting time.
      Keyboards and mouse are still working during black screen, I can see the operations after the monitor works again.
       
      It connects LG monitor via DP port and I tried to modified the dp version between 1.2 and 1.4, got the same issue.
       
      Attached my entire OC folder, I'm so appreciated if someone could help me check it out, or tell me which part I should focus on.
       
      Thanks in advance!
       
      P.S. Here is my PC summary: Dell Optiplex 7060 MFF
       
      CPU Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz; 8th Gen, Coffee Lake GPU Intel(R) UHD Graphics 630 RAM Team Group 32 GB (2 × 16GB), 2400 MHz, DDR4 Chipset
      Intel 300 Series LPC (Q370) – A306 Audio Realtek ALC255/3234 (Codec ID: 0x10EC0255) Ethernet Intel(R) Ethernet Connection I219-LM WiFi/BT M.2 BCM43224 802.11a/b/g/n Storage Samsung SSD 970 EVO 500GB USB Ports Type-C × 1,USB 3.0 × 5 Video Output DP × 2 Monitor LG 4K 3840 x 2160 @ 60 Hz
      BIOS v1.4.2 OC.zip
×