Jump to content

Sony Vaio VPCF115FM Discussion: DSDT Injection

kizwan

By kizwan,
in Laptops

 Share
787 posts in this topic

Recommended Posts

20brains
20brains
Posted
Posted

I had it working with lion when it was at 10.7 once i updated i never got it to work. it keeps having a conflict with the graphics i believe and would never boot.. have to boot with some legacy kexts in the extra folder but that only works on the 10.7

Link to comment
Share on other sites
  • 1 month later...
fernando.c.neves
fernando.c.neves
Posted
Posted

Well now is time to simple pass my work in Sony Vaio VPC F Series, I had one VPCF130-FB from Brazil with 310m, i5... I had successfully install Mountain Lion DP3 with Fully QE/CL working on it right OOB, but only in External HDMI, I uses DSDT and all Mountain Lion Kext without enabler only GraphicsEnabler=yes getting Full Resolution of 1920x1080X32@60. So, the big point is after all this great discussion, to has a fully working LCD with QE/CL in Native 1920x1080x32 resolution, but i can't get this working on LCD.

 

Maybe some DSDT injection do the work with the LCD panel I guess...

 

Someone has tried out some DSDT injections to correct this issue?

 

Please don[t let this post get lost, let's make this thing works!

 

Now I successfully Installed Mountain Lion, we really has more job to do.

 

Best regard,

Fernando Castro Neves.

 

Brazil

Link to comment
Share on other sites
  • 3 weeks later...
Funky frank
Funky frank
Posted
Posted

This could maybe open new possibilities. Anybody tried clover? I think the Vaio F11 is also UEFI:

 

http://www.projectosx.com/forum/index.php?showtopic=2304

 

And another idea:

 

What about connecting the internal lcd connector to the external hdmi port by using a built adapter?

 

As far as I can remember the Vaio F11 has a LVDS connector for the internal LCD. So we would need a HDMI to LVDS converter/adapter.

 

EDIT: Anyone tried this Quadro driver for 10.6.8?

http://www.nvidia.com/object/quadro-macosx-256.02.25f01-driver.html

Link to comment
Share on other sites
  • 5 weeks later...
Alexei Leonov
Alexei Leonov
Posted
Posted

Hey guys, this probably has nothing to do with the problem of getting the internal screen to work, but have you ever noticed the dip switches behind the keyboard?

 

http://www.laptoppartsexpert.com/attachment/30622-.jpg

 

In this link, it is mentioned that the dip switch has to be set up in order to use some replacement LCDs for Vaio:

 

http://www.laptoppartsexpert.com/i-1902422-lcd-screen-display-16-4-wxga-tft-single-lamp-auo-lgp.html

 

I remember to have read somewhere that for specific LCD replacements, if the dip switches are misconfigured, the result is a screen with the backlight off, which resembles the situtation we get with GraphicsEnabler=yes on MacOS, I reckon. Sorry, but I cannot find the link where someone who has tested mentions it, but there's an interesting discussion here:

http://forum.notebookreview.com/sony-owners-lounge-forum/521914-official-sony-vaio-f-series-i5-i7-owners-thread-part-5-a-413.html#post7314323

 

It's a shot in the dark, but I wonder if changing the default dip switch setting can actually help the nvidia macos driver to detect the internal screen. Unfortunately I don't have a MacOS installed on my Vaio VPCF12 any more to test it. What do you think?

Link to comment
Share on other sites
jlvaio
jlvaio
Posted
Posted

Hey guys, this probably has nothing to do with the problem of getting the internal screen to work, but have you ever noticed the dip switches behind the keyboard?

 

http://www.laptoppar...ment/30622-.jpg

 

In this link, it is mentioned that the dip switch has to be set up in order to use some replacement LCDs for Vaio:

 

http://www.laptoppar...mp-auo-lgp.html

 

I remember to have read somewhere that for specific LCD replacements, if the dip switches are misconfigured, the result is a screen with the backlight off, which resembles the situtation we get with GraphicsEnabler=yes on MacOS, I reckon. Sorry, but I cannot find the link where someone who has tested mentions it, but there's an interesting discussion here:

http://forum.noteboo...tml#post7314323

 

It's a shot in the dark, but I wonder if changing the default dip switch setting can actually help the nvidia macos driver to detect the internal screen. Unfortunately I don't have a MacOS installed on my Vaio VPCF12 any more to test it. What do you think?

 

interresting, so it could be a sting for this oir some kind of overide

Link to comment
Share on other sites
  • 1 month later...
  • 2 weeks later...
  • 1 month later...
Funky frank
Funky frank
Posted
Posted

Hey mates,

 

I have some sleeping issue with my Vaio F11 and Snow Leopard 10.6.6 and I forgot how to fix this:

 

When the system goes to sleep and wakes up again (using external HDMI, SleepEnabler, FakeSMC, AppleACPIPS2Nub), the kernel task will now take 35% usage constantly.

 

Any idea how to avoid this crazy usage of cpu? It must be some kext the went crazy, but I don't know any way to find out what kext uses the cpu...

 

Thanks.

Link to comment
Share on other sites
  • 2 weeks later...
Funky frank
Funky frank
Posted
Posted

UPDATE 05-Nov-12: Fixes for OSX 10.6.8 v1.1

 

 

Here are my recent settings for Vaio F11 / OSX 10.6.8v1.1

 

 

Config

 

Here is my new DSDT for Vaio F11. It now has 4 irqs assigned for HPET that do not seem to conflict any other irqs/devices. It hopefully gives you stable firewire and stable cpu performance...

 

DSDT.aml 31oct2012 ff.zip

 

I also only use 3 kexts in bootloader for OSX 10.6.6-10.6.8v1.1: AppleACPIPS2Nub, fakeSMC, SleepEnabler:

 

Ext 31oct2012 ff.zip

 

For OSX 10.6.8, you need to set pmVersion to 23 in boot.plist and replace (and pfix) AppleACPIPlatform.kext and IOPCIFamily.kext with versions from 10.6.7 directly after running the OSX 10.6.8 combo update. If you do not replace the kexts before reboot, the system will become unstartable, you change to remove it from your Vaio and plug into into another OSXcomputer then to run pfix from there (it can fix perms on external devices too). There are other approaches to fix this "PCI-configuration-start"-problem: http://netkas.org/?p=849 http://www.osx86.net..._begin_fix.html

 

org.chameleon.boot.plist.zip

 

ACPI_PCI_1067_for_1068_ff.zip

 

 

Audio

 

And here is a configured voodoohda.kext (has to be placed into /sys/lib/ext) that successfully shows hdmi audio + internal audio. But hdmi audio output does not work on my external hdmi screen, maybe on yours?

 

VoodooHDA.kext 31oct2012 ff internal+hdmi.zip

 

In case the above VoodooHDA behaves unstable or hdmi audio out is not usable for you too, here is my voodoohda.kext that behaves very stable and only gives you internal audio:

 

VoodooHDA 31oct2012 ff internal only stable.kext.zip

 

After update from 10.6.6. to 10.6.8v1.1 these VoodooHDA kexts became unstable for me, if I put them directly to s/l/e. So load them by script using "sudo kextload KEXT" after desktop has booted.

 

 

Graphics

 

This is the recent GT330m nvidia driver for OSX 10.6.6 (version 256.02.25f01). Put the kexts into /System/Library/Extensions, make a "chown -R root:wheel kext" on each and then run pfix (included in zip). It's also a good idea to backup all overwritten kexts first.

 

This version fixes the blue mouse blue problem and maybe other problems too...

 

https://rapidshare.c...f.zip|31714|0|0

 

For OSX 10.6.8, you should stay with the nvidia kexts included in the combo update and also DISABLE GraphicsEnabler in boot.plist, if you use my dsdt above! See boot.plist above.

 

 

The internal screen problem

 

I did some approaches to fix the annoying internal screen problem. First I want to describe you what actually happens:

 

- Since Sony uses a proprietary energy management chip, the nvidia driver is not able to activate the internal lvds/lcd, so it is not detected at all.

- The nvidia driver only works correctly if you use an external hdmi monitor attached. The internal screen will be powered off.

- If you want to use the internal screen, this is only possible by deactivating the nvidia-driver and using the simple framebuffer (like windows secure mode) without any acceleration. You can easily do this by adding "nv_disable=1" the the Chameleon's boot prompt.

- If you look into ioreg (using IORegistryExplorer), the internal screen should appear under "NVDA, Display-A@0/NVDA/display0". But this only happens on Display-1, the external hdmi port.

 

So in my opinion there are only two ways to fix this problem:

 

1. Patching IOGraphicsFamily, because IOGraphicsFamily is responsible for detecting displays and putting it to the grapihcs driver. IOGraphicsFamily is opensource and can be modified!

 

2. Maybe activating some power management of the Sony's power management chip by using direct ACPI calls. This can be done by using Slice's ACPIMonitor. My DSDT also provides some Sonytesting functions. More details can be found in this and the following posts:

http://www.insanelym...80#entry1683553

 

3. Binary-patching the nvidia driver somehow... Maybe by disassemble the win7 driver and compare the init routines...

 

No other way will work!

Link to comment
Share on other sites
  • 2 weeks later...
jlvaio
jlvaio
Posted
Posted

http://webcache.googleusercontent.com/search?q=cache:3turoEVKa5EJ:0xc0dedbad.com/blog/tag/vaio/+vaio+edid+dump&hl=fr&gl=fr&prmd=imvns&strip=1

 

 

 

 

A Brief History Lesson

 

There have been many issues getting Linux to work with the hybrid graphics being embedded in a number of modern laptops containing nVidia GPUs. The primary issue is being able to switch between the low- and high-power display adapters. Previously, it was possible to achieve ‘cold-switching’ in Linux (allowing a switch of display adapters by changing the position of the hardware switch, and rebooting) by disabling the Vista compatibility reported via ACPI using the kernel boot flag:

acpi_osi="!Windows 2006"

This exploited the BIOS behaviour designed to work with Windows XP, which does not support hot-switching of display adapters. The details have been extensively documented elsewhere, so I won’t go into too much detail here – there is a moderately thorough capture of the data at the Sony VAIO Z-series Launchpad group, with more discussion in the mailing lists of ongoing progress.

With the availability of Windows 7, however, a BIOS update was required to modify the DSDT tables to support the new calls that Windows 7 would use to manage the hot switching of display adapters in these hybrid systems. An unfortunate side-effect of these updates was that Windows XP was no longer supported, and the methods required to retrieve EDID data from the internal LVDS display were moved from the GPU to the BIOS for the high-power nVidia card.

The result is that booting Linux with the high-powered nVidia card enabled results in pretty vertical lines, or multiplied fragments of the intended output during boot, as the LVDS display is fed junk. Once X starts, and the nVidia drivers kick in, the LVDS display goes completely blank, as no EDID negotiation can occur. An external display will work fine, but obviously this is not ideal in a laptop. ;)

 

