Jump to content

Sony Vaio VPCF115FM Discussion: DSDT Injection


  • Please log in to reply
786 replies to this topic

#561
OoTLink

OoTLink

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
boot think supports DSDTs but it doesn't do the same kinda graphics mode system chameleon does.

#562
jlvaio

jlvaio

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 220 posts

boot think supports DSDTs but it doesn't do the same kinda graphics mode system chameleon does.



http://www.presence-...35991/#comments




???????????????????????????????????????????

http://esupport.sony...amp;news_id=349

<h1 id="firstHeading" class="firstHeading">http://en.wikipedia....nthesizer'</h1>

#563
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts
Where can I get a IORegistryTree Dump of an original MacBookPro with a nvidia gt330m inside?

Want to know how this area looks on a MacBookPro:

Attached File  Bildschirmfoto_2011_04_17_um_23.26.40.png   54.5KB   40 downloads


EDIT2: It's a MacBookPro6,2 that fits best.

#564
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts
Here is a manual to successfully compile IOGraphicsFamily:

manual post


AlexanderPD: Ok, I compiled a IOGraphicsFamily for 10.6.6, but exactly as your problem, the version produces lots of dependency errors while booting. Any idea how we can fix this? Maybe we could open a new thread in the projectosx forum, I believe these people there are more experienced...

#565
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts
In case video output lags while moving windows around or the window under mouse pointer lags on your external accelerated display, put this script-app into your users autostart. It requires Quartz Debug installed and will disable beam sync.

There is also the script inside that you can edit with Apple Script Editor. There are 3 lines you can uncomment if you also want to permanently enable QuartzGL.

Attached File  quartzdis.zip   28.23KB   12 downloads

#566
zzecool

zzecool

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
  • Gender:Male

In case video output lags while moving windows around or the window under mouse pointer lags on your external accelerated display, put this script-app into your users autostart. It requires Quartz Debug installed and will disable beam sync.

There is also the script inside that you can edit with Apple Script Editor. There are 3 lines you can uncomment if you also want to permanently enable QuartzGL.

Attached File  quartzdis.zip   28.23KB   12 downloads



does all this have anything to do about sony vaio laptops ( power by nvidia gpu ) and internal lcd fix ?

#567
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts

does all this have anything to do about sony vaio laptops ( power by nvidia gpu ) and internal lcd fix ?


Nothing. Speeds up your external display on Vaio.


Here is a good smbios.plist for Chameleon/Anval Bootloader.

It activates a proper gfx power management profile in AppleGraphicsPowerManagement.kext, so the nvidia display do not stutter or mouse jumps/lags.

<key>SMbiosvendor</key>
<string>Apple Inc.</string>
<key>SMbiosversion</key>
<string>MBP51.88Z.5671.B99.0867221733</string>
<key>SMboardmanufacturer</key>
<string>Apple Inc.</string>
<key>SMboardproduct</key>
<string>MacBookPro5,1</string>
<key>SMfamily</key>
<string>MacBookPro5,1</string>
<key>SMmanufacturer</key>
<string>Apple Inc.</string>
<key>SMproductname</key>
<string>MacBookPro5,1</string>
<key>SMsystemversion</key>
<string>1.0</string>
<key>SMmemtype</key>
<string>24</string>
<key>SMmemspeed</key>
<string>1066</string>
<key>SMmempart</key>
<string>1</string>


You may add SMSerial and SMUUID (google for it).

#568
middle finger response

middle finger response

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Australia
Hey guys, been following this thread since the beginning and it's great to see the amount of progress that has been made so far. I look forward to the day that one of us figures out how to make our graphics play nicely with the internal display. Until then I have a possible alternative that may interest some people.

If anyone here is like me, the main purpose for installing OSX has been for iOS development. The two main issues I have had with using the current solution for this purpose are the inability to display at the screen's native resolution (QE/CI would also be great but I could make do without), and the lack of wifi support.

