Linux on the HP Pavilion ze4300 Notebook

Table of contents

1. Before purchasing
2. Base installation  
3. Graphics 
4. Onboard modem 
5. CD-RW/DVD-R 
6. One-Touch Buttons 
7. ACPI 
8. ... and the rest
9. How to connect a cell phone via USB to a Linux laptop and dial-up an internet connection

(Please excuse the poor formatting of this page, I'm no expert in HTML ;-)

The HP Pavilion ze4300 is a rather inexpensive typical desktop notebook. It has some nice features, among which the one-touch buttons and builtin CD-RW/DVD-R and floppy drives. Another nice thing is the screen, which supports a resolution of 1400x1050, and the touchpad with integrated "scroll-mousewheel" (Synaptics touchpad). As one of increasingly few notebooks it still has a RS232 serial adapter (which for me was one of the main arguments, often having to deal with "headless" devices). It is (apart from the ACPI stuff, which works only partially) fully supported by Linux and very handy and comfortable to work with. I just love the blue LEDs :-))

There are some drawbacks, too, among which most prominently:
- Rather poor manufacturing
- "Designed for Microsoft Windows" label
- No onboard WLAN (though adapter socket is onboard)
- ACPI only power management

The Pavilion is derived from the Omnibook series, and thus the tools and modules from the Omnibook project at Sourceforge work perfectly. I have tried them with various kernel versions, and they worked every time.
   In the meantime, they also work with kernel 2.6.11.2, and omnibook-2005-02-17!

1. Before purchasing

HP has a politics of using different components for each and every country that they sell hardware to. So the configuration of my machine is likely to widely differ from that of a model purchased in another region. I bought mine in Switzerland in July 2003. Having made some rather tiresome experiences, I took a swiss-germanized version of Knoppix 3.2 with me, booted it and controlled if everything worked. It did.

2. Base installation

I used a stock SuSE 8.2 installation CD. (   In the meantime, I'm running Gentoo with a quite different software set. I've tried to insert Gentoo specific stuff into this document as necessary.) The installer detected almost all hardware components and initialized the necessary modules (see original modules.conf for SuSE and    for Gentoo). The only thing that was missing, was the onboard modem chip, and the CD-writer wouldn't work. Sound was OK, network OK, graphics flaky (X came up with errors, and the maximum resolution wasn't reached). Obviously, none of the one-touch buttons would work. Now, having relaxed while watching the YaST installer (which I usually don't use), it was time to go to work.
(   The above goes for SuSE only. Gentoo, too, didn't see the modem chip, but the CD writer worked with the same options. X is quite different, because Gentoo doesn't install X per default, and when I decided it's time for some eye candy, I went for X.org's X Window system. In the meantime, Xfree86 is fading into history.) The onetouch Buttons ("Mail" and "WWW", as well as the volume control keys) strangely worked, though. This was probably due to the acme package in Gnome, after deinstalling it, the volume control stopped working, but not the "Mail" and "WWW" buttons.)

3. Graphics

After playing awhile with SuSE's X-configuration tool SaX2, I decided for the easy way. Remembering that Knoppix had used the whole resolution range, I again booted into Knoppix and just copied over the interesting parts of the /etc/X11/XF86Config-4 file. While SuSE's SaX2 insisted that I use the framebuffer device driver fbdev (probably because of the AGP host bridge, which seems not to be recognised), Knoppix suggested the VESA driver, which brought up X in high resolution (1400x1050) without errors (see XF86Config-4) and a working scrollmouse. Well, that was the easy way, wasn't it?

There is some more potential in the graphic chip (ATI Technologies Inc Radeon IGP 340M) though, especially hardware 3D acceleration. Not being much of a gamer, though, I postponed this until need arises. I have read in a page about another Pavilion model that it is said to be possible to get better graphics - your mileage may vary.

