Linux on a Sony Vaio F809K Notebook
Maintained by Digital Force / Mario Trams
with substantial input from Adi Kriegisch (Debian-related issues)

Table of Contents

• Disclaimer
• Notebook Specifications (upgraded)
• General Comments
• Basic Installation
• X Server
• Linux Kernel
• PCMCIA/CardBus
• Modem
• Sound
• Hard Disk Spin-Down
• Suspending the System / Power Management
• CPU Frequency Scaling
• USB
• FireWire
• Display Brightness
• VGA and TV Outputs
• Special Function Keys (Fn-? and P1-P3)
• Miscellaneous
• Useful Links

Disclaimer

Please note that the information on this page is given without any warranty. It is based on my and Adi's knowledge and experience as well as the recommendations from other Linux users.
I'm not responsible for any damage on your hard- and/or software that may be caused when applying my hints.
However, if you find some errors on this page you are welcome to let me know them so that I can correct them.

Notebook Specifications (upgraded)

CPU:	PIII 850MHz with SpeedStep
Memory:	512MB
Graphics:	ATI Rage Mobility, 8MB Video RAM, 1400x1050 15" TFT Display
Hard Disk:	80GB IDE, fixed
Audio:	Yamaha YMF 744, Headphone out, Mic in, (neither Line out, nor Line in - only with docking station)
PCMCIA:	2xType II or 1xType III PCMCIA, CardBus support
CD Drive:	internal 8xDVD
Floppy Drive:	internal, can be removed and replaced by 2nd accu or weight safer
Others:	1x Sony iLink, 2x USB, PS2 Connector, 1x Serial Port, 1x Parallel Port, internal 56k Modem, VGA Output, TV Output, Docking Station Port

Notes:

• According the user manual, the maximum supported memory for this notebook model is 256MB (2 128MB modules). I doubted this long as the 440BX chipset supports 512MB, actually. Once I came more or less accidentally on a web site of a component reseller who offered 256MB memory modules for the Vaio F809K (INDUSYS, see also this page). Although they claim that they "found a solution for providing 256MB modules for this model", I believe these modules are nothing more than standard PC-100 SO-DIMMs. Anyways, I bought two of these "special" modules and they are working fine.


• The notebook initially came with a 30GB IBM-DJSA-230 Hard Disk. I replaced this drive with an 80GB Western Digital WD800VE. This one is really ultra-silent and brings in a big push in quality compared to the original one that has been retired for backup-purposes. The integration of the WD800VE went almost without any problems. There are just two minor odds.
  The first is that the BIOS detects the disk as a 65535MB one. But neither the original Windows 2000 (which I copied 1:1 onto the new disk) nor Linux is affected by that. The second odd is an inverted behavior of the activity-LED. That is, the HD LED is always on and goes off shortly during accesses. I don't really have a plausible explanation for this effect, but I don't care about it.
  I didn't do any benchmarks, but performance should have increased as well. The WD800VE spins with 5400RPM and has an 8MB Cache.

A General Summary of Experience (Linux-independent)

As of today (February 2005), I'm heavily using this machine for four years for development and general office purposes. It is doing its job absolutely flawlessly - just like a working horse. But actually one can expect this for the rather high price it has cost that time... Except for computing and graphics power, it does still compete very well with todays mid-range Notebooks. The stability is marvelous as well. Sometimes I had the Linux up for periods longer than half a year while carrying it around without any reboot and suspending it only into RAM. When it crashed, then it always was a stupid mistake of mine (such as removing a pc-card that shouldn't be removed when active).

A slight aging effect has been observed for the display or better said the backlight. It does not anymore provide an ultra-white but a warmer, slightly reddish white. This effect is a little bit more extreme when the display becomes activated from a cold state. But this situation is improving within seconds. As this behavior is more or less stable since maybe around 2 years, it does not seem to pose any threats.
The display can be calibrated by making use of software like kgamma (kcmshell kgamma) or by setting XServer gamma values in XF86Config/xorg.conf. This can help to improve the appearance of colors on the display. Unfortunately, it has no effect on white...

Apart from the display there has been observed a slight wearing effect with the original hard disk. This started slowly to show up some squeaking effects which is very likely a sign that the bearing is not anymore in best shape. This was also the primary reason for retiring it and replacing it by a new one.

Basic Installation

So far, I used a Mandrake 8.2 Installation. Just for the sake of history, I'm keeping the old Linux installation notes that are still available here.