Over the easter weekend I had an idea. Since all our hardware works under windows, we SHOULD be able to get access to it using with working drivers from an OSX virtual machine running on windows. Maybe some of you have considered or even tried this before. I set up Snow Leopard in VMware a while back and although I got it to boot, it still wasnt fully functional and ran quite slow, so I didn't consider it a viable option.

I decided to look back into virtualising OSX to see if any major advances had been made and was pleasantly surprised. I came across this tutorial here by Mac Son of Knife, which explains how to install Snow Leopard under VMware (I found the tutorial a little confusing at first, if anyone wants to try this and is having trouble I'd be happy to write a quick tutorial for setting it up on our vaios). It seems that official support for a Mac OS guest can now be enabled under a windows host, and VMware tools can be installed, meaning performance is much better than before. The installation is fairly simple, quite a bit easier than doing a native installation.

I now have a near fully functional OS X 10.6.7 VM set up which can run at my native resolution of 1920x1080, does not require a custom bootloader, with working audio and wifi and even partial hardware graphics acceleration. Admittedly, I am yet to try installing any software other than xcode but performance so far seems quite good. For my needs, I believe this is a superior alternative to the native installation at this point in time. I hope that others may also find this a useful intermediate step until problems with native installations have been solved.

I also had a crack at installing under virtualbox but performance seemed a little poor and I was unable to get native resolution support. I also didn't have any luck in making it work without chameleon, so the installation procedure is a bit more complex. For these reasons I would suggest pursuing the VMware option if possible.

#569
AlexanderPD

AlexanderPD

    InsanelyMac Protégé

  • Members
  • PipPip
  • 59 posts

Over the easter weekend I had an idea. Since all our hardware works under windows, we SHOULD be able to get access to it using with working drivers from an OSX virtual machine running on windows. Maybe some of you have considered or even tried this before. I set up Snow Leopard in VMware a while back and although I got it to boot, it still wasnt fully functional and ran quite slow, so I didn't consider it a viable option.


Sorry, this is impossible :wacko:
A native osX installation uses driver for real hardware (example: geforce nvidia 330m), a osX in Vmware uses driver for virtual hardware (example: vmware video adapter), they are totally different and you can't use it ;)

Maybe your only goal is to have 1920x1080 resolution, maybe switchResX can help (i never tried it), but if you want to do it without any software the only way is using a working driver. Actually in vmware osX uses a "standard video driver" without any QI/QE and you can se 1920x1080 because the virtual monitor support this resolution. In our vaios osX can't read the lcd's edid so it don't know what resolutions are supported.. this means only VESA standard resolution, you can change it from chameleon (i use 1280x800.. better than the default 800x600).

#570
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts
I opened a thread on projectosx, how to successfully build a iographicsfamily: build iographics family

Slice gave me a hint, will try it soon. Alexander, maybe you can try too?

#571
AlexanderPD

AlexanderPD

    InsanelyMac Protégé

  • Members
  • PipPip
  • 59 posts

I opened a thread on projectosx, how to successfully build a iographicsfamily: build iographics family

Slice gave me a hint, will try it soon. Alexander, maybe you can try too?


just tried and posted result on projextosx.. still same s**t as before ;)

#572
middle finger response

middle finger response

    InsanelyMac Protégé

  • Members
  • Pip
  • 5 posts
  • Gender:Male
  • Location:Australia

