Linux on the Sony Vaio VGN-S260

Mike Shade
contact at: mikeshade at

This page is listed at:
TuxMobil - Linux on laptops, notebooks, PDAs, and mobile phones
homepage @
Last updated September 19, 2005

I purchased my Sony Vaio VGN-S260 in December of 2004. My intent was to install a distribution of Linux suitable for use as an internet client, multimedia center, and various other day to day tasks. I wanted prolonged battery life, with a higher powered mobile processor and a good amount of RAM. This document serves to outline information relevant to installing and configuring all the devices standard on this light laptop.

The hardware specifics are as follows:

Reference files:
My xorg.conf
Kernel config file for linux- on the Vaio S260. A quick 'n dirty power management script utilizing ACPI and spicctrl.
Kernel now running on my Vaio. No changes necessary.

I should note that these steps will work on most of the VGN-S series Vaios. Sony hasn't changed much of the basic hardware through the revisions. The latest models use nVidia graphics adapters instead of the ATI Radeon Mobility series, and previous models use ipw2100 (wireless-b) instead of the Intel 2200B/G the newer models include.

My main concerns were setting up wireless support, 3D acceleration, and powersaving features of Intel's speedstep processor design. I chose Slackware 10.0 as the initial distro, but have been through several others, including Ubuntu, Gentoo, Suse 9.2 and now Slackware 10.1. Nothing too dramatic was required on any of these distros to achieve functionality from the important devices. I have not tried to use Firewire, Bluetooth, or the Sony Memory Stick as I have no hardware which utilizes these functions.

Wireless Support

The Intel 2200B/G device is supported out of the box on some distributions. Ubuntu was one of these. Suse 9.2 also includes drivers, but they're not available until the system is installed.

If you're running a distribution which doesn't include these drivers in the base install, (such as Slackware), you'll need to grab the drivers and matching firmware versions from You'll need to compile these drivers against a 2.6.x series kernel, as 2.4 lacks some features required by the driver. That means you may also have to install and/or compile a new kernel from or from your distribution vendor. I used a vanilla 2.6.x series kernel from Outlined below are the options you'll need to configure your kernel with to include support for the ipw2200 driver as well as support for security-enhanced wireless networks.

Those are all the options needed to succesfully build and load the driver.

Now, you'll need to extract the firmware to the proper location so that hotplug can find it and load it with the driver module. The location of the firmware can vary from distro to distro, so you should check /etc/hotplug/firmware.agent for the correct location on your distribution. On Slackware, the directory mine is installed to is /lib/firmware.

Now that the firmware is in place, we may build the ipw2200 driver. Extract the tarball and change to the source directory. Run make install and the driver should compile and copy to the correct location, assuming your kernel is configured properly and running. Execute modprobe ipw2200 and the driver should have loaded correctly. To test whether it is working correctly, use the command iwconfig. You should see a listing for ethX and a summary of the wireless extensions. If you see no wireless extensions after having loaded the module, check the output of dmesg for any error messages. If your firmware isn't loading correctly, double check that it's in the right location. If it's in the right location, you might want to try downgrading to a previous version of the firmware. That has solved some issues I've seen.

After the module is loaded, you can configure it via dhcp with dhcpcd ethX where X is the interface number you see listed by iwconfig with wireless extensions. Use your distros setup to configure it to load automatically at every boot. The way I do this is to add an entry to /etc/modprobe.conf like this:

alias eth0 ipw2200

Then I use Slackware's netconfig to setup eth0 to be configured by dhcp. Consult your distribution's help files on how to do the same.

X Windows and 3D acceleration

The S260 has a very nice 13.3 inch LCD which displays a native widescreen resolution of1280x800. 3D support can be enabled for our Radeon Mobility 9200 with either the open source, kernel-included 'radeon' module, or with ATI's proprietary binary drivers. First, let's get X setup to work with the touchpad and widescreen resolution.

We should start with a pretty bare xorg.conf file. Running the command xorgcfg should provide us with just what we need: a simple, working xorg.conf on which to base ourselves. First, take a look under the InputDevice section for the mouse:

		Section "InputDevice"
			Identifier	"Mouse0"
			Driver		"mouse"
			Option		"Protocol" "auto"
			Option		"Device" "/dev/mouse"

This will work fine for our touchpad. On later 2.6.x series kernels, however, the synaptics touchpad driver has been added. For some strange reason, this driver will recognize our pointer device as an ALPS touchpad (which it is), but then it will disable hardware tapping. The way I prefer to have the touchpad setup is with hardware-tapping enabled. It seems to provide a more natural feel for tapping to drag or click. As a work-around for this behavior, we can add a setting to lilo.conf or grub to pass an option to the kernel on boot. My entry in lilo.conf is this:

append = "psmouse.proto=imps"

