Ode to the Compaq 8510w

I got a sweet new laptop at work. It's a Compaq 8510w. The Core 2 Duo T7500 is fast, 3 GB of RAM is luxurious, and the 1900x1200, 15.4 inch widescreen LCD is pretty. I installed Ubuntu 8.10 and it sleeps (suspends to RAM) and wakes up like no other Linux box I've ever had, which is very, very nice (though the XO has started doing that with the latest update extremely well too). I installed the corporate image of windoze XP under VirtualBox. With the processor's virtualization extensions it runs pretty snappily. I can watch the corporate propaganda WMV movies, use Lookout for calendaring, and access the internal IE-only "web" apps just fine.

I went with VirtualBox instead of kvm this time, kind of just to see what the differences where. I had to set up bridge networking because the corporate image didn't like not having a corporate IP address. I hear the newest version of VirtualBox doesn't need this, but here is the script I run to set up bridged networking with the "old" version:

brctl addbr br0
ifconfig eth0 0.0.0.0
brctl addif br0 eth0
dhclient br0
VBoxTunctl -b -u bryan
ifconfig tap0 up
brctl addif br0 tap0

To remove the bridge and set it back to normal I do this:

ifconfig tap0 down
VBoxTunctl -d tap0
ifconfig br0 down
brctl delbr br0
dhclient eth0

I got help from here and here on this. The scripts work well, except that Firefox gets confused when I switch back and forth. That happens to Firefox when I VPN into work and then disconnect the VPN. I'm sure there's a good explanation.

The other really cool thing about this laptop is that with the docking station, it can drive two external monitors. It's easy to do with the windoze nvidia driver, but with the Linux driver it wasn't as straightforward. Mainly because the version of the nvidia driver that came with Intrepid (version 177) simply didn't support this option. After getting some help from the other Linux lovers at work I realized that this was my problem. Doing an aptitude search nvidia showed that there was a more recent version available and a few older versions. Thankfully it's a simple aptitude install nvidia-glx-<version> to try a different version. I tried version 180 to no avail, and then found that version 173 worked.

The way I could tell it was working was by running nvidia-settings while docked and connected to the two external monitors and finally being able to see them under X Server Display Configuration. You have to disable the Seiko LCD screen (DFP-0) to get the other two (DFP-1 and CRT-0, since there's one DVI and one VGA connector on the dock) configured and working with twinview.

When I undock, the LCD screen stays blank. If I manage to restart X then the display comes up on the laptop LCD, but it's still at the dual-display resolution that doesn't fit on the built-in LCD very well. My solution was to git tag (since I still keep /etc under git) the dual display xorg.conf and then recreate the single built-in LCD xorg.conf and tag it too. To switch between them when docking and undocking I created two scripts, one is called 'laptop' and looks like this:

#!/bin/sh
cd /etc/ && sudo git checkout xorg-laptop-display X11/xorg.conf

The other is called 'external' and looks like this:

#!/bin/sh
cd /etc && sudo git checkout xorg-external-dual-display X11/xorg.conf

It works pretty well, but I still have to restart X after running the scripts. I've heard of this cool thing called XRandR, but it seems like I read that the nvidia driver doesn't Just Work with xrandr. I need to look into that some more.

So, my work satisfaction went up when I got this machine. I never thought I'd want a large "mobile workstation" laptop like this, but when I think about how fast and nice it is, it doesn't feel nearly so heavy to carry. I should probably disclose that I may happen to work for the same galactic corporation that makes this laptop, but I'm in a totally different part of the galaxy, far from where laptops are made. There is absolutely no bias in this endorsement at all. And nevermind that I would not have considered shelling out for such a nice machine myself :-)

Comments

Anonymous said…
I'm also enjoying the same laptop model. For the first time I’m using the x86_64 arch and moving my gentoo to it has been a nice exercise.

The nvidia-drivers with version > 173 are not detecting the display connected to the docking’s DVI port. I have no clue which is the problem so I’ sticking with 173.14.15

A fun thing is that windows based laptops (the standard here at work) are not able to see the whole 4G of ram that linux is happily using, but only 2G.
January 29, 2009 at 10:46 AM
Unknown said…
Do your brightness keys work?
I have 8530w and they do not (ambient sensor works good though). Also, after resume, brightness is fixed to lowest setting, making it unusable.

For DVI port problem, you can hard-code edid from monitor using:

Option "ConnectedMonitor" "DFP-0, DFP-1"
Option "CustomEDID" "DFP-1:/etc/X11/edid-dvi.bin"

in screen section. edid-dvi.bin is edid you get from nvidia-settings when monitor is connected directly to notebook.
January 29, 2009 at 12:27 PM
Anonymous said…
Thanks for the great review. I'm not usually one to drool over hardware, but you managed to make me jealous -- and over a laptop too!

I've been on debian for a few years after being long time redhat then fedora. Is it worth making the switch to ubuntu? (At least most of what I know about debian will be portable?)
January 29, 2009 at 2:44 PM
Bryan said…
@Igor: I just tried the brightness keys, and even though a nifty graphic appeared and seemed to indicate that it knew I was pressing the brightness keys, it didn't look like brightness was actually changing. It seems to be at a comfortable level for me, though, even after resume.

@Brian: I've hardly used Debian, so I'm not sure what you gain by switching from Debian to Ubuntu. Going to apt-get from rpm/yum was a huge step up for me. The other thing I love about Ubuntu is that every seemingly obscure problem I've run into, Google can find me someone else who has also had it and found a workaround or fix of some sort.
January 29, 2009 at 9:46 PM
Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa...
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use...
Read more

SystemVerilog Streaming Operator: Knowing Right from Left

SystemVerilog has this cool feature that is very handy for converting one type of collection of bits into another type of collection of bits.  It's the streaming operator.  Or the streaming concatenation operator.  Or maybe it's the concatenation of streaming expressions (it's also called pack/unpack parenthetically).  Whatever you want to call it, it's nice.  If you have an array of bytes and you want to turn it into an int, or an array of ints that you want to turn into an array of bytes, or if you have a class instance that you want to turn into a stream of bits, then streaming is amazing.  What used to require a mess of nested for-loops can now be done with a concise single line of code. As nice as it is, getting the hang of the streaming operator is tough.  The SystemVerilog 1800-2012 LRM isn't totally clear (at least to me) on the details of how they work.  The statement from the LRM that really got me was this, "The stream_operator <...
Read more