Sorry, this is impossible :(
A native osX installation uses driver for real hardware (example: geforce nvidia 330m), a osX in Vmware uses driver for virtual hardware (example: vmware video adapter), they are totally different and you can't use it :(

Maybe you have not quite understood the point I was making. The fact that VMware presents virtual hardware to the OS is exactly what made me think of using a VM. Instead of OS X seeing our unsupported hardware it sees virtual hardware for which it has working drivers. The virtual hardware still has to talk to our real hardware otherwise what would be the point? The OS X VM may think it is outputting to some generic display adapter, but it must communicate with the windows driver (via VMware) for our nvidia card to actually display an image. While I understand this will not yield the same level of performance as in a native installtion, the point is that OS X is able to indirectly control the display adapter using a driver that functions correctly.

Maybe your only goal is to have 1920x1080 resolution, maybe switchResX can help (i never tried it), but if you want to do it without any software the only way is using a working driver. Actually in vmware osX uses a "standard video driver" without any QI/QE and you can se 1920x1080 because the virtual monitor support this resolution. In our vaios osX can't read the lcd's edid so it don't know what resolutions are supported.. this means only VESA standard resolution, you can change it from chameleon (i use 1280x800.. better than the default 800x600).

I don't think anybody has managed 1920x1080 using any method for a native install. I'm also using 1280x800, and although much better than the default 800x600 it still falls far short of the display quality when running at the native resolution. Using a VM is the only way I am aware of (short of connecting to an external display) for getting native resolution so far.
If you take a look over at the tutorial I linked, there are a couple of drivers written by Zenith432 used which implement some openGL features for improved graphics performance. While they are by no means complete and do not offer full QE/CI support they are much better than just using the standard VMware video driver

#573
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts

just tried and posted result on projextosx.. still same s**t as before :rolleyes:


Hm, why slice writes about repair permissions - I believe that's odd...


EDIT:

One silly idea to fix the display prob:
If you installed devtools, cd to extensions and enter:
otool -arch i386 -vt NVDAResman.kext/Contents/MacOS/NVDAResman | c++filt | grep PowerOff

You'll get two functions:

_osLegacyFlatPanelPowerOff:
_dacPowerOffAllMobilePanels

If we could disable these functions by binpatch the NVDAResman, maybe the display would stay online, no matter what happens? I got this info about usage of otool from here.

EDIT:
otool -arch i386 -vt NVDAResman.kext/Contents/MacOS/NVDAResman | c++filt | grep Panel

_osLegacyFlatPanelPowerOn:
_osLegacyFlatPanelPowerOff:
_dacIsFlatPanelOn:
_dacGetHeadForMobilePanel:
_dacDisableFlatPanelTimingGeneratorSyncs:
_dacPowerOffAllMobilePanels:
_dacExecuteFlatPanelScripts:
_dacSetFlatPanelMode:
_dispInitPanelPowerSaving_STUB:
_dispSetPanelPowerSaving_STUB:
_sorWriteDpInternalPanelBit_STUB:
_sorIsDpInternalPanel_STUB:


Maybe just change the names with hexeditor (like 0xed) to disable?

#574
Alexei Leonov

Alexei Leonov

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Gender:Male
  • Location:London, United Kingdom
Just adding a humble, most probably useless contribution:

I had nothing better to do yesterday and so tried to find some hint strings in NVIDIA's kexts among other things hoping to learn something in the process. Firstly I tried to find some probable hardcoded name for display (in Windows, my VAIO's display is identified as DISPLAY\MS_0025, in Linux, without any patch, NVIDIA's control panel shows a "MS panel" for the internal display LVDS). Actually, I found a boot option in NVDAResman that I didn't know before (nv_disable=1).

So I booted up my hackintosh with "GraphicsEnabler=yes nv_disable=1". In this way, the geforce driver were loaded but disabled. The GUI came normally as it would without using GraphicsEnabler. But this time the properties of the graphics card and display were properly listed in the System Profiler, although "Display connector" was totally blank. But I noticed that in PCI Devices it showed two devices regarding the NVIDIA card (a "display_b" with vendor/device ids 0x10de,0x0a29 and another entry called "NVDA, Parent", with ids 0x10de, 0x0be2 which may be the HDMI port, although it has different device ID in Windows). The last one has "ejection relations" to the first one in the Device Manager of Windows 7. When not using the GraphicsEnabler boot option, none of these devices appear in System Profiler.

IMHO, the "only" problem we have is that the geforce driver has no proper display driver to attach to. I guess that's the same reason why we cannot get full native resolution without GraphicsEnabler. But this isn't any news, I know :rolleyes:

My VAIO: VPCF12M0E/B
GeForce 330M

#575
OoTLink

OoTLink

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
Sadly, the Vmware machine keeps crashing on me after a little while

#576
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts

So I booted up my hackintosh with "GraphicsEnabler=yes nv_disable=1". In this way, the geforce driver were loaded but disabled. The GUI came normally as it would without using GraphicsEnabler. But this time the properties of the graphics card and display were properly listed in the System Profiler, although "Display connector" was totally blank. But I noticed that in PCI Devices it showed two devices regarding the NVIDIA card (a "display_b" with vendor/device ids 0x10de,0x0a29 and another entry called "NVDA, Parent", with ids 0x10de, 0x0be2 which may be the HDMI port, although it has different device ID in Windows). The last one has "ejection relations" to the first one in the Device Manager of Windows 7. When not using the GraphicsEnabler boot option, none of these devices appear in System Profiler.


Oh very good to know that there is a boot option "nv_disable", I always renamed the nvdahal50.kext to boot work with internal screen :( Does this work also with my dsdt that injects the proper nvidia ids without graphicsenabler?

I think if the nvidia driver is disabled, the standard vesa bios of the gfx card will be used, so it's a different mechanism. If there are still some parts of the nv driver inside ioreg, maybe some kexts of nvidia are still loaded? Can you look at kextstat if there is anything nvidia related when using nv_disable? By what kext is display_b hooked up? If you click on it, in the upper part of the window normally "com.apple.iographicsfamily" will appear.

But we need nvidia driver to be completely activated.

#577
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts
Little tutorial about bin patching and disassemble kexts

I made some exemplary bin-patching of the nvdaresman.kext of SL 10.6.7 where I disabled the functions "_osLegacyFlatPanelPowerOff" and "_dacPowerOffAllMobilePanels".

First we need the offsets of the mach-architectures:
lipo -detailed_info NVDAResman.kext/Contents/MacOS/NVDAResman

Result:

fat_magic 0xcafebabe
nfat_arch 2
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 4096
size 3586280
align 2^12 (4096)
architecture x86_64
cputype CPU_TYPE_X86_64
cpusubtype CPU_SUBTYPE_X86_64_ALL
offset 3592192
size 3088816
align 2^12 (4096)

So the offset of x86_64 architecture is from dec 3592192 to hex: 0x36d000.

Now we need to disassemble the x86_64 part of the kext:
otool -arch x86_64 -vt NVDAResman.kext/Contents/MacOS/NVDAResman
The result will be a very large disassemble code. Maybe it's easier to dump it into a text file by adding " > file.txt" at the end of the line. I search now within the dumped result for the two methods.

But there is a much easier way to find the methods by using grep, so you do not need to completely disassemble the kext:
otool -arch x86_64 -vt NVDAResman.kext/Contents/MacOS/NVDAResman  | c++filt | grep -A 2 PowerOff
"-A 2" means that grep will display the found line + 2 lines afterwards.

_dacPowerOffAllMobilePanels:
000000000009569d pushq %rbp
000000000009569e movq %rsp,%rbp
...

_osLegacyFlatPanelPowerOff:
0000000000067637 pushq %rbp
0000000000067638 movq %rsp,%rbp
...

Now I calculate with OSX's calculator the real binary offsets:
_dacPowerOffAllMobilePanels: 0x36d000 + 9569d = 0x40269d
_osLegacyFlatPanelPowerOff: 0x36d000 + 67637 = 0x3d4637

In 0xED I overwrite two bytes at 0x3d4637 and 0x40269d:

C9 C3
C9: opcode for "leave"
C3: opcode for "ret"

I don't really know if the "leave" is really required, but it seems to be exist before every return of a function.
You can ensure that the patches are rightly done by disassemble the kext again.

So here is the patched nvdaresman.kext of OSX 10.6.7. Try it out :(
Patched nvdaresman.kext 10.6.7


EDIT: All functions dump:

otool -arch x86_64 -vt NVDAResman.kext/Contents/MacOS/NVDAResman | c++filt | grep -A 1 _ > functions.txt



#578
Alexei Leonov

Alexei Leonov

    InsanelyMac Protégé

  • Members
  • Pip
  • 27 posts
  • Gender:Male
  • Location:London, United Kingdom

So here is the patched nvdaresman.kext of OSX 10.6.7. Try it out :wacko:
Patched nvdaresman.kext 10.6.7


I've tried your patched kext but it didn't work. I've got a "link error" message during the verbose boot and the nv50hal kext didn't load sucessfully. But maybe that's because I haven't updated to 10.6.7 yet.
Nevertheless, I don't believe that disabling PanelOff functions will work. I think the driver doesn't power on the internal panel anyway as it cannot find one.

When I get spare time I'll update and test it again.

Oh very good to know that there is a boot option "nv_disable", I always renamed the nvdahal50.kext to boot work with internal screen :D Does this work also with my dsdt that injects the proper nvidia ids without graphicsenabler?

I think if the nvidia driver is disabled, the standard vesa bios of the gfx card will be used, so it's a different mechanism. If there are still some parts of the nv driver inside ioreg, maybe some kexts of nvidia are still loaded? Can you look at kextstat if there is anything nvidia related when using nv_disable? By what kext is display_b hooked up? If you click on it, in the upper part of the window normally "com.apple.iographicsfamily" will appear.

But we need nvidia driver to be completely activated.


Wow, so my little contribution wasn't totally useless :)

All the NVDIA kexts are loaded when using nv_disable option. That's why I actually get correct data about the graphics card (e.g. memory size) in the System Profiler (I don't use DSDT or any other modification apart GraphicsEnabler=yes). If I don't use GraphicsEnabler and nv_disable at the same time of course I get the standard vesa and the graphics card info in System Profiler becomes wrong.

Which window is that regarding the kext for display_b?

#579
AlexanderPD

AlexanderPD

    InsanelyMac Protégé

  • Members
  • PipPip
  • 59 posts

So here is the patched nvdaresman.kext of OSX 10.6.7. Try it out :D
Patched nvdaresman.kext 10.6.7


tried with osX 10.6.7 (but with 10.6.6's kernel) and osX boots up.. but nothing happen on main lcd. No differences in ioreg too :wacko:

btw, i found a friend with the old mac book pro with geforce 330m, so i asked for a ioreg dump and.. you can download from this post :P Hope this can help!

little edit: you must use IORegistryExplorer for open it in a good way!

Attached Files



#580
Funky frank

Funky frank

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 462 posts

btw, i found a friend with the old mac book pro with geforce 330m, so i asked for a ioreg dump and.. you can download from this post :rolleyes: Hope this can help!

little edit: you must use IORegistryExplorer for open it in a good way!

That's interesting. display_A and display_B, its subclasses "NVDA" are matched my com.apple.NVDAResman. On Sony with attached HDMI it's iographicsfamily which matches the hdmi.

So I conclude the nvidia driver can work with nvdresman or with iographicsfamily. So there are 2 ways to fix it:

1. Adding the capability of detecting the internal display to iographicsfamily (maybe it only supports standards)

2. Patching nvdaresman. Here we should compare it somehow with the win7 corresponding dll.

(3. Enabling the internal display before driver kicks in by using the SNY5001 device)


The display-A and subclass display0 is actually matched by iographicsfamily in this ioreg of the macbookpro. So I guess, patching iographicsfamily would be the most realistic way. What do you think?


EDIT: Alexander, can you get the DSDT from your friend's macbookpro too?

EDIT2: Are there any Vaios with ATI inside that also have the internal display problem?





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2017 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy