Contribute
Register

Lenovo Y510P (with mobile HD4600) graphic problem

Status
Not open for further replies.
Joined
Jun 13, 2012
Messages
152
Motherboard
Lenovo Ideapad Y510P
CPU
i7 4700MQ
Graphics
HD4600
Mobile Phone
  1. Android
Hi everybody.

I've installed OS X in dual boot with Windows 8.1 using Clover EFI. The process is fairly straightforward:
1. Created USB (manually by mounting, restoring, bla bla bla) then installed Clover EFI on the usb adding required kexts and setting config.plist with ig-platform-id = 0x0a260006 and FakeID = 0x041208086 for Intel with Intel injected and EDID too.
2. Used the usb to format and install Yosemite 10.10.1 on a separate partition on my HDD.
3. Booted OS X using the USB and installed Clover EFI for installed system with adding kexts and configuring config.plist as above.

Now as the thread title says, I am having an annoying problem with graphics on my Lenovo Y510P. It is a glitch in graphics happens when display is set to sleep then wake the graphics looks distorted like reverting to 16-bit colour. This can be seen easily on any translucent area like Launchpad and Notification.

What is worst, once this glitch happens the system can't restart anymore. If I choose to restart the system halt with display off but fans running and I am forced to power off by power button. It doesn't stop here, if I set my system to sleep then wake, the problem occurs as well because display sleep/wake is part of system sleep/wake.