For the new installation I stayed with Mandrake and installed the 10.1 version. As it was already the case for Mandrake 8.2, the basic installation is working absolutely flawlessly. So there is no need to discuss this in detail.
Adi uses Debian/testing (aka Sarge) at the moment and did not report any problems with basic installation as well. He installed his system using the Sarge netinstall image RC2 -- not tested with others but they are expected to work as well.

X Server

The X Server that is coming with Mandrake 10.1 (X.org Rev. 6.7.0) is basically working out of the box without any problems and additional modifications. Initially I made a small mistake with selecting the right graphics chip during the installation process. But this could be corrected later using xf86cfg. In any case, you should watch the device section of your /etc/X11/xorg.conf for a line

BoardName "Rage Mobility P/M AGP 2x"

Although the Rage Mobility P/M acceleration is not very high, I saw a quite significant improvement for an OpenGL application when the acceleration is enabled. By default, acceleration seems to be disabled. So the device section should contain a line like

Option "accel" "True"

If anybody is interested in it, here is my full /etc/X11/xorg.conf.

Here are some Debian-related issues regarding the X configuration issues figured out by Adi:

Debian/Sarge uses XFree 4.3 (with the last "free" patches to 4.4). When configuring the xserver-xfree86 package with the installer there was no chance to select 1400x1050. When asked simply select 1024x768 and then change this in /etc/X11/XF86Config-4.
To use the XVideo extension -- needed for full-screen mode in MPlayer -- you will need to download binary drivers from The Gatos ATI.2 drivers. Parts of those drivers are integrated with XFree86 4.4.0 and X.org -- at least the XVideo extension required for fullscreen video for example. (I could not find any details about what is integrated and what is not: The TV in and out seems to be left out, though.)
If you do not use those drivers with Debian/XFree86 you will get mplayer in fullscreen mode but with a very small picture only. You do not need to install them, but be aware of the fact that they have an enormous impact on the speed of your graphics system! To enable fullscreen video in mplayer you will need to specify -vo xv instead of the default "x11" output.

Linux Kernel

Mandrake 10.1 comes with a (perhaps Mandrake-patched) 2.6.8 kernel as well as with a 2.4.27 kernel. I decided to use the latest stable 2.6.10 vanilla kernel. Apart from the Software Suspend 2 patch (see later) I did not make any modifications for the kernel.

Here is my Kernel configuration file

Note that the initrd that is brought by Mandrake 10.1 should not be used in junction with the new kernel. I do not use an initrd at all.

These are my kernel boot parameters:

acpi=force apm=off acpi_sleep=s3_bios,s3_mode resume2=swap:/dev/hda5

Details are discussed in the sections below.

On Debian/Sarge one might choose to install 2.4.27 or 2.6.8 (either use the default "linux" or enter "linux26" on the CD's boot prompt). Both work perfect out of the box. However Adi decided to use 2.6.8.
Software Suspend (aka Hibernation) is not compiled into the Debian kernel. Suspend-to-RAM works fine with the kernel boot parameters shown above. (You need to specify acpi_sleep=s3_bios to make it work; ACPI support is required as well: acpi=force - the kernel refuses to use ACPI without the force option because the BIOS is too old).

PCMCIA/CardBus

Prior to the installation described herein, I exclusively used the pcmcia-cs package. Now I gave the kernel-built-in PCMCIA support a chance (by setting according kernel options). The pcmcia-cs kernel modules are anyways not anymore compatible with the 2.6.X kernel. There I observed some strange behavior. Although I think this behavior is normal, it is worth to be mentioned here.

The PCMCIA card manager (cardmgr) does really only watch for PCMCIA (i.e. 16Bit) cards and not for CardBus (32Bit) cards. That is, CardBus cards cannot be disabled by shutting down the PCMCIA system by service pcmcia stop. This was possible without the kernel PCMCIA support.

On the other hand, both PCMCIA and CardBus cards can be disabled/enabled with the cardctl tool (cardctl eject/insert).

Note: At the beginning of the installation experiments it has been observed that CardBus cards are not automatically recognized and initialized when the according driver (kernel module) is not already loaded. This problem disappeared later for some reason. So when you have some card and you know there is the right driver available, try to load the module manually before inserting the card.

• D-Link DFE660-TX 10/100MBit network card (32Bit CardBus)
  This one is working fine with the Digital DS21143 Tulip driver.


• Adaptec SlimSCSI 1480A Ultra-SCSI card (32Bit CardBus)
  I'm successfully using the Adaptec AIC7xxx driver (this one marked as "new driver" in the 2.6.10 kernel). This card cannot be hardly removed from the socket without a system crash. One has to soft-eject the card first (i.e. cardctl eject ...).


• AVM A1 PCMCIA FRITZ card (16Bit PCMCIA)
  This is working fine as well. Note that I'm using the "Old ISDN4Linux" instead of CAPI 2.0. The latter one appears to be available for active ISDN cards only.


• CompactFlash (16Bit PCMCIA)
  Various brands of CompactFlash cards are working fine when plugged into a socket using a CF-PCMCIA adapter card and the ide_cs driver (enable PCMCIA IDE support in the kernel configuration).

• 3COM Megahertz 10/100 [3cCFE575BT] (32Bit CardBus)
  The adapter worked like a charm from the very beginning: It is fast and well supported. Adi used it all the time.


• 3COM OfficeConnect Wireless 11g [3cRWE154G72] (32Bit CardBus)
  54MBit WLAN adapter that is fully supported without any proprietary driver. It uses the open source Prism54 drivers which are present in kernel 2.6. Great device ;-).