The State of Play (nVidia support)

 

The binary driver blob from nVidia has always been a source of contention in the open source community, due to their persistence in keeping the driver entirely closed-source, and the kernel-taint resulting from this, despite the fact that all other major display adapter manufacturers have now released specs, and open-sourced their drivers. That said, nVidia have been the go-to chipset for accelerated 3D graphics on Linux for quite some time now, but with many current nVidia-powered laptops being all but unusable with the current state of support from the binary blob, the decision is far less clear-cut, with unsupported parts being entirely useless.

The behaviour displayed by Windows 7 compatible BIOSes in (at least nVidia-based) hybrid GPU laptops is also present for some of nVidia’s standard parts, at least the G210m, and I believe a couple of other similar parts. The nouveau project have apparently made some progress in allowing the EDID data to be retrieved, however this requires kernel modification, since there is no mechanism currently for communicating this information from the BIOS… and of course the nouveau project currently doesn’t support any 3D acceleration, which is really the point here. There has been some significant lag in supporting these parts from nVidia, with drivers purporting to support them, then having support stripped in subsequent releases as the problems were identified, though it appears that support is on the way in a near-future driver release UPDATE1/UPDATE2.

Making Things Work Now

 

Whilst it looks like we may get real support in the moderately near future, we want things to work in the mean time. Some enterprising fellows in the nVidia forums have discerned the method for retrieving and providing the missing EDID data to the X driver, by way of Windows. Obviously this is not ideal, and may not be an option for some, but for the rest, here’s the how. This information is based solely on the Sony VAIO Z series laptops, since that’s what I have access to, but it may be relevant to laptops from other manufacturers that employ similar graphics setups.

First, you’ll want to modify your kernel boot string by removing the acpi_osi flag if you’ve been using it, and if you want to be able to see anything whilst booting, you’ll also need to remove the splash parameter, and add the following (See UPDATE for details on recent drivers):

nomodeset

This will stop the VESA driver from trying to switch to a mode that we can’t support until the nVidia driver kicks in. Also note that once the nVidia driver is initialized, you’ll lose the ability to display VTs – they’ll just show a blank screen, same for the shutdown sequence.

If you’re using the sony-laptop module modified by Eva and Norbert, and as installed by the sony-VGN-Zseries-janitor script, you’ll need to make sure the kernel is loaded with speed_stamina=3, which can be done by placing the following in a file in /etc/modprobe.d/

options sony-laptop speed_stamina=3

Next, the BIOS will need to be updated to a recent revision that contains Windows 7 support. The BIOSes of the various Z-series revisions are interchangeable, so I used the R5031M3 release, which you can download from your local Sony Support site. To make this work as we want it to, however, the BIOS needs to be modified to enable the Advanced section, allowing us to change the mode of the hardware graphics switch. Whilst the os_acpi option will likely still work, this results in garbled graphics following a reboot, making it impossible to access the BIOS, or view boot menus.

To modify the BIOS, a specially crafted EFI boot disk is required, however in all BIOS releases supporting Windows 7, EFI booting from external devices has been disabled. The only method for booting from external EFI media is to disconnect both the HDD and optical drive, however most people are probably reluctant to go to these lengths, particularly considering how difficult and convoluted it is to remove the keyboard to gain access these components. If this is you, some googling will yield pre-patched BIOSes for download. For those who like a challenge, the process for patching the BIOS is described here.

Once you’ve got your Windows 7 BIOS installed, reboot and enter the BIOS configuration by pressing F2 when the VAIO logo is displayed. You’ll notice a slew of new options under the Advanced section, so feel free to tweak a few things (enabling the VT-d option, for example), but be aware that you may seriously impair the functionality of your system by messing too much in here. The option we’re looking for is VGA Switching Policy. Set this to Static, noting that this will disable hot-switching in Windows, whilst enabling cold-switching for all OS’s

Now, flick the graphics hardware switch over to Speed and boot back into Windows. You’ll need to dump the EDID data from the LVDS display, for this I used a free program called softMCSS, available for download here. Export the data for your monitor, and put this somewhere you can access it easily from your linux install, then flip the hardware switch back over to Stamina, and reboot into Linux. Place the EDID dump somewhere sensible (I placed mine in /etc/X11/), and then edit your xorg.conf to look similar to this (if you’re using the sony-VGN-Zseries-janitor scripts, make sure you edit the config relating to the nVidia card):

Section "Module"

Load "glx"

EndSection

 

Section "ServerFlags"

Option "Xinerama" "0"

EndSection

 

Section "Monitor"

# HorizSync source: edid, VertRefresh source: edid

Identifier "Monitor0"

VendorName "Unknown"

ModelName "Nvidia Default Flat Panel"

HorizSync 29.0 - 55.0

VertRefresh 0.0 - 61.0

Option "DPMS"

EndSection

 

Section "Device"

Identifier "Device0"

Driver "nvidia"

VendorName "NVIDIA Corporation"

BoardName "GeForce 9300M GS"

Option "ConnectedMonitor" "DFP-0"

Option "CustomEDID" "DFP-0:/etc/X11/SNY06FA.bin"

Option "NoLogo" "True"

Option "OnDemandVBlankInterrupts" "True"

EndSection

 

Section "Screen"

Identifier "Screen0"

Device "Device0"

Monitor "Monitor0"

DefaultDepth 24

SubSection "Display"

Depth 24

EndSubSection

EndSection

The highlighted lines are the key, with ConnectedMonitor telling the driver to expect a display on the internal connection, and CustomEDID providing the data it needs to communicate with it successfully (See UPDATE for details on recent drivers).

Success!! Sort of…

 

At this point, you can flick the hardware switch back to Speed, reboot and enjoy the nVidia goodness, however there are some caveats. Multiple monitor setups will not function properly at all, and when they do, they’re a pain. Because we’ve had to use ConnectedMonitor to force the internal display to be attached, X won’t see any additional displays unless it’s explicitly told about them, so if you want multiple monitors to work, you’ll need to use an Xorg config similar to the following, assuming it’s connected via HDMI (See UPDATE for details on recent drivers):

Section "Module"

Load "glx"

EndSection

 

Section "ServerFlags"

Option "Xinerama" "0"

EndSection

 

Section "Monitor"

# HorizSync source: edid, VertRefresh source: edid

Identifier "Monitor0"

VendorName "Unknown"

ModelName "Nvidia Default Flat Panel"

HorizSync 29.0 - 55.0

VertRefresh 0.0 - 61.0

Option "DPMS"

EndSection

 

Section "Device"

Identifier "Device0"

Driver "nvidia"

VendorName "NVIDIA Corporation"

BoardName "GeForce 9300M GS"

Option "ConnectedMonitor" "DFP-0, DFP-2"

Option "CustomEDID" "DFP-0:/etc/X11/SNY06FA.bin"

Option "NoLogo" "True"

Option "OnDemandVBlankInterrupts" "True"

EndSection

 

Section "Screen"

Identifier "Screen0"

Device "Device0"

Monitor "Monitor0"

DefaultDepth 24

Option "TwinView" "1"

Option "TwinViewXineramaInfoOrder" "DFP-2"

Option "metamodes" "DFP-0: nvidia-auto-select +0+0, DFP-2: nvidia-auto-select +1600+0"

SubSection "Display"

Depth 24

EndSubSection

EndSection

The problem here is that we’ve told the driver that we have two monitors connected all the time, when this is likely not to be the case. This means that you’ll have a phantom 640×480 monitor when you don’t have an external display connected. You can work around this using Disper, and executing `disper -s` to disable the external display when it’s not connected, possibly you’d want to run this as a login task if you don’t mind the flicker. To extend your desktop onto the external display when it’s attached, just use `disper -e`, and see the Disper documentation for more options.

And that’s pretty much that, until we get some love from nVidia. The configs and the EDID dump from my VGN-Z17GN/B are available in the downloads.

Link to comment
Share on other sites
jlvaio
jlvaio
Posted
Posted

http://webcache.goog...d=imvns&strip=1

 

 

 

 

A Brief History Lesson

 

There have been many issues getting Linux to work with the hybrid graphics being embedded in a number of modern laptops containing nVidia GPUs. The primary issue is being able to switch between the low- and high-power display adapters. Previously, it was possible to achieve ‘cold-switching’ in Linux (allowing a switch of display adapters by changing the position of the hardware switch, and rebooting) by disabling the Vista compatibility reported via ACPI using the kernel boot flag:

acpi_osi="!Windows 2006"

This exploited the BIOS behaviour designed to work with Windows XP, which does not support hot-switching of display adapters. The details have been extensively documented elsewhere, so I won’t go into too much detail here – there is a moderately thorough capture of the data at the Sony VAIO Z-series Launchpad group, with more discussion in the mailing lists of ongoing progress.

With the availability of Windows 7, however, a BIOS update was required to modify the DSDT tables to support the new calls that Windows 7 would use to manage the hot switching of display adapters in these hybrid systems. An unfortunate side-effect of these updates was that Windows XP was no longer supported, and the methods required to retrieve EDID data from the internal LVDS display were moved from the GPU to the BIOS for the high-power nVidia card.

The result is that booting Linux with the high-powered nVidia card enabled results in pretty vertical lines, or multiplied fragments of the intended output during boot, as the LVDS display is fed junk. Once X starts, and the nVidia drivers kick in, the LVDS display goes completely blank, as no EDID negotiation can occur. An external display will work fine, but obviously this is not ideal in a laptop. ;)

 

The State of Play (nVidia support)

 

The binary driver blob from nVidia has always been a source of contention in the open source community, due to their persistence in keeping the driver entirely closed-source, and the kernel-taint resulting from this, despite the fact that all other major display adapter manufacturers have now released specs, and open-sourced their drivers. That said, nVidia have been the go-to chipset for accelerated 3D graphics on Linux for quite some time now, but with many current nVidia-powered laptops being all but unusable with the current state of support from the binary blob, the decision is far less clear-cut, with unsupported parts being entirely useless.

The behaviour displayed by Windows 7 compatible BIOSes in (at least nVidia-based) hybrid GPU laptops is also present for some of nVidia’s standard parts, at least the G210m, and I believe a couple of other similar parts. The nouveau project have apparently made some progress in allowing the EDID data to be retrieved, however this requires kernel modification, since there is no mechanism currently for communicating this information from the BIOS… and of course the nouveau project currently doesn’t support any 3D acceleration, which is really the point here. There has been some significant lag in supporting these parts from nVidia, with drivers purporting to support them, then having support stripped in subsequent releases as the problems were identified, though it appearsthat support is on the way in a near-future driver release UPDATE1/UPDATE2.

Making Things Work Now

 

Whilst it looks like we may get real support in the moderately near future, we want things to work in the mean time. Some enterprising fellows in the nVidia forums have discerned the method for retrieving and providing the missing EDID data to the X driver, by way of Windows. Obviously this is not ideal, and may not be an option for some, but for the rest, here’s the how. This information is based solely on the Sony VAIO Z series laptops, since that’s what I have access to, but it may be relevant to laptops from other manufacturers that employ similar graphics setups.

First, you’ll want to modify your kernel boot string by removing the acpi_osi flag if you’ve been using it, and if you want to be able to see anything whilst booting, you’ll also need to remove the splash parameter, and add the following (See UPDATE for details on recent drivers):

nomodeset

This will stop the VESA driver from trying to switch to a mode that we can’t support until the nVidia driver kicks in. Also note that once the nVidia driver is initialized, you’ll lose the ability to display VTs – they’ll just show a blank screen, same for the shutdown sequence.

If you’re using the sony-laptop module modified by Eva and Norbert, and as installed by the sony-VGN-Zseries-janitor script, you’ll need to make sure the kernel is loaded with speed_stamina=3, which can be done by placing the following in a file in /etc/modprobe.d/

options sony-laptop speed_stamina=3

Next, the BIOS will need to be updated to a recent revision that contains Windows 7 support. The BIOSes of the various Z-series revisions are interchangeable, so I used the R5031M3 release, which you can download from your local Sony Support site. To make this work as we want it to, however, the BIOS needs to be modified to enable the Advanced section, allowing us to change the mode of the hardware graphics switch. Whilst the os_acpi option will likely still work, this results in garbled graphics following a reboot, making it impossible to access the BIOS, or view boot menus.

To modify the BIOS, a specially crafted EFI boot disk is required, however in all BIOS releases supporting Windows 7, EFI booting from external devices has been disabled. The only method for booting from external EFI media is to disconnect both the HDD and optical drive, however most people are probably reluctant to go to these lengths, particularly considering how difficult and convoluted it is to remove the keyboard to gain access these components. If this is you, some googling will yield pre-patched BIOSes for download. For those who like a challenge, the process for patching the BIOS is described here.

Once you’ve got your Windows 7 BIOS installed, reboot and enter the BIOS configuration by pressing F2 when the VAIO logo is displayed. You’ll notice a slew of new options under the Advanced section, so feel free to tweak a few things (enabling the VT-d option, for example), but be aware that you may seriously impair the functionality of your system by messing too much in here. The option we’re looking for is VGA Switching Policy. Set this to Static, noting that this will disable hot-switching in Windows, whilst enabling cold-switching for all OS’s

Now, flick the graphics hardware switch over to Speed and boot back into Windows. You’ll need to dump the EDID data from the LVDS display, for this I used a free program called softMCSS, available for download here. Export the data for your monitor, and put this somewhere you can access it easily from your linux install, then flip the hardware switch back over to Stamina, and reboot into Linux. Place the EDID dump somewhere sensible (I placed mine in /etc/X11/), and then edit your xorg.conf to look similar to this (if you’re using the sony-VGN-Zseries-janitor scripts, make sure you edit the config relating to the nVidia card):

Section "Module"

Load "glx"

EndSection

 

Section "ServerFlags"

Option "Xinerama" "0"

EndSection

 

Section "Monitor"

# HorizSync source: edid, VertRefresh source: edid

Identifier "Monitor0"

VendorName "Unknown"

ModelName "Nvidia Default Flat Panel"

HorizSync 29.0 - 55.0

VertRefresh 0.0 - 61.0

Option "DPMS"

EndSection

 

Section "Device"

Identifier "Device0"

Driver "nvidia"

VendorName "NVIDIA Corporation"

BoardName "GeForce 9300M GS"

Option "ConnectedMonitor" "DFP-0"

Option "CustomEDID" "DFP-0:/etc/X11/SNY06FA.bin"

Option "NoLogo" "True"

Option "OnDemandVBlankInterrupts" "True"

EndSection

 

Section "Screen"

Identifier "Screen0"

Device "Device0"

Monitor "Monitor0"

DefaultDepth 24

SubSection "Display"

Depth 24

EndSubSection

EndSection

The highlighted lines are the key, with ConnectedMonitor telling the driver to expect a display on the internal connection, and CustomEDID providing the data it needs to communicate with it successfully (See UPDATE for details on recent drivers).

Success!! Sort of…

 

At this point, you can flick the hardware switch back to Speed, reboot and enjoy the nVidia goodness, however there are some caveats. Multiple monitor setups will not function properly at all, and when they do, they’re a pain. Because we’ve had to use ConnectedMonitor to force the internal display to be attached, X won’t see any additional displays unless it’s explicitly told about them, so if you want multiple monitors to work, you’ll need to use an Xorg config similar to the following, assuming it’s connected via HDMI (See UPDATE for details on recent drivers):

Section "Module"

Load "glx"

EndSection

 

Section "ServerFlags"

Option "Xinerama" "0"

EndSection

 

Section "Monitor"

# HorizSync source: edid, VertRefresh source: edid

Identifier "Monitor0"

VendorName "Unknown"

ModelName "Nvidia Default Flat Panel"

HorizSync 29.0 - 55.0

VertRefresh 0.0 - 61.0

Option "DPMS"

EndSection

 

Section "Device"

Identifier "Device0"

Driver "nvidia"

VendorName "NVIDIA Corporation"

BoardName "GeForce 9300M GS"

Option "ConnectedMonitor" "DFP-0, DFP-2"

Option "CustomEDID" "DFP-0:/etc/X11/SNY06FA.bin"

Option "NoLogo" "True"

Option "OnDemandVBlankInterrupts" "True"

EndSection

 

Section "Screen"

Identifier "Screen0"

Device "Device0"

Monitor "Monitor0"

DefaultDepth 24

Option "TwinView" "1"

Option "TwinViewXineramaInfoOrder" "DFP-2"

Option "metamodes" "DFP-0: nvidia-auto-select +0+0, DFP-2: nvidia-auto-select +1600+0"

SubSection "Display"

Depth 24

EndSubSection

EndSection

The problem here is that we’ve told the driver that we have two monitors connected all the time, when this is likely not to be the case. This means that you’ll have a phantom 640×480 monitor when you don’t have an external display connected. You can work around this using Disper, and executing `disper -s` to disable the external display when it’s not connected, possibly you’d want to run this as a login task if you don’t mind the flicker. To extend your desktop onto the external display when it’s attached, just use `disper -e`, and see the Disper documentation for more options.

And that’s pretty much that, until we get some love from nVidia. The configs and the EDID dump from my VGN-Z17GN/B are available in the downloads.

 

anyone think there S a fix on it?

 

 

other thing:

 

i 've found this :is that talking something to someone:?

 

http://bbs.drvsky.com/simple/?t11322.html

 

 

 

 

个人提取的sony nvidia显卡亮度调节代码，基本全面

 

年前在研究旧版（for vista）的sony官方驱动时偶然发现了用来键盘调节亮度的代码，当时发现了三种代码分别对应三种显示器的硬件ID，今日研究最新版的sony官方驱 动时发现9组代码，和旧版驱动上的基本不相同，但是在我的8400M GS上测试可用，驱动修改添加代码的方法是我总结的，不知道是否完全正确，因为我只有一台sony的电脑，欢迎测试

代码如下：

[FAEIDS_630_640_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,00,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,OverrideEdidFlags1,%REG_BINARY%,36,7f,45,00,00,00,ff,ff,0d,00,00,00,41,3e,0f,42,c9,10,00,00,18,e0,2e,a0,a0,50,84,58,32,20,50,cc,0f,42,c9,10,00,00,18,00,00,00,fc,00,4e,76,69,64,69,61,20,44,65,66,61,75,6c,00,00,00,fc,00,74,20,46,6c,61,74,20,50,61,6e,65,6c,00,00

HKR,,OverrideEdidFlags2,%REG_BINARY%,36,7f,4a,00,00,00,ff,ff,0d,00,00,00,41,3e,0f,42,c9,10,00,00,18,98,3a,90,40,61,1a,c2,41,60,82,cc,0f,42,c9,10,00,00,18,00,00,00,fc,00,4e,76,69,64,69,61,20,44,65,66,61,75,6c,00,00,00,fc,00,74,20,46,6c,61,74,20,50,61,6e,65,6c,00,00

HKR,,Panel0B,%REG_SZ%,",MS_,,0045"

HKR,,Panel0C,%REG_SZ%,",MS_,,004A"

[FAEIDS_78_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,00,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,OverrideEdidFlags1,%REG_BINARY%,36,7f,fa,08,00,00,ff,ff,0d,00,00,00,15,6A,29,17,00,EA,A8,E0,99,57,4B,92,25,1C,50,54,00,00,00,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,37,2F,90,84,61,B1,1E,30,20,30,26,00,98,E6,10,00,00,18,9C,27,90,90,61,B1,1E,30,20,30,26,00,98,E6,10,00,00,18,00,00,00,FC,00,4E,76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00

HKR,,OverrideEdidFlags2,%REG_BINARY%,36,7f,25,00,00,00,ff,ff,0d,00,00,00,15,6A,29,17,00,EA,A8,E0,99,57,4B,92,25,1C,50,54,00,00,00,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,69,3A,80,18,71,38,36,40,50,32,4A,00,99,E6,10,00,00,18,BB,30,80,20,71,38,32,40,50,32,4A,04,99,E6,10,00,00,18,00,00,00,FC,00,4E,76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00

HKR,,Panel01,%REG_SZ%,",MS_,,08FA"

HKR,,Panel02,%REG_SZ%,",MS_,,0025"

HKR,,Panel03,%REG_SZ%,",MS_,,0025"

[FAEIDS_81_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,00,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,OverrideEdidFlags1,%REG_BINARY%,36,7f,4A,00,00,00,ff,ff,0d,00,00,00,15,6A,2B,1B,00,EA,A8,E0,99,57,4B,92,25,1C,50,54,00,00,00,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,40,38,90,08,62,1A,2A,40,62,C4,5A,00,B1,0F,11,00,00,18,40,38,90,D0,62,1A,96,40,62,C4,5A,00,B1,0F,11,00,00,18,00,00,00,FC,00,4E,76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00

HKR,,Panel01,%REG_SZ%,",MS_,,004A"

[FAEIDS_82_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,00,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,OverrideEdidFlags1,%REG_BINARY%,36,7f,4A,00,00,00,ff,ff,0d,00,00,00,48,37,40,38,90,D0,62,1A,96,40,62,C4,5A,00,42,C9,10,00,00,18,00,00,00,FC,00,4E,76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00

HKR,,OverrideEdidFlags2,%REG_BINARY%,36,7f,26,00,00,00,ff,ff,0d,00,00,00,48,37,DC,32,80,B4,70,B0,28,40,1A,34,5B,00,42,C9,10,00,00,18,00,00,00,FC,00,4E,76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00

HKR,,Panel01,%REG_SZ%,",MS_,,004A"

HKR,,Panel02,%REG_SZ%,",MS_,,0026"

[FAEIDS_84_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,00,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,OverrideEdidFlags1,%REG_BINARY%,36,7f,26,00,00,00,ff,ff,0d,00,00,00,48,37,DC,32,80,B4,70,B0,28,40,1A,34,5B,00,42,C9,10,00,00,18,00,00,00,FC,00,4E,76,69,64,69,61,20,44,65,66,61,75,6C,00,00,00,FC,00,74,20,46,6C,61,74,20,50,61,6E,65,6C,00,00

HKR,,Panel01,%REG_SZ%,",MS_,,0026"

[FAEIDS_MS0026_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,26,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,Panel04,%REG_SZ%,",MS_,,0026"

[FAEIDS_MS0040_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,40,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,Panel01,%REG_SZ%,",MS_,,0040"

HKR,,Panel02,%REG_SZ%,",MS_,,0040"

HKR,,Panel04,%REG_SZ%,",MS_,,0040"

HKR,,Panel05,%REG_SZ%,",MS_,,0040"

[FAEIDS_MS0045_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,45,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,Panel01,%REG_SZ%,",MS_,,0045"

HKR,,Panel02,%REG_SZ%,",MS_,,0045"

每个[ ]跟下个[ ]之间的内容即为一种代码；其中MS0045，MS0040，MS0026等能确认代表的是显示器的硬件ID（不必全部对应）其它的是否代表硬件ID不能确认，猜想应该是，即使不是也一定和显示器的代号有关。

添加亮度调节代码的方法：

首 先通过显卡硬件ID查找驱动中的控制文件对应的是哪个Section（章节）如sony的8400M GS的硬件ID为PCI\VEN_10DE&DEV_0427&SUBSYS_9008104D 其对应的Section为%NVIDIA_DEV.0427.9008.104D% = Section002

找到[ Section002]将亮度调节代码复制到该章节中，并在章节中添加上AddReg = FAEIDS_MS0040_addreg ( [ ]中的文字）

完整修改好的sony nvidia 8400M GS显卡，所用显示屏为MS0040文件如下：

[section002]

AddReg = FAEIDS_MS0040_addreg

AddReg = nv_DRS_addreg

AddReg = nv_FTS_addreg

AddReg = nv_commonBase_addreg

AddReg = nv_commonDisplayModes_addreg__02

AddReg = nv_controlPanel_addreg

AddReg = nv_global_addreg

AddReg = nv_miscBase_addreg__02

AddReg = nv_opengl_addreg

AddReg = nv_timingRestricti*****_addreg__01

CopyFiles = nv_Drs_copyfiles

CopyFiles = nv_cplSetup_copyfiles

CopyFiles = nv_license_copyfiles

CopyFiles = nv_sysDrivers_copyfiles

CopyFiles = nv_system32_copyfiles

DelFiles = nv_sysDrivers_delfiles

DelFiles = nv_system32_delfiles

DelFiles = nv_system64_delfiles

DelReg = nv_clearRegistrySwitches_delreg

FeatureScore = E6

RegisterDLLs = nv_common_registerdll__02

[section002.CoInstallers]

AddReg = nv_commonCoinstaller_addreg

CopyFiles = nv_coinstaller_copyfiles

[section002.GeneralConfigData]

MaximumDeviceMemoryConfiguration = 128

MaximumNumberOfDevices = 4

 

[FAEIDS_MS0040_addreg]

HKR,,OverrideEdidFlags0,%REG_BINARY%,7C,00,40,00,00,00,FF,FF,04,00,00,00,08,02,36,7F

HKR,,Panel01,%REG_SZ%,",MS_,,0040"

HKR,,Panel02,%REG_SZ%,",MS_,,0040"

HKR,,Panel04,%REG_SZ%,",MS_,,0040"

HKR,,Panel05,%REG_SZ%,",MS_,,0040"

 

[section002.Services]

AddService = nvlddmkm, 0x00000002, nv_nvlddmkm_serviceInstall

驱动安装时应该是可以升级安装的，如果先卸载原驱动再安装时重启后一定先确认设备管理器中的显卡上有无黄色叹号，如果有请刷新硬件待安装上系统自认的驱动重启后再装新驱动，否则可能不能调亮度

 

本修改方法适用于自行修改nvidia公版驱动为兼容sony硬件后不能用键盘调节亮度的情形，如果连修改公版驱动的方法都还不会的先自行补课后再来研究 :help:

Link to comment
Share on other sites
  • 2 months later...
  • 2 weeks later...
jlvaio
jlvaio
Posted
Posted

LOL jlvaio: Do you want to explain anything?

lol

i can t explain nothing this is is just what i've found about the craphic card issue on the web with svaio by linux user and it seems they get some fix by following this info and seems they get method and maybe i thing this could be a method maybe to take the dsdt of a svaio using ubuntu and apply them to osx because linux user seems to have a fix now and if we get the good dsdt from linux we can mirroring the success to osx and maybe understood whats wrong with..

an other god things were to make a thread with all progress with svaio like list of actual success with good kext fix listed by distro dsdt data good tools...like linux user did i think that help a lot because new user don t find good thing ,just some kind of legends..

Link to comment
Share on other sites
jlvaio
jlvaio
Posted
Posted

lol

i can t explain nothing this is is just what i've found about the craphic card issue on the web with svaio by linux user and it seems they get some fix by following this info and seems they get method and maybe i thing this could be a method maybe to take the dsdt of a svaio using ubuntu and apply them to osx because linux user seems to have a fix now and if we get the good dsdt from linux we can mirroring the success to osx and maybe understood whats wrong with..

an other god things were to make a thread with all progress with svaio like list of actual success with good kext fix listed by distro dsdt data good tools...like linux user did i think that help a lot because new user don t find good thing ,just some kind of legends..

 

http://www.bios-mods.com/forum/Thread-Vaio-VGN-AR840e-Phoenix-R2090J8-02-26-2008

Link to comment
Share on other sites
  • 2 months later...
Alexei Leonov
Alexei Leonov
Posted
Posted

Hello guys,

 

Have you ever thought about doing something similar to this post?

 

http://www.insanelymac.com/forum/topic/277765-mobility-5650-acer-aspire-7741g-no-lvds-qeci-1600x900-need-help-with-personality/#entry1869325

 

They have a similar issue with Radeon cards and LVDS. I don't have any experience with that, but thought that could give you guys some hints. If you have any new ideas, I can test them on my VPCF12M0E/B.

 

Alexei

Link to comment
Share on other sites
Funky frank
Funky frank
Posted
Posted

Here is my recent VAIO F11 boot.plist for chameleon for Snow Leopard 10.6.8 (other OSX versions maybe need another pmVersion). Notice that I enabled Apple's native CPU power management (by adding "-allowAppleCPUPM" to the kernel flags), which gives us good power saving, less fan spinning and faster turbo mode. It also gives us proper sleep mode and wakeup:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>pmVersion</key>
<string>23</string>
<key>Instant Menu</key>
<string>Yes</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>-v -allowAppleCPUPM arch=x86_64 cpus=8 busratio=12 maxmem=6135 pmVersion=23 EthernetBuiltIn=No</string>
<key>Rescan</key>
<string>Yes</string>
<key>RestartFix</key>
<string>Yes</string>
<key>GraphicsEnabler</key>
<string>No</string>
<key>Graphics Mode</key>
<string>1600x1200x32</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>Default Partition</key>
<string>hd(0,4)</string>
<key>USBBusFix</key>
<string>Yes</string>
<key>DropSSDT</key>
<string>No</string>
</dict>
</plist>

 

Hello guys,

 

Have you ever thought about doing something similar to this post?

 

http://www.insanelym...y/#entry1869325

 

They have a similar issue with Radeon cards and LVDS. I don't have any experience with that, but thought that could give you guys some hints. If you have any new ideas, I can test them on my VPCF12M0E/B.

 

Alexei

Well, ATY_init seems to be a part of the ATI drivers. So what would be the proper kext when using nvidia drivers?

Link to comment
Share on other sites
  • 2 weeks later...
Alexei Leonov
Alexei Leonov
Posted
Posted

I guess we could use Natit.kext to inject some of the dictionary entries proposed in that link. I've been trying things for the last two weekends and I guess I learned a lot in the process. I'm convinced that we have to tack two problems in sequence. First one is to properly detect an AppleBacklightDisplay without the Nvidia driver being activated. This currently doesn't happen with GraphicsEnabler=no and until it isn't fixed we cannot go to the next step which is to force the display EDID. Also, I agree with the author of that post that GraphicsEnabler=yes somehow messes up the display detection on laptops so we should avoid using it and try to inject properties instead. I could try to patch IODisplayWrangler and IONDRVSupport classes that have source code available but it's almost impossible to do that without a second computer to debug the driver (I only have my VAIO). What could be crucial to speed up things is to find a definitive guide on how VAIO displays are supposed to be detected and then try to override the detection process in the source code of that classes. Any thoughts?

Link to comment
Share on other sites
  • 2 months later...
 Share
Go to topic listing
×
×
  • Create New...