VAIO Power Management

A few tips and a small script for how to change your Sony VAIO backlight under Linux

Most of the time, Wildfire, my Vaio PCG-FX105K runs on AC on the desk and is connected directly to the Internet through the winterwolf.co.uk LAN, but occasionally shi does get to travel around the country (and even abroad when I get the chance). When running on battery rather than AC, power management becomes quite important. Until recently, I'd had nothing but trouble getting any form of power management to work.

Here's a quick run-down of what I've done to get power management working under Linux. Although this is for the PCG-FX105K, it should work for all VAIO laptops (PCG-[whatever]) and possibly even for VAIO desktops (PCV-[whatever]). Particularly old VAIOs may have problems with the ACPI stuff, and if that's the case or you experience any other problems, please do contact me and I'll try to help you out if I possibly can. Most of the things here have been seen to work on a PCG-FX805, and comments have been added where differences were noted.

APM/ACPI Kernel Support

The major component for power management is either ACPI or APM. I don't have any experience of older VAIOs that may use APM in preference to ACPI, so if you do have one of these machines then please let me know. I'll try to help you along if you have problems, but it's not wasy without ever having used something like that.

Current Linux kernels have support for ACPI as standard, but I'd definitely recomment the current ACPI4Linux patches to be applied to the kernel. The new implementation seems a lot more stable across more platforms. It also fixes some USB problems I've been experiencing on my VAIO, but breaks USB on my desktop machine. Do let me know if using this patch causes USB problems and I'll see if I've come across them myself before.

There is a patch against 2.4.19 in the Linux Software section of the site. If you're using a different kernel version to this, you could try checking the ACPI4Linux homepage for patches that suit you.

Important: If you are also planning to apply the software suspend patch to 2.4.19, please read the section on software suspend below before applying this patch.

If you've never applied a patch before, the basic procedure is to move to the root of the kernel source and use a command similar to this:

$ zcat /path/to/patchfile.gz|patch -p1

All being well, the patch will apply flawlessly.

When configuring the kernel, in the General Setup section turn on "ACPI support" and turn off "Advanced Power Management BIOS support". There will also be an ACPI section under here, and you can choose to compile in (or compile as modules) whatever you'd like. In case you're interested, this is what I have compiled in under the "ACPI Support" section:

ACPI Support
AC Adapter
Battery
Button
Fan
Processor
Thermal Zone

Recompile your kernel and boot the new one, and all being well you system will start up and provide the ACPI Interface to you. You can check by running something like "dmesg|less" and looking for lines containing "ACPI".

BIOS Problems

If your VAIO's LCD stops updating at the point where ACPI is being initialised, but the system appears to boot normally apart from that, you're probably suffering from the same problem as I was the first few times I tried this. The solution was to get a BIOS update from Sony. Previously, this was a bit of a problem, but they seemed to have quite a varied selection when I went to have a look.

If you need a BIOS update, you should be able to get one by going to VAIOlink, clicking "VAIO User", entering your product ID code if prompted and then going to the Downloads section under "Other Support Options".

There are quite a few people no longer needing Microsoft products, but when they come to updaing the BIOS are having problems finding a way to run the flash utility. Marianne Promberger, a reader of this web site has kindly provided a description of how they worked around this problem:

Create the boot image:

# Download BIOS update exe and unzip it: wget http://winterwolf.co.uk/software/bios/vaio/R0243U0.exe unzip R0243U0.exe # Download boot disk image: wget http://www.fdos.org/bootdisks/old/FREEDOS.IMG (copy here) # mount boot disk image mkdir freedos sudo mount -o loop FREEDOS.IMG freedos/ # copy all files unzipped from the BIOS update exe to the same directory: sudo cp r0243u0/* freedos/ # unmount freedos sudo umount freedos # Copy the now modified freedos boot disk image onto the floppy: dd if=FREEDOS.IMG of=/dev/fd0

Flash the BIOS: Insert floppy and turn on computer, laptop boots from floppy. Answer no to all Y/N questions. (Answering Y or just ENTER is no good; tried this first, but this gives "Cannot flash when memory managers (EMM386) are present"). End up at DOS command prompt.

# list files on floppy dir

To flash the BIOS, I first tried:

PHLASH /B=PLATFORM.BIN BIOS.ROM

This started working (first asks: Do you want to flash the BIOS? Y/N) then suddenly the computer shut down. Removed floppy and hit power button. Got a SONY screen but nothing happened. uh-oh. Hit power button to turn off laptop, reinserted floppy, turned back on Booted from floppy again. Again answered N to all Y/N questions

