- Joined
- Jun 13, 2012
- Messages
- 152
- Motherboard
- Lenovo Ideapad Y510P
- CPU
- i7 4700MQ
- Graphics
- HD4600
- Mobile Phone
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:
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:
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.
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.