This tells the built-in Alps driver to "forget it", basically, and we achieve the same functionality as we did in previous kernel versions. (NOTE: If you're looking to enable the scroll wheel function on the touchpad, you won't want to add this. Instead, we'll use the synaptics driver and add some custom definitions in xorg.conf. I prefer the more basic functionality, however.)

Next, let's take a look at our "Monitor" section. Nothing special required here, either:

		Section "Monitor"
			Identifier	"Monitor0"
			VendorName	"Monitor Vendor"
			ModelName	"Monitor Model"
			Option		"dpms"

VendorName and ModelName are probably not important, but I've always seen them listed, even as something generic like above. You'll notice that there are no ModeLines or refresh settings. Xorg is intelligent enough to figure those out on the fly.

Now, to check out the "Device" listing for our Radeon.

		Section "Device"
			Identifier	"Card0"
			Driver		"radeon"
			VendorName	"ATI Technologies Inc"
			BoardName	"Unknown Board"
			BusID		"PCI:1:0:0"

After using xorgcfg, it had selected the 'ati' driver instead of 'radeon'. I made that simple change to enable 3D support. If you'd like to try the proprietary ATI fglrx driver, there are some important things to note:

The next section to look at is the "Screen" portion of our xorg.conf. Again, with newer versions of X, not much needs to be done here. This bare minimum should be all that's needed:

		Section "Screen"
			Identifier	"Screen0"
			Device		"Card0"
			Monitor		"Monitor0"
			DefaultDepth	24
			SubSection	"Display"
				Viewport	0 0
				Depth		24

Lastly, let's make sure users are able to access our 3D hardware:

		Section "dri"
			mode 0666

Type startx and try it out. I think you'll like what you see.

I ran into a little bit of a snag with 3D capabilities. I'd run glxgears, or glxinfo, and X would revert to indirect rendering. Hint -- not what you want. I used xhost + to disable access control momentarily and ran the commands again. They ran fine; direct rendering: yes. Knowing I already had the "dri" section in the xorg.conf, I wasn't sure what the issue was. Turned out that /dev/dri/card0 was set with 660 permissions, owner root, group video. This meant that my user, mike, was unable to access it without being added to the 'video' group or chmod'ing /dev/dri/card0 to 666. I chose the former route and ran usermod -g users -G wheel,audio,video mike to rectify the situation.

Also note that tmpfs should be mounted on /dev/shm as POSIX shared memory access is required for some 3D apps (ATI fglrx driver is one of these situations.) Check fstab and if that's not present, add this:

		tmpfs		/dev/shm	tmpfs	defaults	0 0

And that should be that.

Power Saving Abilities

The Pentium M in our machine is scalable from 600Mhz to the full-on 1.7Ghz via Intel's speedstep technology and ACPI. We can also adjust the screen brightness of the LCD; this is a huge factor in battery longevity. Our Vaio also has a hardware switch to turn the Wireless card on and off -- another good thing to do when not in use.

In order to take advantage of some of these features, you may need to recompile the kernel. The relevent bits are the 'sonypi' driver, which allows us to control the screen brightness and other vaio specific settings. In addition to the sonypi driver, you'll want to go under 'Power Management Options' in the kernel configurator.

Here you'll want to enable the following items:

These settings will allow us to utilize most of the powersaving features of the Pentium M. Now all we have left to do is setup some way of controlling the consumption of power.

The most basic of ways to control processor speed, or 'power profile', is by talking directly to files in /proc or /sys. Root can echo a setting to change to the relevant virtual-file and the computer will respond accordingly. Files of interest are:

If you take a look in scaling_available_governors within the /sys/.../cpufreq directory listed above, it will tell you we have a choice among 'ondemand conservative powersave userspace performance' (if you configured your kernel like mine). The 'conservative' power governer was added with the 2.6.12 kernel release. It works like ondemand, but uses a more graduated algorithm to set intermediate frequencies as well. To set this to the desired option of your choice manually, echo the desired governor to scaling_governor, like this:

echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

KDE includes a nice little app, klaptop, which can control all of these functions from the system tray. It can also control screen brightness via the sonypi driver. Another controller of screen brightness, called spicctrl, can be obtained from This is a command line utility useful for various tasks specific to the sonypi driver. You can also incorporate the use of it into startup scripts to obtain desired operation. I also wrote a quick and dirty script which incorporates spicctrl and ACPI power management to help with setting the values more easily. To run this as a user, you'll need to change the permissions to the scaling_governor entry under /sys (shown above) to 666.

Sound Support

The onboard Intel AC'97 codec is supported by the snd-intel8x0 alsa driver. I've found that it's important this is compiled as a module, rather than within the kernel.

Under the kernel configurator, it is listed under device drivers -- sound -- alsa -- pci devices -- Intel/SiS/nVidia/AMD/ALi AC97 Controller. Enable this a module. After you build and boot the kernel, you should be able to run alsaconf and have it automatically set your card up. NOTE: On this particular laptop, the sound is a little quirky. You'll need to adjust settings with alsamixer and turn ON or OFF the "External Amplifier" channel. I would suggest playing a sound sample with mpg123 or xmms while you are playing with the settings to tune it to your liking.

Send any corrections to mikeshade AT gmail DOT com

Index---S260 Main---mshade main