310m/Intel GPU Optimus

[plasticinedean]

Hi guys, no updates from 30-september?

Nope sorry, pretty much still waiting on support for the intel hd gma. To see what progress is happening there have a look at http://tonymacx86.com/viewtopic.php?f=18&t=2348&start=150&sid=e2e773ac9120e1f87eac2e2587cb1cf4 or for the more technical side http://www.insanelymac.com/forum/in...456cbb782fffa2bdffeb2&showtopic=223754&st=160

 

[fiox]

Hello, thank you, but I follow these forums for a long time (tonymaxx86 and insanelymac)
I hope that soon a solution is found

Bye

 

[Everell]

It seems that the linux guys are on the right way:
http://linux-hybrid-graphics.blogspot.c ... -asus.html

Is anybody able to adopt this for OS X?

 

[Everell]

@Faselbla:

Do you have the problem while installing or after the install of SL?

 

[kizwan]

I did further testing last night with os-info (to be exact AAPL,os-info for the IGPU - Intel GPU) & with AppleIntelHDGraphicsFB.kext loaded. AppleIntelHDGraphics.kext is removed because it caused KP on my notebook. I found it function like Nvidia NVCAP.

30 49 01 11 01 10 08 00 00 01 00 00 00 00 00 00 FF FF FF FF
30 49 00 14 14 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF
30 49 01 01 01 00 08 00 00 00 00 00 00 00 00 00 FF FF FF FF

This test has been done with external monitor plugged in to HDMI port.
- The 1st & 3rd os-info detected the internal LCD (in IOReg) but the screen is blank/black. No signal to the external monitor.
- The 1st one actually already exist in IOReg (automatically) without manual injection.
- The 2nd os-info turned off the internal LCD. Grey screen on external monitor. No display detected in IOReg.
Since 1st & 3rd behave the same, I found out that the fifth bytes is identical between 1st & 3rd. So I did little experiment with 2nd os-info.

30 49 00 14 01 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

- The result is the same with 1st & 3rd.

30 49 00 14 02 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

- The result is grey screen on external monitor. Internal LCD turned off. No display detected in IOReg.

30 49 00 14 03 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

- The result is only a little artifact (just artifact) on the external monitor. Internal LCD turned off. There is only two lines under IGP device in IOReg.

30 49 00 14 04 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

- The result is grey screen on external monitor. Internal LCD turned off. No display detected in IOReg.

I think I can make the conclusion that the 0x01 at the fifth bytes is internal LCD connection (LVDS/TMDS).
os-info_FifthBytes_InternalLCD.jpg
So, to activate the external monitor I need to find which bytes hold it. Maybe the green one is for primary display while the red one is for secondary display?

30 49 01 11 01 10 08 00 00 01 00 00 00 00 00 00 FF FF FF FF

I wish I know what other bytes means.

 

[kizwan]

30 49 01 11 01 10 08 00 00 01 00 00 00 00 00 00 FF FF FF FF
30 49 00 14 14 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF
30 49 01 01 01 00 08 00 00 00 00 00 00 00 00 00 FF FF FF FF
- The 1st one actually already exist in IOReg (automatically) without manual injection.

Sorry, I checked it again & the there is no os-info entry in my old IOReg dump. I must have mixed up with real macbookpro's IOReg dump.

Anyway, I tested the three os-info again with external LCD connected to VGA port. I got mangled screen at the external monitor with all three os-info.

30 49 01 11 01 10 08 00 00 01 00 00 00 00 00 00 FF FF FF FF

- Mangled screen on external LCD. Backlight only on internal LCD. Display detected in System Profiler & IOReg is the internal LCD.

30 49 00 14 14 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

- Mangled screen on external LCD. Internal LCD is turned off. Display detected in System Profiler & IOReg is the external LCD.

30 49 01 01 01 00 08 00 00 00 00 00 00 00 00 00 FF FF FF FF

- Mangled screen on external LCD. Backlight only on internal LCD. Display detected in System Profiler & IOReg is the internal LCD.

I also did further test with 2nd os-info with different value at the fifth bytes:-

30 49 00 14 01 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

2nd_os-info_5thBytes_0x01.jpg
- Mangled screen on external LCD. Backlight only on internal LCD. Display detected in System Profiler & IOReg is the internal LCD.

30 49 00 14 02 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

2nd_os-info_5thBytes_0x02.jpg
- Mangled screen on external LCD. Internal LCD is turned off. Display detected in System Profiler & IOReg is the external LCD.

30 49 00 14 0F 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

2nd_os-info_5thBytes_0x0F.jpg
- Mangled screen on external LCD. Backlight only on internal LCD. Display detected in System Profiler & IOReg is the internal LCD.

30 49 00 14 04 14 08 04 00 00 00 00 00 00 00 00 FF FF FF FF

- Mangled screen on external LCD. Internal LCD is turned off. Display detected in System Profiler & IOReg is the external LCD.

 

[kizwan]

Mangled screen means I can see the desktop, icons, etc but it is badly mangled.

 

[minihack]

Might another approach be to look at the hardware registers for the Intel HD internal graphics on the processor and see if a disable bit could be written to it to turn the graphics part off and see if that allowed the Nvidia to take over?

I have done a little searching for Intel specifications for the i5 mobile processor set and found the attached document. Possibly page 62 gives the location of hardware register for turning off the internal graphics function [Note Internal Graphics device is defined as "device 2" on page 39 of this document]:
322813.jpg

Maybe by identifying this register using Reggie SE and writing a zero to bit 3 would confirm whether the Intel HD graphics could be turned off?

Also page 65 refers to a register for routing to an external graphics card (in case of this thread the 310M) and describes the bit settings.
322813.pdf.zip

Please note that I have a Vostro in which the intel HD graphics are permanently disabled (probably by the method described on page 61 of the document which looks to be locked and not user settable, whereas the method on page 62 is referred to a "lockable"). So this post is just a theory and I have no way of testing myself and carry no liability for you trying a register write operation yourself. Those with the wherewithal to at least check the register statuses and see if they conform to the spec.s as set out in the attachment might perhaps want to experiment a little and post your results....

 

[kizwan]

Maybe by identifying this register using Reggie SE and writing a zero to bit 3 would confirm whether the Intel HD graphics could be turned off?

Yes, you can enabled/disabled the Intel HD Graphics this way. However, considering the optimus architecture/configuration, I doubt Nvidia GPU can take over. Anyway, even though I'm sure Nvidia GPU won't be able to take over, I still think this is something we should try. I believe the register will reset back to default after computer reboot or powercycle, right?

 

[comatron]

i´m now on a lenovo z360 with 310m and intel hd too. i spent 3 days of testing with several injectors and modifying kexts - but no luck. absolultely not ...

now i have questions:

how to force the maschine to boot in VESA? i allways need to use nawcoms mod boot cd which allows me to boot the installation in vesa mode.

what are your device ids? mine are 0a70 (nvidia) and 0046 (intel - should be the same at all ppl out there). there are guys runnin the 310m with devif 0a72 oder whatsoever (samsung R series). they installed a distro and used nvenabler / aty_init in combination with graphics enabler (wich is strange bs) ... but that thing works. see here:

http://www.insanelymac.com/forum/index. ... pic=221769

there are some other thread where ppl randomly found a solution without knowing how to do. so - this should be possible.

i am willing and able to test the hell out, debug and report if any of the geniuses out there need a guy having strong nerves to test and test and test

if you have the same notebook (wich is VERY nice and compatible exept GFX) - heres the thread for that:

http://www.insanelymac.com/forum/index. ... pic=237160