(   I use the server from X.org on Gentoo. Configuration was quite straighforward (i.e. reading the comments in the example config file, then editing and starting the server - took some trial and error, though ...), and the resulting /etc/X11/xorg.conf file appears more tuned for the hardware than the one for XFree86. And: After installing (emerging) just about everything with a "glx" or "opengl" in its name, and enabling the DRI manager in the kernel config, hardware 3D acceleration is working! It uses the free implementation of the ATI readeon driver that comes with the vanilla kernel sources.)
You need to install the "synaptics" package (emerge synaptics) for the Synaptics touchpad. This gives you the synaptics driver loaded by the server.

4. Onboard modem

Traditionally, this scares you away, since onboard modems usually are socalled "Winmodems", i.e. modems that are too stupid to do anything and rely on the operating system do deal with the gory details of handshaking, handling protocol stacks, communication etc. Times have changed, though. lspci revealed an "ALi Corporation Intel 537 [M5457 AC-Link Modem]" chip, and after Google and http://linmodems.org brought me to the (although ethically questionable) resolution of using a non-free driver from http://www.linuxant.com/. I used version 5.03beta, which works well and doesn't have a speed limitation. Unfortunately, linuxant has since changed their policy, so that the "free" (as in free beer ¦-[ ) driver is limited to 14.4Kbps data, while you have to pay for the 56K and fax driver. And, unfortunately again, they have put a paragraph in their license that prevents me from making the package available to you here. But then, who still needs modems, right?

The installer installed the modules and tools without much ado and added the following lines to /etc/modules.conf:

	alias /dev/ttySHSF* hsfserial
	alias char-major-240 hsfserial
	alias /dev/ttyCUA* hsfserial
	alias char-major-241 hsfserial
	alias /dev/modem hsfserial
	options hsfserial serialmajor=240 calloutmajor=241
	

The following device was created in /dev:

	crw-rw-rw-    1 root     root     240,  64 2003-08-08 17:54 /dev/ttySHSF0
	lrwxrwxrwx    1 root     root           13 2003-08-08 17:54 /dev/modem -> /dev/ttySHSF0
	

With that, the modem worked, but I haven't used it since.

5. The CD-RW/DVD-R

I had done the installation with the SuSE-DVD, so this was rather obviously supported without any issues. The problem was the CD-RW, which would read CDs, but not burn them. From another workstation installation that I had done some days before I copied over the following lines to /etc/modules.conf

	# Options for scsi-emulated atapi cd writer
                                                                                
	options ide-cd ignore=hdc ignore=sr0            # tell the ide-cd module to ignore hdc
	alias scd0 sr_mod                    # load sr_mod upon access of scd0
	#pre-install ide-scsi modprobe imm    # uncomment for some ZIP drives only
	pre-install sg     modprobe ide-scsi # load ide-scsi before sg
	pre-install sr_mod modprobe ide-scsi # load ide-scsi before sr_mod
	pre-install ide-scsi modprobe ide-cd # load ide-cd   before ide-scsi
	

This basically tells the IDE driver to ignore the drive and gives control to the scsi-ide emulation driver. It then force-loads some modules prior to using the drive.

Additionally, we need an entry in the bootloader configuration to set these parameter at boot time. I'm using GRUB, so the according entry goes to /boot/grub/menu.1st

	title linux
    	    kernel (hd0,5)/vmlinuz root=/dev/hda5 vga=0x31a  hdc=ide-scsi hdclun=0 splash=silent showopts
    	    initrd (hd0,5)/initrd
	

