I have been in the market for a new laptop for a while, and finally settled on the Compaq R3000Z as my notebook of choice. It has a very nice display, NVidia graphics (albeit an old GPU), an Athlon64 processor for playing with the 64 bit world, and builtin wireless and bluetooth. It's size (8 lbs) is significant, but not a problem for my taste. I've generally been very happy with it. It is, however, not exactly out-of-the-box compatible with Linux. This page is an attempt to share with other users what I've learned.
Hewlett Packard sells this laptop under two model designations: The "Compaq Presario R3000Z" and the "HP Pavillion zv5000z". As far as I have been able to determine the differences are cosmetic only; the electronics are 100% identical. Also note that there are retail versions of both machines available in stores under slightly different model names. See HP's site at http://shopping.hp.com for details.
The notes below were compiled while installing the 32 bit Fedora Core 2 distribution. Most of the information will be applicable to other Linux distributions with only minor changes, and some of it might even be useful for installing a 64 bit distribution (something I am just now starting to work on).
Also note that I am not the first person to tread these waters. I found the following two "installation HOWTO" sites for the R3000Z/zv5000z very helpful when getting started:
There is also a mailing list for relevant discussions:Please send any notes, corrections and questions to me, Andy Ross, at andy (at) plausible (dot) org
This is an older GPU, based on the NV17 core of the original Geforce 256's generation. It has only two pixel pipelines and a fixed-function vertex unit, with no "shader" programmability for either. For single-texturing applications, however, it is really quite acceptable. The fill rate is roughly half of what I see with the Geforce 5700 Ultra in my desktop machine. For my work with FlightGear, it does the job.
By default, Fedora will install the X.org "nv" driver for this card. This is a 2D only driver that unfortunately has a few bugs on this machine. Once X gets a hold of the screen, the text mode console becomes corrupted and the display fails to sync to it. It also had what appears to be a nasty color depth problem; gradient images would display banding, even when the server claimed it was running in 24bpp. NVidia's propietary drivers, however, have always been very fast and stable; I bought this machine with the expectation of installing them.
Note that as of 30 June 2004, NVIDIA has released new drivers that claim to work unmodified with the 4k stacks feature. I haven't had the opportunity to test these yet.
Unfortunately, Fedora Core 2 ships a kernel that simply won't work with the current versions of NVidia drivers. The "4K Stacks" patch has been enabled, which limits kernelspace execution to just one page of stack space. The NVidia kernel module is a port of their windows code, where (I believe) kernel handlers get 12k of stack, and when run it simply overflows the stack and crashes the machine.
Even worse, for inexplicable reasons the Fedora developers have removed the configurability of this feature, so you can't even recompile a compatible kernel from the Fedora kernel-source package. You have to install a stock kernel (both 2.6.6 and 2.6.7 work for me) instead. Be sure to disable the CONFIG_4KSTACKS option when configuring the kernel.
Most models of this laptop have a 16:10 widescreen display, which means that standard video modes will look stretched. The /etc/X11/xorg.conf files generated by Fedora's installer don't include any such non-standard modes. I'm using the following 60 Hz modelines for my 1920x1200 screen, which seem to work pretty well:
Modeline "1920x1200" 197.27 1920 2064 2272 2624 1200 1201 1204 1253
Modeline "1680x1050" 147.14 1680 1784 1968 2256 1050 1051 1054 1087
Modeline "1280x800" 85.7 1280 1360 1496 1712 800 801 804 835
Interestingly, I discovered that running a 1600x1200 mode does
not get stretched, and instead appears centered and
pixel-exact on the screen. I'm not sure if this is a feature of
the graphics card or the display, but I was impressed.
The touchpad on an R3000Z is an ALPS Glidepoint attached to the PS/2 mouse port. Getting it working was a chore, due mostly to the fact that the linux input subsystems are currently a frothing mess. As I understand it, the kernel used to support a simple "/dev/psaux" driver, which just echoed the raw bytes that went over the synchronous serial port. External applications, like gpm and the X server, had various drivers that understood the myriad protocols and did the right thing.
The kernel developers, however, decided that for the 2.6 release it should be the kernel's job to abstract the hardware and present a unified "event" interface to the userspace applications. Which would be all well and good, except for the fact that the kernel currently supports only a minimal subset of known mouse protocols. Specifically, it doesn't recognize the ALPS pad at all.
Even then, the pad requires a moderately complicated software driver to interpret advanced features like the scroll-wheel area on the right side of the pad. This has to be done in the X server. So you need to install a custom driver for Synaptics (and ALPS) touchpads and apply an included kernel patch to get the kernel to recognize the ALPS pad and the X server to talk to it correctly.
And here you hit what appears to be a hardware bug in the NForce3 chipset. At boot, the kernel's PS/2 mouse driver doesn't detect the port. You need to unload the psmouse module and reload it to get the hardware to appear. Unfortunately, you cannot do this too early in the boot or else it doesn't work. Maybe something in the NForce3 chipset needs to be kicked by another initialization step before it enables the mouse port? Note that the Fedora kernel wants to compile the psmouse driver into the core kernel, so it's not a module and cannot be unloaded. Be sure to make this a module when you configure your kernel.
And even then, configuration is a hassle. The synaptics driver requires that you specify a specific /dev/input/eventN device to the X server; it doesn't understand the /dev/psaux compatibility device, nor the /dev/input/mice "combined" device. But because of the "late reloading" required to get the hardware to enable the mouse port (which happens after the USB initialization) the correct device for the touchpad will be a different device file depending on whether a USB mouse happens to be plugged in at boot. What a mess. To fix this, I wrote a findmouse perl script which gets run from /etc/rc.local, reloads the psmouse module, and makes a /dev/input/TouchPad link to the correct device just before the X server is run.
And that's all. One kernel patch, a third party driver for the X server and one perl hack later, my touchpad works reliably from boot. It works great, by the way. I especially like the button above it that allows me to turn it off while typing.
Sometimes, perhaps one boot in ten, the machine comes up in a state where the keyboard simply doesn't work. This may be related to the problems with the PS/2 mouse detailed above, I'm not sure. I can always use the keyboard successfully in the grub boot loader, so the issue somehow manifests itself later on in the boot process. I have never seen the problem under windows, although I haven't booted windows very often on this machine.
If anyone else has seen this behavior and/or is aware of a fix, please let me know. One thing I should try is plugging in a USB keyboard while the machine is in such a state, but I haven't gotten around to that yet.
Other people have discovered that, as with the touchpad, unloading and reloading the atkbd module late in the boot process forces the kernel to re-detect the keyboard and prevents the problem. This again requires a kernel rebuild for fedora users, as FC2 does not build this as a loadable module.
Even weirder, Jeff Connelly discovered that simply pressing "~" ("shift-backquote" is probably a better description) is sufficent to kick the keyboard into a working state. I've had only one opportunity to test this, but I can confirm that it works. There is some speculation that the problem is related to the shift key state management, but I don't have enough evidence to say for sure.
The Athlon64 CPU has a different interface for its frequency scaling than its predecessors did. Accordingly, you need to use the powernow_k8 kernel module to control it. This is an "experimental" module that isn't built by default in the Fedora kernel, so you will need to enable and build it yourself.
Once loaded, you can query the list of available frequencies via sysfs, in /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies. You can read and set the current CPU speed using the scaling_setspeed file in the same directory.
In principle, you should be able to use the cpuspeed program included with the distribution to manage the speed for you automatically, but I couldn't get it to work; my guess is that it fails on machines with no APM interface at all. Instead, since this is a really easy problem, I wrote my own "userfreqd" daemon in perl to do the job. It isn't nearly as robust as it could be, but seems to work well for this machine. For a Fedora machine, simply dropping it in /etc/init.d and running:
chkconfig --level 2345 userfreqd on
should be sufficient to get it installed. You can start it up and
shut it down just like any other subsystem, e.g. with the "System
Settings / Server Settings / Services" GUI tool.
I made a bet and lost with this part. HP offered two wireless configurations for this machine: a "Broadcom 802.11g" adaptor, and a "802.11b" one. We all know Broadcom isn't supported, but I figured if the high-speed device listed the manufactuerer explicitly, and the low-speed option didn't, they must be different. The 802.11b card would therefore probably be a Prism card, with linux drivers. Since I wanted the integrated Bluetooth adaptor (which is available only in a combo with a wireless card), I had to pick one of these anyway.
Nope. I lost the bet, it's a Broadcom too. No drivers.
The good news is that the ndiswrapper project's driver wrapper works amazingly well. Basically, you just build the ndiswrapper source code to compile the kernel driver, point their installer utility at a windows driver .inf file (I used the one that came on the driver CD with my computer) and it Just Works. Not free software, but not a configuration hassle either. Very impressive.
It obviously won't work in 64 bit mode without a lot of hackery, however, so I'm still in the market for a wireless adaptor...
ACPI suspend: Doesn't work. If you try to enter the S3 sleep state from a normal system environment, the machine immediately oopses inside a sound card interrupt handler. If I carefully exit X and unload the sound modules (or boot to single user mode), I can get it to "successfully" enter a sleep where the power button is blinking just like it does in windows. But it doesn't wake up. Since this laptop has no APM support, this means that suspend is unavailable in linux. I might try the swsusp project's patches for suspend to disk at some point, but for now I'm happy enough with booting and shutting down the machine manually.
Sound Card: It's an i810 compatible audio controller embedded in the NForce3 chipset. Works great with the ALSA drivers out of the box. No configuration needed.
10/100 Ethernet: The integrated Realtek 8139 controller works perfectly with the 8139too driver.
USB: The NForce3 chipset has three USB busses. Bus 001 is a USB 2.0 EHCI controller, and owns the two ports on the left side of the laptop. Bus 003 is a USB 1.0 OHCI controller and owns the single port on the right side, as well as the internal Bluetooth adaptor. Bus 002 is a zombie, it has no external ports, nor internal devices attached.
Volume/Mute buttons: These are just softkeys, and are reported to the X server as normal key events with keysyms like XF86AudioMute, etc... Oddly, the Gnome 2.6 environment doesn't have these mapped by default. You can use the Keyboard Shortcuts control panel to map them appropriately.
Wireless On/Off Button: This is a hardware switch (i.e., the CPU doesn't know it exists) that disconnects the power to the 802.11 and Bluetooth antennas. After I got the machine out of the box, I spent almost an hour trying to figure out why the wireless wasn't working until I discovered this thing. It also "unplugs" the internal USB Bluetooth adapter; the usb_hci driver in the 2.6.6 kernel has a bug that causes a kernel oops when this happens, locking up the bluetooth subsystem until the next reboot. It's fixed in 2.6.7.
Firewire/IEEE1394 Controller: Gets detected correctly, but I have no Firewire device to test it against.
PCMCIA/CardBus slot: Haven't tried it.
Modem: Haven't tried it. It's an AC97 winmodem, so I'm not hopeful.
Integrated Card Reader: This is a Texas Instruments PCI-1620 CardBus controller with integrated "UltraMedia" flash card interface. So far as I can tell, no drivers exist for Linux. The datasheet for the part is downloadable from TI, but all they document is the firmware loading interface; apparently all the interesting features are handled by firmware, with a proprietary interface. Sigh. This would otherwise be a useful gadget.