The problem is not related to Yosemite as it can be reproduced in Mavericks as well. Regarding graphic drivers patching I followed this thread (http://www.tonymacx86.com/yosemite-...-fix-intel-hd4400-hd4600-mobile-yosemite.html) and had all the patches there. So basically, my system should be running without graphics issue but it is not.

I have been advised to try other ig-platform-id than 0x0a260006 and I tried those without luck:
1. 0x0a260006 (with or without 9MB cursor bytes patch)
2. 0x0a260005
3. 0x0a26000a
4. 0x0a260000 (doesn't work for me but others with the same laptop confirm they have it working but with the same glitch)

All this without DSDT/SSDTs edits on a clean install without missing with any system file but OpenCL.framework as it have to be patched on disk. Speaking of DSDT/SSDTs I had to introduce them to fix brightness and other things for system sleep. So brightness works and sleep/wake works so well apart from the issue posted above.

During investigation with Rehabman we tried few things like testing if _PTS/_WAK are being entered and exited successfully using ACPIDebug with "Add DSDT Debug Methods" and "instrument_WAK_PTS" patches and the results were positive and they are fine as shown below:
Code:
01/12/2014 16:23:50.680 com.apple.kextcache[692]: kext-dev-mode allowing invalid signature -67062 0xFFFFFFFFFFFEFA0A for kext ACPIDebug.kext
01/12/2014 16:37:15.000 kernel[0]: ACPIDebug: Version 0.1.2 starting
01/12/2014 16:41:05.000 kernel[0]: ACPIDebug: { "_PTS enter", 0x3, }
01/12/2014 16:41:05.000 kernel[0]: ACPIDebug: "_PTS exit"
01/12/2014 16:41:05.000 kernel[0]: ACPIDebug: { "_WAK enter", 0x3, }
01/12/2014 16:41:05.000 kernel[0]: ACPIDebug: "_WAK exit"
01/12/2014 16:52:47.000 kernel[0]: ACPIDebug: { "_PTS enter", 0x3, }
01/12/2014 16:52:47.000 kernel[0]: ACPIDebug: "_PTS exit"
01/12/2014 16:52:47.000 kernel[0]: ACPIDebug: { "_WAK enter", 0x3, }
01/12/2014 16:52:47.000 kernel[0]: ACPIDebug: "_WAK exit"

Another thing he wanted me to test is comparing SystemMemory addresses in both native DSDT and the patched one. For this I had to grab the native tables using Linux and tested them in OS X. I found that there are 19 mentions to SystemMemory addresses in both files and 4 of them are listed slightly different between the tables. Here are the different ones:

Code:
Native  : OperationRegion (GNVS, SystemMemory, 0x8CFBCA98, 0x000002F6)
Patched : OperationRegion (GNVS, SystemMemory, 0x8CFBCA98, 0x02F6)

Native  : OperationRegion (OGNS, SystemMemory, 0x8CFBBF98, 0x0000003A)
Patched : OperationRegion (OGNS, SystemMemory, 0x8CFBBF98, 0x3A)

Native  : OperationRegion (MDBG, SystemMemory, 0x8CFB8018, 0x00001004)
Patched : OperationRegion (MDBG, SystemMemory, 0x8CFB8018, 0x1004)

Native  : OperationRegion (COMP, SystemMemory, 0x8CFBEC98, 0x00000200)
Patched : OperationRegion (COMP, SystemMemory, 0x8CFBEC98, 0x0200)

I don't know if that make sense or not but let's see Rehabman's opinion about it.

I'm attaching IOreg in addition to pictures taken by mobile phone before and after replicating the process for the glitch. To see it clearly zoom into area just above the dock in both pictures and compare. I could have taken screenshots from OS X itself but both (before and after) will be the same and glitch will not be visible. This may be due to screenshot are taken from the system before processing to show on display (i.e before the glitch goes in).


UPDATE:

I have updated the way I patch graphics so now I use FakePCI*.kext with the FakeID of 0x04128086 and the issue still present. The problem is reproducible in many ways, for example:

> System sleep: it turns display off in the process then on wake it turns display on
> Screen Saver: on switch on it turns display off then on to activate SS
> Selecting display sleep to any corner from screen saver dialog
> Changing screen resolution: Display turns off then on as part of the process
> Connecting to external display

The problem symptoms AFAIK are:

> Crippled graphics with gradients (as if it is 16-bit colour) in all translucent areas (Notification centre and Launchpad for example)
> Restart is not working (goes all the way and hang into a state where display is off, mouse and keyboard are off, and machine still working)

I have been trying to investigate the problem as far as I can. I found that without graphic fix procedure the problem does not exist. I.e., IF i remove all FakePCI*.kext and boot with FakeID=0x04168086 and the graphics will be unfixed (as expected) but there will be no way to replicate the problem.

So I guess it is something related to the graphics fix (using FakePCIID) that maybe my graphics ship needs more patching for it to work nicely as other mobile HD4600.
 

Attachments

  • Files.zip
    4 MB · Views: 136
...
I'm attaching IOreg in addition to pictures taken by mobile phone before and after replicating the process for the glitch. To see it clearly zoom into area just above the dock in both pictures and compare. I could have taken screenshots from OS X itself but both (before and after) will be the same and glitch will not be visible. This may be due to screenshot are taken from the system before processing to show on display (i.e before the glitch goes in).

I don't see any glitches in your photos.
 
I tried choosing from the existing presets but nothing made any difference to the problem. (Whisper: Display wake results in losing restart, forget about the colour for now).
 
I tried choosing from the existing presets but nothing made any difference to the problem. (Whisper: Display wake results in losing restart, forget about the colour for now).

The two issues may be related...
 
Okay let's think differently instead of try and error. Assume this scenario:

- System is running fine before display sleep/wake
- After display sleep/wakesomething happened resulted in the issues
- A screenshot taken after the issue but noticed no graphic distortion in the screenshot (while visible on display)

This means the system is rendering the graphics fine all the time regardless of sleep/wake. However, displaying the rendered graphics after display wake is problematic. So this make me wonder which part of the OS is responsible to display the already rendered graphics because it might have issues after waking display. This one might be connected to restart functionality one way or another.
 
Okay let's think differently instead of try and error. Assume this scenario:

- System is running fine before display sleep/wake
- After display sleep/wakesomething happened resulted in the issues
- A screenshot taken after the issue but noticed no graphic distortion in the screenshot (while visible on display)

This means the system is rendering the graphics fine all the time regardless of sleep/wake. However, displaying the rendered graphics after display wake is problematic. So this make me wonder which part of the OS is responsible to display the already rendered graphics because it might have issues after waking display. This one might be connected to restart functionality one way or another.

Did you review DSDT/SSDT diffs from native -> patched?

That is, diff the files you kept... review the files you dropped... to be sure it all makes sense...
 
Did you review DSDT/SSDT diffs from native -> patched?

That is, diff the files you kept... review the files you dropped... to be sure it all makes sense...

Sorry I've been busy lately. I'll do that and update.

Just to add up to the problem, the issue is reproducable when connecting external display too since the main display have to turn off then on.
 
Hi, I'm sorry for being late on reply again. I've been working on fixing other issues but currently this is the main issue I have.

You advised me to compare DSDT/SSDTs patched against the native which I don't know how to do for sure .. If I found I'm dropping a table how to know it is related?

Also to give you more info I updated the first post with additional info.

Thanks for all your work
 
Hi, I'm sorry for being late on reply again. I've been working on fixing other issues but currently this is the main issue I have.

You advised me to compare DSDT/SSDTs patched against the native which I don't know how to do for sure .. If I found I'm dropping a table how to know it is related?

Also to give you more info I updated the first post with additional info.

Thanks for all your work

Disassemble both your patched files and your native files. Then compare them with diffmerge.
 
Alright I did that (I think). Basically, the native SSDT's are 7 and I compared them to the patched ones and here are my notes:

SSDT-0 : Exist in patched but no major difference from native (not even patched)
SSDT-1 : Does not exist in patched (I have SSDT-1 in patched but for CPUPM)
SSDT-2 : Exist in patched with small differences from native
SSDT-3 : Does not exist in patched (I have SSDT-3 in patched but for disabling Optimus)
SSDT-4 : Exist in patched but no major difference from native (not even patched)
SSDT-5 : Exist in patched but no major difference from native (not even patched)
SSDT-6 : Exist in patched with major differences from native (mostly PNLF, HDAU, and IGPU patches)

I attached a pictures from DiffMerge for all the 5 comparable SSDT's (the pictures only shows the diffs). I'm also attaching the SSDT's that doesn't exist in my patched folder (SSDT-1 and SSDT-3) maybe you can help me figure if they are related to the problem.

Thanks.
 

Attachments

  • Archive.zip
    571.1 KB · Views: 75
Status
Not open for further replies.
Back
Top