Hardware Design and the User

A good piece of (computer) hardware shows attention to the user and to user interface design (although not in the software sense). I have had an experience in contrasts of late that show what a difference good hardware engineering can make.

I have been working with the Toshiba Portege M100 laptop, and have found its design to be “interesting” to say the least. The LED lights that describe all of the various details commonly found on the outside cannot easily be seen when the system is in operation: they are pointing towards the ceiling on the top of the open display lid. The mouse buttons are confusing: there is no left/right button – rather, the “right” button is on the bottom and the “left” button is on the top of the two larger buttons. The purpose of the two tiny buttons are unclear.

The batteries and their installation is also an interesting study. The latch to “unlock” the battery is a slider with a locking mechanism in the middle: it is hard to describe. You’ve never seen anything like it, and operating it can be, at least initially, mystifying. There is also no way to determine whether a battery is charged or dead by looking at it.

This machine, the Toshiba Portege M100, can be contrasted with the HP nc4010. Batteries on the nc4010 have a four-LED light display which not only shows the state of the battery, but also provides (for the battery wizards!) an error display (but good luck determining what the error displays are…). The batteries snap into place and are set to go; removing a battery is a matter of moving a spring-loaded latch right next to the battery that shows a battery symbol. The battery symbol is built into the case itself in relief: this prevents the logo from “rubbing off”. Similar symbols can be found for RAM, hard disk, battery #2 (travel battery), and keyboard.

The capability of using a second battery shows foresight on the part of the designers as well: there is no obvious way that the M100 could take a second battery.

Instead of a sliding catch to unlock the top lid like the M100, there is the more commonly seen pushbutton latch. Several LEDs are built into the front edge of the machine – on the corner, so that the displays can be seen both from the top and from the front – that is, these LEDs can be seen easily by the user whether the machine is in operation or not.

Even the logo on the top of the computer itself shows attention (or lack thereof) to detail. The logo on the Portege M100 is only readable to the user (who presumably owns the machine); the HP, like Apple, has their logo large and in the middle and readable to passersby when the machine is open. Apple took this one step further and lit up the logo!

Another common mistake is the port cover on the back of the machine. The Compaq Armada E500, for instance, like so many of its kind, has a large one that goes nearly the entire length of the back of the laptop. Toshiba uses a small one with no obvious way to open it: instead of pulling it down from the top, it is opened by pressing down near the hinge, though there is no description of how to do this on the machine itself.

In all cases, these “latches” or covers will often get broken off and disappear. The HP nc4010 has no cover/latch in the back – thus nothing to break off.

Once again, all ports on the back of HP nc4010 are labeled by labels in relief built directly into the plastic; the Toshiba M100 labels nearly all of them with painted on labeling.

Even the plastic itself shows an attention to detail: the M100 uses a silver-painted white plastic; the nc4010 uses black plastic with no paint. This means that as the machine gets older, the Toshiba M100 will show evidence of the white plastic underneath as the paint is worn away – and the HP shows none of this.

The HP nc4010 is not without its mistakes: there are several painted labels, and there is a PCMCIA insert that can be lost. On the nc4010 the speakers point to away from the listener to the left and to the right – the Compaq Armada E500, though bigger, put them in the front pointing directly up at the listener on the left and right sides.

This sort of engineering can be seen in other areas as well: how hard is it to repair the product, for instance? Many servers – Sun and HP servers in particular – can be easy to maintain. However, consider the Apple laptop: pulling one apart (to replace a hard drive for instance) can require removing 30 or more screws – a definite mistake. Does pulling the system apart require special tools – or any tools at all? Some servers can be maintained, at least in part, without any tools at all – replace PCI cards, install memory, install or replace hard drives – all without tools.

All of this design is not specifically user interface design, but the fundamentals are the same: consider the user, consider what will happen in the future, and consider how the system will be used. In my experience, HP and Compaq have both been excellent in their design engineering.

What are your thoughts and experiences?

FreeBSD 6.3 is OUT! (Armada E500 installation)

Just after installing 6.3-RC2, I discovered that 6.3 was officially released!

This didn’t take much work to update to. The basic steps were:

freebsd-update upgrade
freebsd-update install

Then – after a reboot (for kernel updates, I presume) another:

freebsd-update install

Relatively painless, throughout.

Then, continuing my install over the weekend, there were a few niggling things to fix. First off, the buttons up on the top of the keyboard didn’t work (no surprise there). Using the xev utility helps to pin down the actual keycodes for these keys, then use the xmodmap tool to add the appropriate actions to the keys. In my case, xev reported that the keys left to right were:

  • 163 (info key)
  • 142 (home key)
  • 154 (search key)
  • 143 (mail key)

These can be configured using xmodmap and a .Xmodmap file configured this way:

keycode 163 = Help
keycode 142 = XF86HomePage
keycode 154 = XF86Search
keycode 143 = XF86Mail

The values on the right (Help, XF86HomePage, XF86Search, XF86Mail) show their XFree86 heritage, but apparently do not change for X.org. These are activated by using the command:

xmodmap .Xmodmap

