|
 |
 |
|
Linux on a Sony Vaio F809K Notebook
|
|
Maintained by Digital Force / Mario Trams |
with substantial input from Adi Kriegisch (Debian-related issues) |
F809K = F690 ? I'm not completely sure, but I guess the F809K is the European
version of the F690. At least the F690 is not available in
Europe but has exactly the same specifications as the F809K.
So the things described below might also be applicable for a
Vaio F690 model.
Table of Contents
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.
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.
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.
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.
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
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.
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).
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.
The following PCMCIA/CardBus cards are working fine for me:
- 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).
Adi has been using the following cards with success:
- 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.
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 |
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.
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.
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...
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 is working out of the box without problems.
Currently I have attached an external hard disk via USB and this is
working absolutely flawlessly.
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.
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.
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!
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
Notice that all this stuff is only working when ACPI is enabled!
Sometimes it might be necessary to use fnkeyinit=1 when loading sonypi.
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.
Here are some notebook-specific links that may help to solve your problems:
http://www.linux-laptop.net
http://www.linux.org/hardware/laptop.html
http://www.mobilix.org/
|