This baby is my precious :-P. Seriously! A real gem. Sony is one of the few manufacturers to pack so much heat in such a small package. Carbon chassis, LED backlit X-brite LCD, Core 2 Duo ULV, an abundant 2 GB of RAM, draft N wireless, and - the icing on the cake - an SSD :-).

Hardware specifications

• Intel Core 2 Duo U7600
• 2 GB of DDR2 533 Mhz SO-DIMM
• 11,1" LED backlit TFT
• Intel GM 945 chipset with onboard GPU
• IPW4965 a/g/n miniPCI wireless LAN with hardware switch
• Marvell Yukon Gigabit LAN adapter
• 32 GB 1.8" SSD
• Infineon TPM (Trusted Platform Module)
• Integrated fingerprint reader (haven't checked the details yet)
• built-in Bluetooth
• SD/Memorystick card reader
• FireWire 400 4-pin connector
• 2x USB 2.0

Setup
Sony has no reputation as being Linux-friendly and with this laptop it really shows. I've spent a lot of my precious time on getting it to work - but heck it paid off :-). I will only be covering the odd parts here, I trust when you read this you are familiar with setting up basic stuff like cpu frequency control and stuff - bref, anything common to configuring laptop hardware.

Fn keys
Here Sony lives up to its reputation. Whereas all my Fn keys worked out of the box on my HP laptop - probably because the controls were hardware, on this beauty none of them actually work (at least not with a 'basic' WM like Openbox). Hal is supposed to get them to work but I guess you'd need a more comprehensive WM or DE to interface with it. You can have ACPI events generated by the Fn keys by using the Sony laptop driver. This only provides an interface, though; you still need to make ACPI aware of what it can do with those keys (and that's where the tinkering comes in). Either you patch the handler.sh script (like I did, but that's the filthy way) or you add new event files in /etc/acpi/events. The patch handles most relevant Fn key combinations (switching on the external VGA with xrandr still has to be implemented). You can find all relevant code and scripts linked at the end of this article.

Multimedia keys
Sony sells this laptop with shiny, tiny metallic multimedia keys. Most of them generate xev events so you can configure them through Xmodmap (and Openbox then manages the keybindings for you). The Audio/video and eject buttons generate ACPI codes (and no xev events), just like the Fn keys. I bound the multimedia keys to mpc, mpd is always running in the back anyways. This way I have a nice way to control my music player directly (play/pause, stop, forward, rewind). The audio/video key is configured to launch a fullscreen VLC instance, always nice to watch my favourite series or a movie :-). The eject button, well... That one is mapped to the eject command, surprisingly. Sony's ravishing design has one (small) drawback: it makes some concessions on usability. The optical drive tray's button is too tiny comfort; having an eject button at the front of the laptop is quite handy.

SSD
The SSD, a PATA 32 GB Samsung 1.8" (ref. MCBOE32GQAPQ), gets mistakenly detected as connected by a 40-wire cable (while it's actually plugged in through a ZIF socket), and libata correspondingly sets the UDMA speed to 33 MBps. This puts a serious strain on the drive - hdparm reports a whopping 26 MBps throughput. Quite annoying when you know this thing can almost do double.
This is a known flaw of libata, as far as I can tell it already exists since the 2.6.19 kernel (!), and there have been attempts to fix it. For now there are two solutions - either switch back to the old ide layer, or force libata to treat the device correctly and switch to higher speeds. According to its data sheet this SSD runs in UDMA 4 mode.
Scavenging the mailing lists I managed to resurrect a patch that allows you to override the libata detection. If libata is compiled in statically you need to add
libata.force_cbl=80
as a kernel boot parameter. If you load libata from initrd, or after boot, you need to pass
force_cbl=80
as module parameter. After forcing libata to treat the device in the correct UDMA mode, hdparm reports a stunning 46 MBps :-). Not bad for a laptop disk huh!

Xorg
This proved to be quite the bitch. The eternal dilemma: the i830 driver more or less works out of the box with the native resolution (it takes a configuration file and xrandr to beat it into submission though), but it does not support xrandr, thus making activating the VGA out a real mess.
The intel driver (as we speak it's at 2.2.1), on the other hand, stubbornly sticks to 1024x768. I got hold of a patch for it that makes it use the video BIOS modes instead of the probed ones - this makes the driver (out of the box - yay) go with 1366x768. This patch is quite old (dates from a few months before the last stable intel driver got released) so I guess it won't be in the stable release anytime soon; 2.3.0 seems to be around the corner, curious if that will fix it.
This patch allows me to run the display at native resolution - no need for xrandr anymore to adjust it after starting X, and I can use the external VGA output without messing up my Xorg layout :-). Haven't gotten around yet to configure the hotkey (doesn't work out of the box), I'll probably only do that when I really need it :-P.