Of course, you need to adapt these settings to your setup (especially the (hd0,5) and root=/dev/hda5 apply to my machine specifically; they mean that my root partition is /dev/hda5, while the /boot direcory resides on a separate partition /dev/hda6. I know, it's not obvious, but "hd0,5" means disk 0, partition 5 (count starts at 0), which results in /dev/hda6 (here, count starts at 1).)

With this (and after rebooting and depmod -a, the drive burns at 8x speed and is nicely configurable in e.g. XCDroast.

	title gentoo-mwe
    	    root (hd0,0)
    	    kernel (hd0,5)/boot/kernel-2.6.11-rc4 root=/dev/hda3 resume=/dev/hda2 resume2=/dev/hda2 pmdisk=/dev/hda2 vga=0x31a showopts
	

6. The One-Touch Buttons

This was probably ( definitely!) the nicest hack of them all.

Some years ago, keyboards and laptops appeared that have (generally five) extra shortcut buttons to access some frequently used programs or functions. Since they directly call system-specific software, they need to be controlled by the operating system. All manufacturers provide Windows drivers, of course, but most ignore Linux users. HP took the concept a little step further by assigning even the volume control to the operating system's custody, i.e. all "extra" buttons don't do a thing by themselves but generate keyboard interrupts (non-standard, of course) instead, relying on the OS to make something useful out of them.

Thanks to the Omnibook project at Sourceforge there is a kernel module that is capable of handling those interrupts and passing them on to userspace. SuSE has already incorporated the module in their stock kernel, so I didn't have to do much. But, as said above, the module worked as well when compiled against vanilla sources.

1. Load the module.
   insmod omnibook should do the trick. To have it loaded at boot time, I created /etc/rc.d/omnibook:

   	case $1 in
   	        start)
           	/sbin/insmod omnibook
           	;;
           	stop)
           	/sbin/rmmod omnibook
           	;;
   	esac
   	

   By making it executable with chmod 755 /etc/rc.d/omnibook and setting links from the runlevel directories I entered it into the normal boot procedure:
   

   	ln -s /etc/rc.d/omnibook /etc/rc.d/rc5.d/S20omnibook
   	ln -s /etc/rc.d/omnibook /etc/rc.d/rc5.d/K20omnibook
   	

   Now the module gets loaded/unloaded when entering/leaving runlevel 5, which is the default graphical multi user runlevel of SuSE. Adapt for other distributions (The command runlevel should give you your current runlevel.) The module enables the kernel to receive the interrupt and pass it on as keycodes to the console driver (which is X when running in graphic mode).
   (   Under Gentoo, all that is needed is to add a single line that says "omnibook" to /etc/modules.autoload.d/kernel-2.6.)
   

