nVidia 260.19.29 and Sony VAIO Z

January 19th, 2011 by pdf

I’m happy to report that CustomEDID is no longer required as of this release, meaning that with a fixed BIOS, the VAIO Z can finally work on a standard Linux install with the nVidia binary blob. Yay!

Ghetto-mounting UIO card brackets for standard cases

December 13th, 2010 by pdf

UIO bracket is mounted on the back side of the card

UIO bracket is mounted on the back side of the card

In building a new NAS recently, I needed to attach a lot of drives from an SFF-8087 backplane cheaply. After a quick look around I found the Supermicro AOC-USAS-L8i – a card with a common and proven chipset – going particularly cheaply (~AU$100). At 8 ports per card I could load out the 24 ports required using three cards, at a fraction of the price for one or two of the big 24-/16-port cards. Great.

The only issue is that these cards are Universal I/O (UIO), which means the components and brackets are mounted on the opposite side of the PCB to standard cards.  That makes ‘Universal I/O’ a total misnomer in my book, since it poses two potential problems for a non-UIO chassis: the heatsinks/capacitors/etc can interfere with cards in adjacent slots that have their components mounted on the standard side (not a problem in this case, since the system they’re destined for has onboard video); and with the bracket being mounted on the opposite side, the card will not fit in a standard case.

Hunting through a box of screws I came out with a bunch ~10mm motherboard standoffs that are just the right length to mount the bracket on the standard side of the card.  There are a couple of other hurdles, but here’s how I did it:

  1. Remove the bracket (simply remove the screws)
  2. Screw motherboard standoffs directly into the now vacant holes in the PCB
    Be careful screwing in the motherboard standoff - keeping it at 90' is difficult

    Be careful screwing in the motherboard standoff - keeping it at 90' is difficult

  3. The threading on your motherboard standoff probably doesn’t match the threading on the bracket, so you may need to quickly file out the bracket thread
    Keep filing until the hole is big enough to accomodate the new screw (~1mm)

    Keep filing until the hole is big enough to accomodate the new screw (~1mm)

  4. Attach the bracket to the standoffs with screws
    UIO003

    You're good to go!

  5. Mount in case as normal

The whole process should take you no longer than about 5 minutes.  Enjoy!

Australian devs can now sell Android Market apps

October 1st, 2010 by pdf

Just announced: the list of countries able to publish paid applications to the Android Market has been greatly expanded.  Australia is now on the list, which is great, and hopefully we’ll now see an increase in the number of quality apps hitting the Market.

nVidia 256.xx/260.19.0x and Sony VAIO Z

September 29th, 2010 by pdf

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

International Android Development

September 20th, 2010 by pdf

Please see UPDATE

I’ve been an quite vocal advocate of Android as an alternative to Apple’s walled-garden of mobile applications, until I discovered today that anyone who lives outside a very short list of countries is still unable to publish paid applications.

In a time when 3rd-party applications are clearly one of the most compelling drivers for popularity in the mobile operating system market, it seems absolutely astounding that Google would exclude the majority of the world’s developers from contributing to the Android application market in a commercial capacity.

Clearly this stems from deficiencies in Google Checkout’s ability to cater for international merchants, but there appears to have been no forward movement on that front for at least a year now, and no meaningful response from Google as to what, if anything, is being done.  There are numerous long-running Google Groups threads requesting such, and local online media has even run the story.

With Google Checkout clearly being the culprit for hampering quality application growth, and alienating developers worldwide, and with an obvious lack of commitment from Google to rectify the problem on that front, surely it’s time for them to admit that they’ve failed to resolve it, and to consider the extremely simple option of allowing Paypal for international developers (much as that would stick in their craw)?  Surely it’s the lesser of two evils to vastly improve the available application pool, and appease the world’s developers, by allowing payment via a competitor, since there is no revenue coming from these regions in any case, and apparently no effort being imparted to alter this?

Discovering this information made it suddenly obvious why there are so few quality region-specific applications in my area (Australia), and this in turn clearly proves the point that this stifling of commercial creativity is bad for the platform end-to-end.  Developers suffer, since they can’t make a living, and end-users suffer since the Android market lacks the content available in other application markets.

This has of course also completely killed a number of projects I had prototyped.  This is how not to do an application store.

Create a new git branch on a remote repository (and other helpers)

August 4th, 2010 by pdf

git-rbranch

Managing remote git branches is a pain in the rump – I can never remember the sequence (and have no desire to).   So, I created the following small script to handle it automagically.

#!/bin/sh
# git-rbranch