A good place for this line would be in the .xinitrc. However, once this is set, it is still necessary to tie applications to the shortcuts listed. In KDE, this is done in the Keyboard Shortcuts section of the Regional and Accessibility pane in Settings. In this dialog, select the “Command Shortcuts” tab, then the application you desire to use. For example, “Find Files/Folders” could be attached to the shortcut XF86Search. Once the xmodmap has been modified using the command above, then click on the Custom radio button, and click the shortcut button. Press the actual shortcut button to define the shortcut for the application.

Do this for all four buttons, and all will be well.

Then there was the problem of the mouse not being operational when waking up from a suspend. Turns out that the moused(8) daemon is the culprit. Sending a HUP signal to the daemon fixes it, but having to do this all the time is not a desirable outcome. The utility acpiconf(8) describes how it uses /etc/rc.suspend and /etc/rc.resume before and after suspending the system. I placed the command:

pkill -HUP moused

into this script, but I don’t yet know if it is truly having the desired effect or if other things are causing failures.

Another thing: the CD player would not play CDs in Amarok. Apparently, this is due to HAL and DBUS not being available. HAL depends on DBUS, so both are necessary. The following packages were needed:


I don’t know that all the dbus packages are necessary, but I decided not to chance it. Of course, dbus is part of GNOME, but whatever. Once these packages are installed, add the following to the startup configuration in /etc/rc.conf:


Next time the system boots, these daemons will start.

Also, up until this point X.org had to be started using startx as a normal user. However, adding the login screen isn’t difficult. Edit the /etc/ttys file. In this file, there will be a line that specifies the command xdm.

Since kdm (the KDE display manager, the login screen) is actually a reworked xdm, switching one for the other is smooth and clean. Replace the xdm setting with /usr/local/bin/kdm (keeping the -nodaemon option) and set the tty to “on” (instead of “off”). Then the next time the system starts (or the ttys file is read) a login screen will activate on ttyv8 (if your file is like mine).

FreeBSD 6.3 RC-2 on a Compaq Armada E500

FreeBSD 6.2 has been on this machine for a while, but then I tried to upgrade all of the applications using the ports tree. This almost worked, except upgrading to Xorg turned out to be a massive headache and nothing worked.

It was then that FreeBSD 6.3 RC-2 was announced. I thought, why not? So off I went.

It installed well – if you don’t count my not providing enough room for /usr/local. With my “full-featured” (ha!) list of software, I wound up needing more than the original 2 Gb I originally alloted for /usr/local; with 4 Gb it worked. I also had to change the boot options, as it was still set to use 6.3-RC1 instead of 6.3-RC2. Changing the name in the options screen worked just fine.

Then after loading, I had to load the proper kernel – it couldn’t find the kernel. I selected /boot/GENERIC/kernel and all was well. At the boot loader prompt:

load /boot/GENERIC/kernel

I had to configure Xorg. This was another headache. There was an excellent article from Julien Valroff about instaling Debian GNU/Linux on this machine. Despite the difference in operating systems, the fundamentals were similar. Another fantastic resource was this old page by Frank Steiner. Despite the age, the descriptions are relevant and useful (though, again, it is about Linux). There is a page on the Gentoo Wiki that describes the machine as well, though the other pages are more descriptive.

The screen display descriptions turned out to be the easiest; the problem was the mouse. Some descriptions suggest that the synaptics driver should work. However, this never did work for me. Using the standard PS/2 mouse driver and protocol worked just fine.

I also had to up the maximum files available, though for what reason I forget. Add this line to /etc/sysctl.conf to fix this problem:


Sound was another matter. It took a bit to figure out. First off, all the Linux directions suggested using lspci to see if it was there; this is Linux-specific. The FreeBSD counterpart is pciconf. Running pciconf -lv presents this:

pcm0@pci0:8:0:   class=0x040100 card=0xb1120e11 chip=0x1978125d rev=0x10 hdr=0x00
    vendor     = 'ESS Technology'
    device     = 'ES1978 Maestro-2E Audiodrive, ES1970 Canyon3D'
    class      = multimedia
    subclass   = audio

Thus, I knew that the sound was recognized. I just had to figure out how to get things to work with it. This means kernel support, da?

First attempts to load a driver turned up short; nothing is found in /boot/modules (!). The search path had to be changed to /boot/GENERIC:

kldconfig -i /boot/GENERIC

After this, load the snd_maestro driver:

kldload snd_maestro

After this, sound will work! Amarok is great…… and sound on this machine is excellent too!

Seeing as a I was trying to load KDE on here, the next step (once Xorg is working) is to add a startkde command to the .xinitrc file (in one’s home directory).

To make the system boot properly (and so you don’t have to load kernel modules manually all the time), the /boot/loader.conf file had to be created with this:

# Directory (in /boot) containing kernel and modules
# Load maestro driver

This then worked well.

I’m enjoying this machine again – though I am attempting to make it more of a usable desktop, which means more memory and all of the niggling setup work – like bootup splash screens, configuring kdm, and more – but hey, we’re system admins here, right?