Sony Vaio TZ190N
An ultrabook avant la lettre (except for the price tag). Carbon chassis, LED backlit LCD, Core 2 Duo ULV, an abundant 2 GB of RAM, draft N wireless, and - the icing on the cake - an SSD.
- Intel Core 2 Duo U7600
- 2 GB of DDR2 533 RAM
- 11,1" 1366x768 LED backlit LCD
- Intel GM 945 chipset with onboard GPU
- IPW4965 AGN miniPCI wireless LAN with hardware switch
- Marvell Yukon Gigabit Ethernet
- Samsung MCBOE32GQAPQ ZIF 32 GB 1.8" SSD
- Integrated fingerprint reader (haven't checked the details yet)
- SD/Memorystick card reader
- FireWire 400 4-pin connector
- 2x USB 2.0
Sony has no reputation as being Linux-friendly and with this laptop it really shows. I've spent a lot of my time on getting it to work - but 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.
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.
Sony sells this laptop with shiny, tiny metallic multimedia keys. Most of them generate xev events so you can configure them through Xmodmap. Openbox then manages the keybindings for you. The Audio/video and eject buttons generate ACPI codes (and no X events), just like the Fn keys. I bound the multimedia keys to mpc, mpd is always running in the background 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. 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.
The SSD, a PATA 32 GB Samsung 1.8" 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.
This proved to be quite the b*tch. 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 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.
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:
1 2 3 4 5 6 7 8 9
#!/bin/bash case $1 in suspend) chvt 1 ;; resume) chvt 7 ;; esac
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 tarball (Mediati link is dead, sorry) 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.
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.Updated: 2014-01-21