Using the information on these pages, and any files downloaded in relation to this page, is done entirely at your own risk. If your spanking new Tecra goes up in flames, then you have my sympathy, but that's all.
These are described in more detail later, but summarized here for those just wanting to get something working.
|Video - Intel GM45 Express Chip||Works with adjustment|
|Wireless - Intel Wifi 5000 AGN||Works with adjustment|
|Audio - Intel 82801I ICH9||Works with adjustment|
|Fingerprint reader - Authentec AES1610||Almost works with adjustment|
|Ethernet||Works - Module e1000e picks it up|
|USB - EHCI and UHCI||Works - adjustment suggested though|
|Trackpad/Nipple (ALPs)||Works - adjustment suggested though|
|Headphone Socket||Works (once general audio is working)|
|Card Reader||Probably works|
I used amd64 Lenny (testing at time of writing) with a network install. I needed to use the ethernet connection - nothing appeared to be available for performing a wireless install.
X was able to start and run, although at a degraded resolution. However, when I 'upgraded' to unstable X stopped working. However, this problem is fixable.
If you're new to Debian/Linux, then you might need to read some background information before tackling all of this install. There are plenty of tutorials out there. I'm only describing getting the hardware working. As a quick reference if you want to move to unstable (I don't think it's necessary):
/etc/apt/source.listso that it contains just:
deb http://ftp.uk.debian.org/debian unstable main contrib non-free
deb-src http://ftp.uk.debian.org/debian unstable main contrib non-free
synapticto reload the sources, mark all upgrades, and then apply the changes.
There was no getting around it - a kernel recompilation was necessary in order to use the built in wireless (note that an extra step was also required for the wireless to work).
As installed, the kernel was version 2.6.26. I knew that
I wanted to play with
ext4 so I downloaded 2.6.28 from
For those that intend to replace their kernel, i'm providing three options. Only one is really recommended - the full version where you do everything. However, I appreciate that not everyone wants to do this and some are willing to take a risk on a downloaded file from an untrusted website. Hence, the later options.
I am well aware that you're not supposed to do all of the following as root. With that said, I did it as root.
apt-get install zlib1g-dev(needed to avoid lguest compile error)
apt-get install build-essential fakeroot
apt-get install kernel-package
apt-get install libncurses5-dev
cd'd to the new directory
make menuconfigto make editing the config file easier (mine is available here if you just want to copy that. The following changes were made:
CONFIG_IWLAGN. This can be found in Device Drivers|Network Device Support|Wireless LAN|Intel Wireless WiFi Next Gen AGN.
CONFIG_IWLAGN_SPECTURM_MEASUREMENT), LEDS feature (
CONFIG_IWLAGN_LEDS), and Intel Wireless Wifi 5000AGN (
CONFIG_IWLWIFI_RFKILL) - it's also in the same area.
CONFIG_USB_EHCI_HCDto be compiled into the kernel, rather than as a module. The USB section explains the reasoning behind this. You can find this setting at Device Drivers|USB Support|EHCI HCD (USB 2.0) support.
.configfile has been written, we can compile:
fakeroot make-kpkg --initrd kernel_image kernel_headers.
dpkg -ion both of the
.debfiles just created.
Instead of creating the
.config file yourself, use
Trouble with this option is that you're downloading unverified kernels. Do so at your own risk - you can't hold me responsible for any damage. If the thought of compiling your own kernel scares you more than the thought of trusting unverified code, then you should download:
And then install them both with
dpkg -i. The linux headers
may be required if you need to do an out of tree compilation, e.g. with
The kernel needs to be recompiled in order to have the
correct driver. On top of that, the driver requires firmware to be
iwlwifi-5000-ucode-5.4.A.11.tar.gz. Once downloaded,
untar it, and copy the
/lib/firmware. I restarted at this point to make sure
that it found it and used it correctly.
You'll need to set up
/etc/network/interfaces or whatever
way you want to configure the network on your system. This task was only about getting
the hardware working, not full configuration.
This needed no special attention. I tested that it worked by running a
ping, and then turning the switch to off. The pings stopped,
so that was good enough for me. When turning it on, my simple
/etc/network/interfaces meant that the interface did
not come back up, but an
ifdown wlan0; ifup wlan0 sorted
The 'upgrade' to unstable broke what was a working, albeit degraded, X. I'm
not sure what my
/etc/X11/xorg.conf file looked like before the
upgrade, but I know that afterwards it didn't contain much, and that the
X server couldn't start because it couldn't work out a valid resolution.
To get X working again required some changes to the
/etc/X11/xorg.conf. You can find my modified file
here - this can be just copied over yours and
gdm restarted with
/etc/init.d/gdm restart. However,
see the caveats about this file in the next section.
After finding help from another
It was clear that the driver (
xserver-xorg-video-intel) and other settings needed to be set in the
xorg.conf. Fortunately, there is no need to
recompile the driver. Following a
Xorg -configure to create a basic
which I then modified to support the trackpad properly, amongst other things.
xorg.conf was modified to not
only support the video driver but changed the driver for the trackpad to
the synaptics driver (already installed as part of the basic installation).
Two things to realize about my
synclient. This is considered a potential security threat.
Therefore, if you're going to use it (feel free), then you'll probably
be making some changes. Probably the easiest
place to find out more about this driver is in the file
/usr/share/doc/xserver-xorg-input-synaptics/README, and the
README.alps. The Toshiba has an ALPs trackpad.
A further mouse section was added to allow external mice to optionally be plugged in.
One other change that you may wish to consider is disabling the caps-lock key.
I'm not a fan of caps-lock, and i'm
not alone. I choose to disable it by moving
Default, and then adding:
xmodmap -e "keycode 66=".
This is possibly not the best use because it now doesn't do anything, but for me
that's better than the default.
Only a minor changed required to make this one work, but it required
The only thing that's necessary to get audio working is to edit
/etc/modprobe.d/alsa-base and add
options snd-hda-intel model=toshiba at the end. After a restart
(yes, there's bound to be a way avoiding a restart), the sound should
be working. I found that the volume was already set to a non-zero value.
However, I have been caught out before, so if this didn't work for you,
then please check the volume first before wasting your time with anything else.
This may seem an odd one because surely, once the audio is working, the headphones are working? Well, no, actually. I've had two other machines (an Acer and a Fujitsu) that could play sound but there was a problem when headphones were involved. The good news is that the Tecra is not like those machines so this didn't require any effort once the audio was working.
At the time I tried this, there was good news and bad news. The good news is that the hardware works. The bad news is that I couldn't get it to reliably verify my fingerprint so I personally decided to abandon the idea of using it for login. I shall describe here the steps that I took to get to the point of experimentation.
At the time of writing, neither unstable nor the kernel had drivers for the AES1610. The 'experimental' version of Debian does but that sounds much scarier than unstable. In order to get the drivers, and support programs, I downloaded the following source files:
libfprint provides the userspace drivers for
the fingerprint reader. The
fprint_demo program allows you
to play around with the reader (quite a nice program actually), and the
pam_fprint library would allow the finger print reader to
log you in. I didn't play with the pam part.
In order to compile
libfprint, some development libraries
apt-get install libusb-dev libssl-dev libglib2.0-dev libmagick9-dev
After uncompressing the
libfprint files it can be compiled with:
The usual compiling as root caveat applies! More instructions
can be found here.
fprint_demo can be compiled using:
make install(I doubt it's really necessary to install)
You should now be able to run
fprint_demo as root. I found that
I couldn't get a reliable verification, a problem that is being
If you still have windows on your machine, then you might be able to
help by snooping on the USB traffic.
This just worked but with a slight wrinkle. I've had trouble with EHCI
controllers on older laptops so I was interested to see what was in
syslog about it. It showed that the UHCI driver was being
loaded first and recommended that the EHCI (USB 2.0) driver should
always be loaded first. I decided to cheat and compiled the EHCI
driver directly into the kernel while leaving the UHCI driver as a
PCMCIA, Cardbus, or whatever it's called these days just worked. I tested
it by plugging in a USB port card and I could see all of the hub registration
Bluetooth just worked. I could view the contents of my mobile phone through gnome.
Both hibernation and suspension worked without issue when I tested them. I haven't used them exhaustively, so prolonged use may prove that they don't work as well as when I first played with them. The only issue I noticed after hibernation was that I had lost bluetooth.
I couldn't test the card reader although I believe that it's working. The
reason that I couldn't test it was because I only had an Xd card available,
and apparently that's not really
From the information in that article, and reading through the output of
lspci, I get a good feeling.
Untested. Couldn't even see an entry in
This wasn't tested conclusively because I tried to test it and I don't know whether the test means that it failed. I took an external drive connector, and an HDD and plugged it in. Nothing happened (no spin-up) so i'm wondering if the drive couldn't take power from the eSATA cable. Maybe it needed an external supply. Hence, I can't say one way or the other.
The following information is no longer relevant, or at least not
at the time of writing (14th Oct 2009). I've just changed to lenny as
a stable distribution and upgraded to Workstation 6.5.3. I didn't need
to do any monkeying around with the
vmnet drivers. However,
i'm leaving the paragraph in here for future reference.
Getting VMWare working was critical for me, and this is where I had a little trouble. It's working now though, through some help.
At the time of writing, I was testing VMWare Workstation 6.5, on a system
running kernel 2.6.28 - there's an issue there. Once vmware has been installed
it is unable to use two of its important kernel modules -
vmnet. The workaround is a little bit scary and my well be
unecessary in later version of VMWare.
I shall recap on the original instructions here:
/usr/lib/vmware/modules/sourceinto a directory where you can play with them
make. This succeeded for me in all directories other than
vmppuser-only. I don't know what this module does but it doesn't seem to have prevented it from working.
.kofiles should now be copied. You can find the
.ofiles in the directory that contains the module directories. Each of the module directories contains its own
.kofile. They should then be copied into
There was also a slight problem, some time after installing, that caused the keyboard seemingly mad. This was remedied using the xkeymap.nokeycodeMap trick from the forums.
lspci- short - verbose
lsusb- short - verbose