if [ $# -ne 1 ]; then
         echo 1>&2 Usage: $0 branch_name
         exit 127
fi

branch_name=$1

check_return() {
	if [ $1 -ne 0 ] ; then
		exit $1
	fi
}

if [ -n "$(git branch |egrep "^[[:space:]*]*${branch_name}\$")" ] ; then
	echo "Local branch already exists, cannot continue"
	exit 1
fi

if [ -n "$(git branch -r |egrep "^[[:space:]*]*${branch_name}\$")" ] ; then
	echo "Remote branch already exists, checking out"
	git checkout --track -b ${branch_name} origin/${branch_name}
	check_return $?
	git pull
	check_return $?
	exit 0
fi

git push origin origin:refs/heads/${branch_name}
check_return $?
git fetch origin
check_return $?

git checkout --track -b ${branch_name} origin/${branch_name}
check_return $?
git pull
check_return $?

Simply place it on your path somewhere as git-rbranch (ie – /usr/local/bin/git-rbranch) and call with:

git rbranch <branch_name>

This will create the new remote branch, check it out and pull the changes, the only caveat is that the branch can’t exist locally.

git-info

I also find Duane Johnson’s git-info script useful for quickly grabbing the vital stats for a repo:

#!/bin/bash

# author: Duane Johnson
# email: duane.johnson AT gmail.com
# date: 2008 Jun 12
# license: MIT
#
# Based on discussion at http://kerneltrap.org/mailarchive/git/2007/11/12/406496

pushd . >/dev/null

# Find base of git directory
while [ ! -d .git ] && [ ! `pwd` = "/" ]; do cd ..; done

# Show various information about this git directory
if [ -d .git ]; then
  echo "== Remote URL: `git remote -v`"

  echo "== Remote Branches: "
  git branch -r
  echo

  echo "== Local Branches:"
  git branch
  echo

  echo "== Configuration (.git/config)"
  cat .git/config
  echo

  echo "== Most Recent Commit"
  PAGER=/usr/bin/less git log --max-count=1
  echo

#  echo "Type 'git log' for more commits, or 'git show' for full commit details."
else
  echo "Not a git repository."
fi

popd >/dev/null

Place it on your path as git-info and call with:

git info

git-keep

Finally, a quicky to ensure empty directories make it into git by placing blank .keep files in them.  This will not be to everyone’s taste, but it works when you need it.

#!/bin/sh
dir=$1
if [ -z "$dir" ] ; then
	dir=.
fi

for dir in `find $dir -type d -empty |grep -v '\.git' |grep -v '\.svn' |grep -v '.hg' ` ; do
	touch "${dir}"/.keep
	git add "${dir}"/.keep
done

Place on the path as git-keep and call with:

git keep <dir>

Where <dir> is the top-level directory you want to store dirs from. If omitted, will use the current dir.

Download

You can download the files here:

git-rbranch

git-info

git-keep

Fluid jqGrid

May 4th, 2010 by pdf

The jqGrid plugin for jQuery is an excellent method for displaying and editing tabular data, but has a shortcoming – by default it’s size is fixed.  This presents some problems for sites with fluid layouts, or dynamic display elements.  There are posts elsewhere describing how to make it respond to window resize events, however a recent project had dynamic content that adjusted the size of various page elements.  To make jqGrid respond to resizes of it’s parent element, an alternative approach is required.

This method requires installation of the jQuery resize event plugin, which provides resize events for all elements, rather than just window.  Follow the instructions at Ben’s site to install the plugin before continuing.  Once the plugin is installed, add the follow functions to your page:

function jqgrid_fluid_resize(grid, gridParent) {
  grid.setGridWidth(gridParent.width());
}

function jqgrid_fluid_trigger(grid) {
  jQuery.resize.delay = 100;
  gridId = jQuery(grid).attr('id');
  gridParent = jQuery('#gbox_' + gridId).parent();
  gridParent.bind('resize', function() {
    jqgrid_fluid_resize(jQuery(grid), gridParent);
  });
};

Then attach jqgrid_fluid_trigger to the loadComplete hook in jqGrid, and your grid will automagically resize when the containing element does.

I should probably extend the jqGrid object with these functions rather than just sticking them in the global space, and I’ll get to that, but I wanted to dump the info here before I forget.  You can grab the code here.

I don’t write JavaScript, so if you want to tell me how this would be better, leave it in the comments.

nVidia drivers 195.36.03, no joy

February 5th, 2010 by pdf

I had hoped that the fix in the works as reported in the nVidia forums, and released in 195.36.03 for poor EDID results on some mobile display adapters would result in functional graphics for dual-GPU systems with Windows 7-compatible BIOSes, but alas it has not done anything to improve the situation.  I’ll investigate the status of G210m support, and see if any progress has been made there, as I believe that to be the closest related issue.  Will update this entry when I have further information.

Dual boot Linux and Windows 7 on Sony VAIO Z

January 30th, 2010 by pdf

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.

Open for Business

January 27th, 2010 by pdf

It’s been a long time coming, but it’s finally time to kick this site off, joy!

(Okay, so there’s no actual business being done ;-) )