PHLASH BIOS.ROM

Again started up fine and did a bunch of stuff, then suddenly shuts down.

Removed floppy, turn laptop back on. Boots into Zenwalk. Doesn't shut down properly, (goes down to halt but screen is still on). I think this might have been present before BIOS update. Turn back on and at the SONY screen, hit F2 to get into BIOS. Information displays R0243U0 as the BIOS version, so it seems to have worked. Shutting down from this BIOS screen works.

Installed Xubuntu 7.04, rebooted a couple of times without problems. Shutting down works fine and even Suspend works.

Software Suspend kernel support

As far as I am aware, most VAIOs either do not have any form of hardware suspension or it simply does not work properly with Linux. This is certainly true for the PCG-FX100 and PCG-FX800 series of VAIOs. Software suspend get around this problem by allowing the machine to be suspected into the swap partition. It's a similar idea to Windows' idea of using a hibernation file, but the whole system doesn't always need writing, resulting in potentially much faster suspend and resume times.

You'll first need to apply the Software Suspend patch for your kernel version. The Linux Software page contains a patch against 2.4.19, but if you're after a patch for another kernel version, the official website may help. Don't forget to enable software suspend (in the general setup section), then rebuild your kernel.

You'll also need a swap partition that is at least the size of your physical memory. If you use more than one swap parition, that's fine, just make one of them at least the size of your physical ram. Then reboot to your new kernel, passing the parameter resume=/dev/swappart to your kernel (eg. "resume=/dev/hde1"). swsusp should inform you of its presence during boot, and you should be able to suspend your machine as a trail by executing "echo '1 0 0'>/proc/sys/kernel/swsusp". On your next reboot it should just carry on where it left off.

There are some pieces of hardware that really don't like software suspend, but luckily these are few and far between. The Promise PDC20276 in Scrat is a prime example of one of these. Less fortunately, there are quite a few devices that don't like software suspend, but won't cause nasty crases if you try. The two UHCI USB modules "uhci" and "usb-uhci" are good examples. USB will not work and you'll ket timeout messages until the module is unloaded and reloaded, at which point everything will work fine again.

If it's annoying for you to do that each time you resume, try creating a small shell script. If should unload problem drivers, Write "1 0 0" to /proc/sys/kernel/swsusp, sleep 3 seconds or so to make sure the resume is finished, the reload your drivers. Obviosuly, for this to work properly, all problem devices must be built as modules.

Please note that the Software Suspend and ACPI patches overlap in 2.4.19. To apply them correctly, first patch the kernel with Software Suspect, then patch with ACPI. At three points during the patching for ACPI, you will be told that a reverse patch is detected. Tell it not to reverse the patch and try again, but say that it should try to apply the patch anyway. You will get three failures marked, but since the cahnges are already present from Software Suspect, that's not a problem. You can now build a kernel with both software suspect and patched ACPI support built in.

Sony PI and Backlight

I'm not too sure if you're supposed to be able to do things like alter the backlight brightness through ACPI, but you can't do it on Wildfire. Newer VAIOs seem to support changing the backlight brightness in hardware (just use Fn-F5 for Up and Shift-Fn-F5 for down, this certainly works on the FX800 series). If not, you'll certainly be able to do it using the Sony PI support. Support is included in newer kernels, and can be compiled in by turning it on in the character devices section.

Once it's in there, you'll need a program called spicctrl to talk to the PI to read and write settings. It's in current Debian repositories, or alternatively you can get it from here.

I've also made a little script called sblctrl which is available from the Linux Software page. It takes a single parameter of either "up" or "down" and either increments or decrements the backlight respectively. It does not increment or decrement linearly to do some basic compensation for the eyes logarithmic response to intensity. The script is also cyclic, so that if you are at the brightest setting and try to turn the brightness up it will be set to its dimmest operation mode and vice versa. It's inteded to be bound to a key combination in X window managers, but can be used standalone or called by some other method.

It seems that root access is required for reading or writing the Sony PI. I have get around this by making spicctrl suid root. This is probably insecure, but I have quite a high level of contorl of who access Wildfire so I'm not too bothered. It should be a consideration yourself, however, if security is important.

ACPI software support

Just building ACPI support into the kernel will enable CPU idling by ACPI and basic CPU thermal protection, but some events require external handing, such as response to pressing the power button. For this, I'd recommend acpid, which is available in Debian or from the acpid SourceForge site. You could use this to shut down (or software suspend, see above), the computer on pressing the power button, for example. All ACPI events should be handlable by acpid, all you have to do is decide what you'd like them to do.