2. Tell the X-Server what symbol to assign to the keycodes.
   There is a tool called xmodmap that allows any user in X to dynamically assign values to any keycode pressed. It needs a keycode and a key value (symbol) as parameters. So, we have to find out what keycodes are sent by the one-touch buttons and volume control buttons. The tool to accomplish this is xev. Once started from an X terminal, it prints out lots of information for every key pressed and released. What we need from that wealth of data is the parameter "keycode":
   

   	KeyRelease event, serial 25, synthetic NO, window 0x3400001,
       	    root 0x3a, subw 0x0, time 11595553, (662,386), root:(665,429),
   	    state 0x0, keycode 236 (keysym 0xffd2, NoSymbol), same_screen YES,
   	    XLookupString gives 0 bytes:  ""
   	

   The above is some of the output from xev when pressing the (top left) one-touch button with the envelope symbol. It tells us that X has received keycode 236, but has no symbol associated with it. Repeat the above step and write down the keycodes for all buttons you want to use.

   Next, we decide which symbol to assign to the keycodes. Since we don't want to simply print out a character, but call a function, it makes sense to assign function keys to the keycodes. Standard keyboards provide function keys F1 through F12, so better not use those. I decided to start at F21.

   The command to assign keycode "236" with funktion key "F21" is

   	xmodmap -e 'keycode 236=F21'
   	

   which I repeated for every key I wanted to use:
   

   	xmodmap -e 'keycode 236=F21' # EMail OneTouch Button
   	xmodmap -e 'keycode 243=F22' # TV OneTouch Button
   	xmodmap -e 'keycode 178=F23' # WWW OneTouch Button
   	xmodmap -e 'keycode 241=F24' # Lock OneTouch Button
   	xmodmap -e 'keycode 240=F25' # Help OneTouch Button
   	xmodmap -e 'keycode 176=F26' # VolumeUp OneTouch Button
   	xmodmap -e 'keycode 174=F27' # VolumeDown OneTouch Button
   	xmodmap -e 'keycode 160=F28' # VolumeMute OneTouch Button
   
   	xmodmap -e 'keycode 115=F29' # "Windows" Button
   	

   The values above are taken from my laptop and may be different on yours.
    The above works for kernel 2.4 only. See below for updates on kernel 2.6.

   Those commands need to be run every time a user logs into X, since they are specific to the keymap loaded on X startup (usually with every graphic login). Since I wanted to make the keys available to all users on my laptop (wife, kids ...), I put them into a world-executable script /etc/keycodes, which every user would run on login. To make sure they really do, I entered the following into /etc/profile.local (which gets automatically executed after /etc/profile on SuSE. Your distribution may provide a different mechanism.):
   

   	# Set OneTouch keycodes in X
           # Don't do it if not an X session or simply "su"-ing.                                                                        
   	if [ -x /etc/keycodes -a -n "$DISPLAY" ]; then
           	. /etc/keycodes
   	fi
    	

   Once those commands get executed, our X-Server generates the appropriate symbols and passes them on to the running windowmanager. So now we must konfigure the windowmanager to react to the function keys. How to do this obviously depends on the windowmanager you're using. I use Gnome2, and I haven't found out how to tell it to launch a custom application on a special keystroke. All I found was pre-defined system actions to take (like switch desktops, cascade through open windows ...). KDE on the other hand lets you configure this very comfortably via kmenuedit.
   

   

   Just create a new item, assign a name, command, the shortcut key (optionally also an icon) to it, apply, and the key is active ... as long as the KDE subsystem is running! The problem is that all KDE applications need their DCOP component running in the background.

   Now, I didn't want to use KDE just because of the one-touch keys! As it turned out, I didn't need to run KDE in the foreground for this, it was enough to have just the basic components running in the background while continuing to use Gnome. As all KDE programs start the DCOP server (among others) when invoked, I just had to make sure that such a program was started by every user logging into X. And what program would do better than khotkeys? So the following lines also went into /etc/profile.local:
   

   	# Shocking: Start KDE in background to enable OneTouch Function keys
   	# (because afaik only kmenuedit can assign a Shortcut key to an application)
                                                                                   
   	KDE_RUNNING=`ps xa | grep -v grep | grep "kdeinit:"`
                                                                                   
   	if [ -z "$KDE_RUNNING" ]; then
           	/opt/kde3/bin/khotkeys>/dev/null 2>&1
   	fi
   	

   This way, khotkeys launches the basic KDE services in the background before starting, and since the script is run at login time, it is available to all users.

     With KDE 3.3 being much faster than its predecessors, I switched back to KDE. So no more need to start any KDE stuff in the background.
   

     Things work slightly different under kernel 2.6.
   As stated above, with kernel 2.6, the onetouch buttons didn't work anymore. Just the "Mail" and "Internet" buttons, plus the volume control keys.

   After installing the omnibook-2005-02-17 module, I finally got some reaction from my kernel when pressing one of the three buttons that were not working:
   

   	Mar 13 12:31:37 blue kernel: atkbd.c: Unknown key pressed (translated set 2, code 0xf0 on isa0060/serio0).
   	Mar 13 12:31:37 blue kernel: atkbd.c: Use 'setkeycodes e070 ' to make it known.
   	Mar 13 12:31:37 blue kernel: atkbd.c: Unknown key pressed (translated set 2, code 0xf1 on isa0060/serio0).
   	Mar 13 12:31:37 blue kernel: atkbd.c: Use 'setkeycodes e071 ' to make it known.
   	Mar 13 12:32:02 blue kernel: atkbd.c: Unknown key pressed (translated set 2, code 0xf3 on isa0060/serio0).
   	Mar 13 12:32:02 blue kernel: atkbd.c: Use 'setkeycodes e073 ' to make it known.
   	

   So I did. I again prepared a small scriptlet to set those bindings at boot time: /etc/scancodes:
   

   	#!/bin/bash
   
   	setkeycodes e073 175
   	setkeycodes e071 177
   	setkeycodes e070 179
   	

   You may notice that the keycodes that are bound to the scancode are different from those used in the first example under kernel 2.4. Read below for an explanation. This was probably the reason things didn't work anymore under kernel 2.6!

   As suggested on the Kernel Mailing list, the kernel will only pass keycodes in the range 0-239 to the keyboard driver. So any keycode value that is over 239 won't work. This was true for exactly those three buttons that refused to work under kernel 2.6.x for months!
   So the idea was to try and assign keycodes < 240 to the scancodes in question, and I randomly used three values that xmodmap -pm reported unused (175, 177, and 179 in the above example).

   xev now finally reported a key event when I pressed one of the three buttons, but strangely, the keycodes didn't match those that I had configured:
   

   	KeyRelease event, serial 30, synthetic NO, window 0x1000001,
   	    root 0x48, subw 0x0, time 5918130, (-643,3), root:(578,874),
   	    state 0x0, keycode 210 (keysym 0xffd3, NoSymbol), same_screen YES,
   	    XLookupString gives 0 bytes:
   	

   That's the "TV" button ok, but instead of keycode 175, as set with /etc/scancodes, X got keycode 210. Somehow the keyboard driver seems to do its own magic mapping ... I haven't yet found out the magic behind it though. 175 becomes 210, 177 becomes 220, and 179 becomes 246. Higher maths, I suppose;-)
   Well, the "workaround" is trivial, just repeat the above steps for the remaining buttons and adjust /etc/keycodes accordingly:
   

   	#!/bin/bash
   
   	xmodmap -e 'keycode 236=F21' # EMail OneTouch Button
   	xmodmap -e 'keycode 210=F22' # TV OneTouch Button
   	xmodmap -e 'keycode 178=F23' # WWW OneTouch Button
   	xmodmap -e 'keycode 220=F24' # Lock OneTouch Button
   	xmodmap -e 'keycode 246=F25' # Help OneTouch Button
   	xmodmap -e 'keycode 176=F26' # VolumeUp OneTouch Button
   	xmodmap -e 'keycode 174=F27' # VolumeDown OneTouch Button
   	xmodmap -e 'keycode 160=F28' # VolumeMute OneTouch Button
   	
   	xmodmap -e 'keycode 115=F29' # "Windows" Button
   	

   This did the trick! I could now assign actions to buttons F22, F24 and F25! (I chose konsole for F22, and kdesktop_lock --forcelock [Lock screen] for F24. Still don't know what to do with F25. But I guess, that's what the question mark stands for;-)

   The method for loading the keycodes remains the same, and I've written a small script for setting the volume. It's called with alsavolume [up|down|mute|unmute]. I've setup the keys kmenuedit:

   

