Please see UPDATE

A short addendum to my previous post to say that nVidia drivers numbered 256.xx allow the VGN-Z (and possibly others) to work without having to use the ConnectedMonitor option.  This is a great boon in a multi-monitor scenario since you don’t have to have a phantom monitor when your external is unplugged.  Additionally, nomodeset, and disabling of splash in GRUB are no longer necessary, however the xorg CustomEDID option is still required.

Unfortunately, 260.19.0x introduced a regression, actually hanging my VAIO, and certainly not presenting any working displays, so stick to 256.53 for now.

It’s worth noting that the regression was introduced because nVidia are actually trying to rectify the problem of detecting the internal displays of various problematic laptops (particularly VAIOs), so there is hope that we may be able to do away with the CustomEDID nonsense too.

From the nV News forum, regarding 260.19.0x:

The driver isn’t detecting the laptop’s internal panel. 260.19.06 has fixes for panel detection on a number of quirky laptops, but apparently it’s not working for you…

– AaronP

There’s a bug filed on panel detection problems on some VAIO laptops, so hopefully that’s the same issue and it’ll be fixed in a future release. For future reference, the bug number is #681330.

– AaronP

Another trick learned from that thread is that we can get EDID data from /proc.  So, an updated xorg.conf might look like:

--- xorg.conf	2010-09-29 10:44:16.996719950 +1000
+++ xorg.conf.new	2010-09-29 10:50:01.796759876 +1000
@@ -1,41 +1,38 @@
 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         "CustomEDID" "DFP-0:/proc/acpi/video/DGPU/LCD/EDID"
     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

Note: The details below have only been tested on the VGN-Z series, and may not apply to the newer VPC-Z hardware

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.