• Several CF-Card adapters (16/32Bit)
  worked flawlessly out of the box.

Note: In junction with the Kernel Software Suspend there appeared a problem with the PCMCIA/CardBus system after Suspend-to-Disk when ACPI was enabled. This problem could be fixed with the kernel parameter pci=noacpi. Interestingly, this was not anymore necessary with Software Suspend 2. For more about suspending the system see below.

Modem

Since I'm using an ISDN card for my internet connection, I have not yet attempted to get the internal 56k modem running.

However, Adi has reported that this modem is working flawlessly for him. Drivers can be obtained from http://www.mbsi.ca/cnxtlindrv/. Debian packages are available as well as RPMs. The post-install script tries to compile the modules. You only need to have installed the kernel-headers-2.6.8-2-686 package on Debian systems. Kernel specific headers have to be installed on all systems; the packet management software should show dependencies! (Source is available as well if you prefer to compile them all by yourself)
There are some options to make the modem quiet. This is especially useful when you finished initial configuration/debugging because the modem is rather loud on speakers. Those AT commands should work fine with the modem (according CyberTechHelp):

ATM0 -	Produce no sound at all
ATM1 -	Produce sound only during the connection phase
ATM2 -	Always produce sound whenever the modem is active
ATM3 -	Produce no dialing sounds, but produce sound until the connection is established

Sound

Note: Before you start experimenting with sound you have to disable PNP in the BIOS. To enter the BIOS setup press F2 when you see the Sony logo during the boot process. Then go to "Advanced" and set PNP BIOS from YES (default) to NO. Windows 2000 is still working with this setting.

Note: I haven't checked whether the note from above still applies for the installation described herein. But anyways, it is working in that way...

The actual installation of the sound-related stuff is working out-of-the-box and there are no special things to mention. I'm using the ALSA system and the Yamaha YMF724/740/744/754 driver.

Wait, there is one minor issue that popped up when I tried to use the console-based amixer tool for muting the master volume control. While muting went fine, unmuting did show up some strange effect. Although the volume parameters have been set to specific values, they are applied only for a fraction of a second (clearly audible) before they fall back to smaller values. It is not clear whether this is an issue of the ALSA system (or amixer) as such, or an issue of the combination of both sound chip and ALSA. Anyways, I have also enabled the OSS compatibility for ALSA and aumix is doing the job fine.

Hard Disk Spin-Down

As mentioned above, the WD800VE hard disk is really silent and there is almost no need to shut it down due to noise-reasons. Nevertheless, I actually want a 100% silent system...