7. ACPI

This is a rather sad chapter and thus very short. It appears to me that the ACPI implementation of current Linux kernels cannot yet handle all tweaks and oddities of all hardware. SuSE have managed to integrate the patches in question in a reasonable manner, so that at least some of the functions work: Battery status works well, so does processor throttling (aka SpeedStep). The rest doesnt. Well, the system does receive the ACPI events OK, but any action that could be taken via the /proc/acpi interface - save throttling - simply fails. I have tried various kernels, and 2.6.x looks very promising. I managed to do a software suspend with 2.6.0-test3 afair, but then the box wouldn't wake up again.

(  Suspend to disk works in most cases (i.e. for most kernels), but I've in the meantime got accustomed to powering down. Time will bring a solution :-) I strongly recommend using swsusp2 (http://www.suspend2.net/). It is very nicely configurable and definitely more stable than the legacy version!

You can work around that a little bit by writing your own scripts that should be executed on specific events and entering them into the acpid configuration files in /etc/acpi/events/ (see acpid(8)). Power-off or throttling the processor to minimum when the lid closes might be an option.

8. What about all the rest?

There's more to the Pavilion ze4300, e.g. FireWire (IEEE 1394), IrDA, microphone, parallel and serial ports etc.

Parallel and serial work without any issues.

I have not had the opportunity to test all the rest. I am confident though for FireWire at least, because lspci identifies the adapter correctly:

	00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link)
	

That's all. Comments, feedback (and help) are welcome at public at wernig dot net.