Suspend to RAM
Not sure if I'll ever implement suspend to disk on this one, 2 GB of swap on a 32 GB is a bit much if you ask me. Suspend to RAM works just fine with pm-utils; the virtual terminal hack is still needed though:

#!/bin/bash
case $1 in
suspend)
chvt 1
;;
resume)
chvt 7
;;


Camera
The camera in this laptop is provided by Ricoh (model R5u870, USB ID 05ca:183a). The camera model is VGP-VCC7 (by Sony I presume) and is listed as supported - the driver tarball has also a corresponding firmware file in its firmware dir, it is supported out of the box. The 0.11.0 version builds fine against the default Arch kernel (2.6.24), but by now I am running 2.6.25 and the stable code does not seem to compile against it. The image quality is a bit quirky, but this is my first Linux webcam experience, so I cannot compare, really.
There are a few problems to get this thing to run with a tweaked kernel. You need the virtual video driver enabled. Until recently this driver would pull in the VIDEOBUF_DMA_SG stuff too, but the driver got split up recently (I can only testify for 2.6.24.x), and without proper patching you'd get errors like this upon loading the driver:

r5u870: Unknown symbol usbcam_ctrl_add
r5u870: Unknown symbol usbcam_curframe_get
r5u870: Unknown symbol usbcam_claim_interface
r5u870: Unknown symbol usbcam_curframe_testpattern
r5u870: Unknown symbol usbcam_urbstream_stop
r5u870: Unknown symbol usbcam_urbstream_start
r5u870: Unknown symbol usbcam_ctrl_add_tmpl
r5u870: Unknown symbol usbcam_urbstream_cleanup
r5u870: Unknown symbol usbcam_register_mod
r5u870: Unknown symbol usbcam_curframe_abortall
r5u870: Unknown symbol usbcam_curframe_complete_detail
r5u870: Unknown symbol usbcam_unregister
r5u870: Unknown symbol usbcam_urbstream_init
r5u870: Unknown symbol usbcam_choose_altsetting
r5u870: Unknown symbol usbcam_ctrl_alloc
r5u870: Unknown symbol usbcam_urbstream_config_iso

This kernel patch will take care of that. You can find a the needed files to build the subversion driver package here.

lspci output
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)
00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055 PCI-E Gigabit Ethernet Controller (rev 13)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
09:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
09:04.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
09:04.3 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 11)
09:04.4 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 11)

lsusb output
Bus 005 Device 006: ID 044e:300d Alps Electric Co., Ltd Bluetooth Controller (ALPS/UGPZ6)
Bus 005 Device 005: ID 05ca:183a Ricoh Co., Ltd
Bus 005 Device 003: ID 0409:005a NEC Corp. HighSpeed Hub
Bus 005 Device 002: ID 054c:02d5 Sony Corp.
Bus 005 Device 001: ID 0000:0000
Bus 004 Device 002: ID 147e:2016
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

Issues
I have been experiencing seemingly random lockups with this laptop; this does not seem related to overheating (the processor tops out at 73° C when compiling code). I suspect mpd to play a role in the lockups (although that may just be a coincidence since it's often playing and that's how I notice the lockup in the first place). Since nothing works anymore at that point, all I can do is a hard reset... So I'm a bit at loss where to start checking logs (the usual in /var/log isn't really telling anything). I bumped into other people on the Arch forums that experience similar X lockups on their boxes. I have not experienced such lockups since I switched to 2.6.25 RC9, and I also tested my RAM for almost 10 hours - not a single error. So it seems it's the software, and not the hardware, that's the problem :-). Since the 2.6.25 RC's something else popped up - the system hangs (again, at first sight, at random) during boot up. It does react to keyboard input (Enter makes the output jump, Del produces (undesired) output, but Ctrl+Alt+Del does not work, so all I can do is power off the system.
Another problem is the Ricoh cardreader, which does not respond at all when I feed it my Memorystick Pro cards. The model I have (see lspci output above) seems to be on the blacklist for now - haven't found any patches to fix it. Compiling the drivers statically, (un)loading the ricoh_mmc driver, nothing helps... People having a similar card reader say the SD part isn't working either.

Links
Samsung SSD datasheet
ACPI patch
Xmodmap settings
UDMA 33 40-wire cable patch (2.6.24)
UDMA 33 40-wire cable patch (2.6.25)
xf86-video-intel BIOS mode patch
Linux 2.6.24 PKGBUILD
Linux 2.6.24 kconfig
Linux 2.6.25 PKGBUILD
Linux 2.6.25 kconfig
Matching r5u870 driver