The first thing to take care for are the journaling file systems (I'm exclusively using ext3 for all file systems). Journaling file systems have a so-called commit interval where they write data onto the disk. When the system crashes, only those changes that were made since the last commit are lost. By default, the commit interval is set to 5s. This is quite low. For most file systems (i.e. /, /usr, ...) I set the commit interval to 3600s (1 hour). For /home I set it to 1800s.
You have to enter the according values in the /etc/fstab. For instance my /home partition has the following fstab-entry:

/dev/hda3 /home ext3 noatime,commit=1800 1 2

Note: Setting the commit interval to such high values renders the advantages of a journaling file system almost useless!

The next thing to have a look at is the virtual memory system. There are two important parameters that influence the so-called pdflush deamon (pendant for the bdflush in linux 2.4.X). These parameters are dirty_expire_centisecs and dirty_writeback_centisecs and can be read/written via /proc/sys/vm/. These values (in 1/100s) specify the timing parameters when the pdflush becomes activated and when dirtied (modified) pages are to be written onto the disk. I set both parameters to 180000 meaning a half hour.
In strong relation with the pdflush settings is the laptop-mode setting. The laptop-mode (/proc/sys/vm/laptop_mode), when activated, writes out all dirtied pages once the hard disk has been accessed by some other activity (i.e. some by access that was unavoidable). This is a quite nice feature, actually. To activate, one has to set the laptop-mode parameter with a time value (in seconds) specifying the delay after the extra-flush occurs. I set it to 60. The recommended value is 5, but I thought this could hurt the performance for periods of high activity (in fact, I did not made any practical analysis).
I appended all the settings described above at the /etc/rc.d/rc.local so that they are made automatically during the boot process:

echo "Setting Virtual Memory Controls" echo 180000 > /proc/sys/vm/dirty_writeback_centisecs echo 180000 > /proc/sys/vm/dirty_expire_centisecs echo 60 > /proc/sys/vm/laptop_mode

Important Note on Laptop-Mode: I am administrating also another older notebook that is a little bit short of memory. Initially I set the laptop_mode to 10 there. As it turned out later, this was a mistake as 10 seconds were far too small. When larger applications got started up, this caused a permanent swapping making the machine almost dead. In the end, this is a logical behavior that can be explained easily (think about it :-). So when you see that your memory requirements are that high so that bigger portions of the swap space are used, better set the laptop_mode to larger values (perhaps 2 or 3 minutes).

Last, but not least, the actual hard disk spin-down parameter has to be set as usual. This can be added as well to /etc/rc.d/rc.local:

echo "Setting Hard Disk Spin-Down" hdparm -S60 /dev/hda

This sets the timeout to 5min. Note that the WD800VE seems to have a limit for the minimal value. I haven't checked this in detail, but it seems to be somewhere between 5 and 10min.

Note: As mentioned above, the settings described here do significantly increase the risk that data is lost when the system has hung up. Personally, I have taken to call sync explicitly whenever I am going to do some critical action such as removing/inserting a PCMCIA card or plugging/unplugging an USB device.

Note: Some programs (especially editors) tend to make implicit writes to disk followed by an explicit sync command to insure that data is really written onto disk. So it maybe that you experience disk accesses relatively often even with the special pdflush settings. The vim is such an example. When vim is started with the option "-n" these backup-writes can be suppressed. But, of course, there's no recovery possible - nothing is for free...

Debian provides a laptop-mode-tools package which is a series of scripts that care for this. It sets all those parameters and default values work quite well. They are largely the same as those suggested above.

Suspending the System / Power Management

Well, that's an interesting topic and it took me the most efforts of all. Suspending the system is very important (at least for me) because I don't want to start all my hundreds (ok, tenths ;-) of windows every time. To anticipate the result of my efforts: I got both Suspend-to-RAM as well as Suspend-to-Disk running.

Suspend-to-Disk
After some testing with the kernel-built-in Software Suspend Suspend, I decided to give Software Suspend 2 a chance. With the first one I experienced some crashes after resume and sometimes it took really long time (several minutes) to suspend the machine.
So I applied the Software Suspend 2 (version 2.1.5.14-for-2.6.10) patches to the 2.6.10 kernel and built it. In addition, the kernel needs an according boot-parameter to find the right place from where to resume. The according parameter for my installation is resume2=swap:/dev/hda5.
Apart from the kernel-related stuff I installed the hibernate script package (hibernate-script-1.03) that is provided for the Software Suspend 2 (note that these scripts are not necessarily needed). The hibernate configuration file (usually /etc/hibernate/hibernate.conf) for the Suspend-to-Disk has been adopted as following (comments have been removed):

UseSwsusp2 yes Reboot no EnableEscape yes DefaultConsoleLevel 1 Verbosity 0 LogFile /var/log/hibernate.log LogVerbosity 1 SaveClock yes Unmount /mnt/cdrom OnSuspend 25 /sbin/cardctl eject 0 OnSuspend 25 /sbin/cardctl eject 1 OnSuspend 26 sleep 1 OnResume 25 hdparm -S60 /dev/hda OnResume 25 /sbin/cardctl insert 0 OnResume 25 /sbin/cardctl insert 1 OnResume 26 sleep 1 UnloadBlacklistedModules yes LoadModules auto StopServices usb pcmcia StartServices pcmcia usb

The most important things is the OnSuspend/OnResume stuff, that might appear to be a little bit strange. The cardctl commands ensure that the PCMCIA/CardBus sockets become disabled before the actual suspend and enabled after resume. Obviously, just stopping the pcmcia service does not help and the system crashes after resume when a CardBus card is removed between suspend and resume. The sleep commands are actually a dirty hack. The first one (on suspend) avoids a long delay of the stopping of the pcmcia service. I don't know where this comes from, but stopping pcmcia immediately (i.e. with no significant delay) after ejecting the cards takes very long, and sometimes even times out without success. A slightly different effect has been observed during resume. Without the sleep there, sometimes sockets are not available due to some reason.

The hdparm command on resume is needed to restore the hard disk spin-down timeout parameter which is lost after power-down (see also the Hard Disk Spin-Down section).

Note: When there are no card(s) inserted, the cardctl will fail with an error message. In this case, the hibernate script terminates. This can be avoided by either calling hibernate with the option --force, or by redirecting the output of cardctl to /dev/null (i.e. /sbin/cardctl eject 0 >& /dev/null etc.)

Note: So far I have only used the suspension method where the state of the system is stored in the swap partition. Software Suspend 2 does also somehow support the suspension into a file which is less critical, I think (what, when the swap cannot keep its own contents plus the memory contents?).

Notes on Kernel Software Suspend: Inserting the sockets again was not necessary here. However, when ACPI is enabled, it was required to pass the option pci=noacpi so that the cards are properly configured. This is a little bit strange, however, because I'm quite sure that the Kernel Software Suspend also worked once without this setting.

Suspend-to-RAM
I'm using the same hibernate script for Suspend-to-RAM as for Suspend-to-Disk with basically the same hibernate.conf settings as described above. Just the first four (Software Suspend 2 related) lines have been replaced by:

UseSysfsPowerState mem # alternatively working: UseACPISleep 3

There is just one additional issue with Suspend-to-RAM: The display is black (switched off) after resume. This is a common problem with ACPI Suspend-to-RAM and also described in the Linux kernel documentation (Documentation/power/video.txt). The problem can be fixed by setting the kernel parameter acpi_sleep=s3_bios,s3_mode.

Note: Adi reported that the option s3_mode is not necessary for his setup (he just uses acpi_sleep=s3_bios. So you should try on your own what is working fine for you...

Ahh, yes, there was also another minor issue that the notebook does not reboot after a Suspend-to-RAM cycle. Instead, it just halts after the Linux has been shut down (one has to hold down the power button to power off the system). But, who wants to reboot...

CPU Frequency Scaling

I could not get the actual cpufreq-stuff running. The problem is that neither the module speedstep-smi nor acpi-cpufreq can be loaded. When I try to load them (i.e. modprobe speedstep-smi) this fails with the message Error inserting ... : No such device. I haven't analyzed this problem in detail, but the speedstep-smi driver should actually be the right one when following the kernel documentation.

What is working is the frequency scaling using the ACPI subsystem directly. This is done through /proc/acpi/processor/CPU0/throttling. When you are trying

cat /proc/acpi/processor/CPU0/throttling

you should receive a state list with 8 states (T0-T7). The default state is T0 (no speed throttling). The state can be changed by writing the according state number into the throttling parameter. For instance

echo 4 > /proc/acpi/processor/CPU0/throttling

Sets the state T4 (50% throttling).

This appears to work basically flawlessly. However, during my experiments I encountered some strange interaction with xosview which I'm using as monitoring tool. Sometimes this crashes very strange after the throttling has been changed (it does nothing more than consuming lots of CPU power). I crashes that hard, that it even cannot be killed anymore. Not even entering single-user mode helps here. The problem appears to be somewhere where xosview draws some information from the ACPI subsystem. I have to say that I'm using a specially patched xosview, but right now I cannot imagine where exactly the problem lies. A work-around is to close xosview before changing the throttling and then restart it again. This is quite nasty, however. Perhaps suspending xosview for the duration of the frequency change does help as well.

USB

USB is working out of the box without problems. Currently I have attached an external hard disk via USB and this is working absolutely flawlessly.

Sony iLink / FireWire

I cannot say much here, because I do not have any FireWire/iLink device. Adi reported that he got several FireWire devices working under Linux. I also guess that the support for these devices is meanwhile in a state like it is the case for USB.

Perhaps one thing that is worth to mention is that Mandrake 10.1 automatically set up a network device (eth0) for FireWire (eth1394). During my first Kernel Software Suspend experiments I figured out that this kernel module could not be removed. Because I do not need such a network device I just disabled the according driver in the kernel. However, according to Adi it is helping when the network device is shut down (i.e. ifconfig eth0 down). Then the module can be removed without any problems.

As this is an iLink connector it only has a small 4pin connector without 5V power supply the 6pin version as used by Apple and others has. So you will most probably need a 4-to-6 adaptor and a power supply which gets power either from the USB interface or from PS/2. They exist and all of them work fine.

Display Brightness

Although I'm using this functionality rather seldom, I installed it nevertheless. I'm using the spicctrl tool. spicctrl is a frontend for the sonypi kernel driver (refer also to section Special Function Keys) that can be used to control various things of the so-called Sony Vaio SPIC.

spicctrl can be downloaded from here: http://alcove-labs.org/en/software/sonypi.
Here is also a local copy: spicctrl-1.7.tar.bz2.tar.

VGA and TV Outputs

Bad News: Both VGA and TV Outputs are not working anymore that smooth as it was the case for my former installation. I'm not completely sure, but I guess that this is a problem with the X.org that is used now by Mandrake instead of XFree86. This guess becomes sustained by the fact that it is possible to activate the VGA output using atitvout when working on the console. Even more, atitvout is working for XFree86 4.3 (see below).

At least there are two work-arounds to get the VGA output working under X. The first one is to modify /etc/X11/xorg.conf. Obviously, the X server is well aware about the fact that there is a panel as well as a VGA output. There are options for enabling the panel, the VGA output (aka crt), or both (panel is default). To enable both outputs the crt option can be set in the device section:

Option "crt_display" "True"

The VGA output alone can be activated by these settings:

Option "crt_display" "True" Option "panel_display" "False"

The latter is sometimes needed when the timing parameters for the panel are not compatible with the monitor resulting in a distorted picture or no picture at all.
Of course, the bad thing with this way for activating the VGA output that the X needs to be restarted after xorg.conf has been changed. I believe, that it should be possible in principal to toggle between panel and VGA on-the-fly by reprogramming the graphics chip accordingly - just like it is done by the X server for the different configuration according xorg.conf. However, here it would be required to patch the X server. Well, so far I have been too lazy to have a look at this...

The second work-around to get the VGA output running is to reboot the notebook with an attached external monitor. This permanently enables both the panel and the VGA output.
Note: Before the same idea comes in your mind as it was the case for me: No, the trick to make a Suspend-to-Disk, attach the monitor, and resume the system is not working, unfortunately.

With the Debian/Sarge that is using XFree86 4.3 the atitvout utility works fine. Maybe this is related to the Gatos-patches mentioned in the XServersection. (Adi never used XFree86 without those patches/binary modules).
Sometimes atitvout is not able to detect attached monitors properly; so it is not easy to use it from within a script: Sometimes there is returned a message like "VBE call failed.". For subsequent calls of atitvout everything works fine. But you should not try to select other outputs when the last message was "VBE call failed.". Retry with atitvout active and/or atitvout detect until you get something else. Then use atitvout lc where l stands for LCD, c for CRT and/or t for TV output, to activate something else.
You should switch X to 800x600 before using TV-Out!

Special Function Keys (Fn-? and P1-P3)

Events on these keys can be captured and according (user-defined) actions can be carried out. To make use of this functionality you have to do the following steps:

• Enable the Sony Vaio Programmable I/O Control Device support in the kernel.
• When you want to compile it as a module (as I did), add sonypi into /etc/modprobe.preload so that the module is automatically loaded during boot.
• Get the small sonykeyd package from here: http://www.pm.waw.pl/~jslupski/vaio/sonykeyd.html
  Here is also a local copy: sonykeyd-0.2.tar.gz.
• Install everything as described in the documentation. For some reason I had to manually change the mode of some files so that they are executable. Make sure that the sonypi service becomes automatically started after booting.
• Now you can modify /usr/local/sbin/sonykey.sh so that commands can be started according your needs. You can also have a look at my sonykey.sh. The most important mappings found there are:
  Fn-ESC -> Suspend-to-RAM
  Fn-F12 -> Suspend-to-Disk
  Fn-F3 -> Mute
  Fn-F5 -> decrease display brightness
  Fn-F6 -> increase display brightness
  

Miscellaneous

I have enabled the VGA console in the kernel and set the VGA parameter to 834 (vga=834 in the according /etc/lilo.conf entry. This gives a nice resolution for the console at 1400x1050 pixels.

Apart from the things discussed throughout this website I applied also some other changes to the basic installation. However, they are mostly not specially related to this notebook and are not of public interest.

Useful Links