Liberating the Dell Latitude C400

The Dell Latitude C400 is a lightweight (about 1.8kg) notebook with enough computing power to comfortably use it for serious work - it comes with a 1.2GHz PIII, up to 1GB main memory, and a decent video chip. It's actually fun to watch the machine cut through a kernel compile. The following documents my experience with replacing the legacy OS that comes with the machine by GNU/Linux.

The instructions below come with absolutely no warranty. Following these instructions may result in broken hardware, a crippled laptop, and loss of data as well as loss of your sanity.
By now (= year 2004), this page is mainly of historic value. Major distributions, such as SuSE 9.0 as well as Red Hat 9 (and I assume Fedora Core), install on the Dell C400 right out of the box without any fuss. Hence, this page is not maintained anymore.

Summary: The C400 works well with GNU/Linux, but to use high-resolution graphics with more than 256 colours you either need to fiddle with your XFree86 installation and two related Linux kernel modules or purchase a proprietary X server (which has it's own buglets, that you can't fix). Detailed instructions for installing XFree86 are provided below. *new*

Laptops affected by the I830 with XFree86 problem: This page also summarises the problems with Intel's i830 graphics chipset under XFree86 with some laptops. These problems are known to affect the Dell Latitude C400, Dell Latitude X200(?), Dell Inspiron 2600, some models of the Sony PCG R505 series, the Asus S1 series (problem seems to be solved with BIOS rev 0201) and the Asus L1400, and the HP omnibook XT 6050. If you are not interested in the C400, but only in the XFree86 issues with the Intel i830 graphics chipset, proceed to the challenge section. There may be even more i830-based notebooks that have this problem, watch out for an XFree message saying

No matching modes found in the configuration file.
Only the following modes are supported by the bios in this bpp: 640x480
Laptops that are equipped with the newer I845 chipset have the same problem.

The Machine

Before getting to the actual installation and configuration of GNU/Linux, first a couple of remarks regarding the hardware.

Hardware Components:

Details that I like:

Details that I dislike:


I currently have RedHat 7.3 (Valhalla) installed on the machine, pepped up with the latest Ximian Gnome. Other distributions should work similarly, but you definitely need to use one that has a recent 2.4 kernel and XFree 4.2.0 upwards. The main problem with installing GNU/Linux on the C400 is that the video chip i830M is only partially supported by the latest binary release of XFree86 (as of 4 Sep 2002, this is version 4.2.0). However, there is a set of patches (some of which are also in the XFree86 CVS repository), which enable accelerated high-resolution graphics. Consequently, the installation is more hassle than usual, which should be taken into consideration before starting the endeavour.

Before booting from the install CD, a special partition has to be set up if the Linux installation is supposed to support hibernation (aka suspend-to-disk). The BIOS uses this partition to store the contents of main memory (including video memory) to preserve the system state during hibernation. Unfortunately, this partition is not always created as part of the factory installation; at least not if the machine is pre-installed with Windows 98. (I chose Windows 98 to minimse the Microsoft tax; Windows 98 is the cheapest option and I knew that I will wipe it of the harddisk immediately anyway.) However, it appears that Dell recently started to add the hibernation partition in Windows 98 installs. You may want to check the configuration with fdisk before installing Linux.

To create a hibernation partition, you need to fetch the tool mks2d from Dell support. The download contains a DOS executable that creates a DOS boot floppy containing mks2d and fdisk. Make sure you have backed up all important data that is on the notebook's harddisk at this point. Boot the system with the newly created floppy, use fdisk to remove the only existing partition, and then, run mks2d. The latter automatically creates a hibernation partition of the appropriate size. Further information is contained in the text files that are on the mks2d floppy.

The described process will, of course, wipe the existing Windows installation from your harddisk. As I understand the situation, there is no way around this (at least for Dell's Windows 98 installation). If you intend to create a dual boot system, you will have to re-install Windows from the CD's that you got with the machine after you have created the hibernation partition. (Make sure that this leaves the hibernation partition intact.)

The suspension mechanism is somewhat different to the laptops I had before the C400, which confused me somewhat in the beginning. Here is the deal: When you press Fn-Escape (labelled with a blue Suspend), the machine merely suspends to RAM (and it doesn't seem to be possible to change that in the BIOS setup). You can also configure it in the BIOS to suspend-to-RAM when you close the lid. Moreover, there is a timeout period (adjustable in the BIOS setup) after which the machine suspends to disk. Most conveniently, it does suspend-to-disk after that time even if it is already suspended to RAM. (My previous laptop would happily run out of battery while being suspended to RAM.) If you want to suspend-to-disk straight from normal operation, press Fn-A. [This has been kindly pointed out by Calum Mackay.]

Base Installation

I originally performed the base installation from the standard RedHat 7.2 CDs, which worked without any problems. In the meantime, I have updated to RedHat 7.3. But note that, as mentioned above, the XFree86 distribution included in RH 7.3 (ie, XFree86 4.2.0) does not fully support the i830M, which implies that RedHat's installer will fall back to text mode (instead of using the better looking graphical installer). Moreover, you should either skip the X configuration step during the install or make sure that you configure X to use only 256 colours (i.e., 8bpp); otherwise, X will fail to work. Moreover, it is important that when you are asked where to install the boot loader, do not use the master boot record. Instead, install it on your Linux boot partition. Otherwise, suspend-to-disk will not work.

At least with the distribution I have used, the built-in FastEthernet NIC is correctly configured to work with the 3c59x driver. Moreover, sound support works out-of-the-box with the i810_audio driver and the USB subsystem is also correctly setup without any intervention (it uses usb-uhci for the USB controller).

However, at least with old BIOS versions (I still run version A01), the PCI configuration of the machine is not fully restored after hibernation. As a consequence, the built-in FastEthernet does not work anymore after the machine has been hibernated once. This problem can be circumvented by passing the option resume=force to the Linux kernel at boot time. On RedHat 7.3, you can add this option to the kernel line of the GRUB boot loader configuration file /etc/grub.conf. On other GNU/Linux systems, edit your GRUB or LILO configuration file correspondingly.

Note to Debian users: Calum Mackay points out that the "fancy text" installer that Debian uses switches the video into a mode that causes a nasty flashing and offset text. Whilst it's possible to just use that as is, it's much better to switch back to a non-fb mode.

When initially booting the Debian install disk (floppy/CD), the user should type (when prompted):

boot linux video=vga16:off

This makes the initial install fine; once the basic system is installed, the system will reboot, and again will have the "wrong" mode selected. I would then suggest users should then immediately edit /etc/lilo.conf, adding vga=773 to fix it properly (as mentioned below).

Wireless Network Setup

The machine can optionally be equipped with a built-in wireless card, which occupies Slot 1 of the PCMCIA controller. (Slot 0 is the one where you can actually plug in a normal PCMCIA card.) The built-in card sold under the name TrueMobile 1150 by Dell is actually based on the popular Intersil Prism II chipset, which is compatible to the "Hermes" wireless MAC controller used in Lucent's Orinoco cards. As a result, recent Linux 2.4 kernels (any kernel from 2.4.7 on should be ok) already come with all the required driver infrastructure in place.

However, flawless operation requires some tweaking of configuration files. Firstly, edit the file /etc/pcmcia/config by searching for the card named "Intersil PRISM2 11 Mbps Wireless Adapter" and changing the bind declaration from "wvlan_cs" to "orinoco_cs". This makes sure that you use David Gibson new driver instead of the old WaveLAN driver, which, for example, is curcial if you want to operate the card in Ad-Hoc mode (i.e., peer-to-peer networking without an access point). Secondly, add to /etc/modules.conf the line

alias eth1 orinoco_cs

That's it! Note that you can use PCMCIA schemes to configure the card for different wireless networks by editing /etc/pcmcia/wireless.opts. The already existing scheme called essidany should, however, do the job for most access point-based networks. (You can select this scheme by issuing cardctl scheme essidany as root.) You can find more details about the driver on Jean Tourrilhes' excellent Web pages.

Wireless Configuration Tip #1:

With both an Ethernet and a wireless NIC built-in, the order in which network device drivers get initialised, unfortunately, becomes important. More precisely, both drivers (the 3c59x for the Ethernet NIC as well as the Orinoco driver for the wireless NIC allocate network interfaces named ethN. The Linux kernel assigns interface numbers (i.e., values for N) contiguous starting from 0 in the order that the interfaces are registered by the device drivers. As the same names are used in the network configuration scripts and the scripts for the two different NICs are often different, it is important that a given NIC always gets the same interface name. Hence, as the kernel allocation policy makes interface names dependent on the initialisation order, it becomes important to initialise the network device drivers always in the same order.

I found that it is easier to guarantee (at least in my system setup) that the wireless card is initialised first. Hence, I use eth1 for wireless and eth0 for Ethernet. To support this association, I put the following in /etc/modules.conf the following two lines:

alias eth0 3c59x
alias eth1 orinoco_cs

(Don't forget to run depmod -a after changing this file.)

Wireless Configuration Tip #2:

To guarantee proper operation of the wireless NIC after suspending the laptop, I found that it is advisable to edit /etc/sysconfig/apmd and set the value of the variable PCMCIARESTART to "yes". This instructs the APM daemon to shutdown and restart the entire PCMCIA subsystem before and after suspension.

Wireless Configuration Tip #3:*new*

If you install Red Hat 7.3 or 8.0 on the C400, then be warned that the version of the orinoco driver that is included in the default kernel (2.4.18-3, 2.4.18-10, or 2.4.18-17.8.0) is buggy. I solved this problem by installing the orinoco driver version 0.13a. For details, see bug #64811 in Red Hat's Bugzilla database.

Installing the Linux Kernel

It is advisable to use kernel version 2.4.11 or later with the C400, as that version adds support for the i830M, especially to the AGP GART support. Consequently, XFree's DRM (Direct Rendering Manager, which is needed for the DRI - Direct Rendering Interface) won't work with earlier versions of the kernel. I am currently using kernel version 2.4.18-10 (i.e., RedHat's patchlevel 10 of the 2.4.18 kernel). This kernel works fine, although a couple of tweaks are needed to properly support orinoco wireless cards (outlined above) and accelerated graphics with more than 256 colours (outlined below).

If you want to compile your own kernel, there are a number of points that you should take care of during kernel configuration:

Before you compile the kernel, you need to apply the AGP GART kernel patch, which you can find in the section about XFree86.

Internal Modem

The C400 includes a softmodem (i.e., only part of the hardware that make a conventional modem), which are notoriously difficult to use under Linux because of lack of vendor support and device documentation. The softmodem in the C400 identifies itself as PCI device id 8086:2486, which according to this device table is the same as the 2304WT V.92 MDC modem from PCTel.

David Plaut reports that Jan Stifter's PCTel modem driver version 0.9.4 works out of the box with the modem contained in the C400. (I haven't tried this myself, yet.)

XFree86: The Challenge

In order to get XFree86 running on the C400, you can follow the elaborate procedure outlinded below, or you can simply install the CVS snapshot tagged, which is available from the CVS repository of the XFree86 project. For users of RedHat 8.0, I recommend the current rawhide rpms [or any other Red Hat mirror] for XFree86. (If you compile straight from CVS, you will have some problems with fonts on RH8.0, which these customised rpms avoid.) Be sure to install them all and to restart the font server after installation (reboot if you are unsure).

With the CVS version of XFree86, everything works beautifully on my C400 (and there is now even XVideo support), except that X crashes if I switch to a virtual text console during an X session. Moreover, there seem to be some problems when using a framebuffer console.

*new* Basil Dewhurst reports that "Redhat's beta Phoebe (date: 2002-12-21) works fine after installation if you select the "Dell 1024X Laptop Display Panel" for your monitor and set the res to 1024x768." So, I hope the graphics problems is entirely a matter of the past once RedHat releases Phoebe.

Since version 4.2.0, XFree86 includes support for the Intel i830 family of graphics controllers. Unfortunately, Intel has decided that - in contrast, to previous chipsets in the i810 series - they do not publicly release detailed programming information for the i830 (and it's successor, the i845). This is rather disappointing and should be noted by all users of open-source operating system, as this policy slows down the development of reliable device drivers, as the example of the i830 has clearly demonstrated. In fact, Intel's i830 page is actually misinforming. As of 4 Sep 2002, it says in a note that ``[t]here is currently no Linux driver to bypass legacy memory limitations. The Linux drivers for the Intel 830M/MG chipset graphics do not currently support full video memory usage; that is, you will always be limited to the BIOS pre-determined memory amount. This is due to the dual-pipe graphics architecture of the Intel 830M/MG chipset graphics.'' As a matter of fact, this doesn't have anything to do with dual-pipe graphics architecture, but is entirely due to Intel withholding, on purpose, crucial technical information about the chipset. On the positive side, the statement in the first sentence is also wrong as, a GNU/Linux driver to bypass the legacy memory limitations is now available. Bad marks to Intel for an attempt to deceive customers. I am also rather disappointed by Dell, who apparently make 10% of their server sales with GNU/Linux, but don't care enough to apply a simple fix to their BIOS when a quite significant number of their customers require to run GNU/Linux on one of Dell's more expensive laptops. Bad marks for style and customer service! All this will certainly affect my next purchase decision and I would like to encourage other GNU/Linux users to consider this, too.

Similar patches as the ones provided below are in the XFree86 CVS repository since a couple of weeks (i.e., since August 2002). However, they require you to start the X server in 8bpp first, before you can use it in 16bpp mode. The patches provided here do not require this.

NB: I am using a VESA graphics mode for my Linux console. In this configuration switching between X and virtual consoles seems to work fine. The VESA mode that I am using is 773. You can configure this by adding the kernel option vga=773 to your boat loader (either GRUB or LILO) configuration. In RedHat 7.3, this configuration is in /etc/grub.conf (add the option to the kernel line).

Kernel 2.4.18-10 on RH7.3: If you get errors complaining about a conflict of module versions, downgrade the modutils package to the version that you had before updating the kernel (ie, the same version that is on the RH7.3 CDs).

Installing and Patching XFree86

To simplify the installation process as well as later maintenance, I did not compile the entire XFree86 distribution from source. Instead, I installed the XFree86 4.2.0 packages from the standard RedHat 7.3 distribution, and then, compiled and installed a patched version of the i830 driver module for the X server as well as of the i830 and agpgart kernel modules. The same or a very similar procedure should work for other GNU/Linux distributions. (I would be happy to include concrete instructions for other distributions if anybody can supply them.) However, there is no reason why you shouldn't be able to use the below procedure when compiling the entire XFree86 distribution from source.

For RedHat users that are running exactly the same software versions as I do (i.e., Linux kernel 2.4.18-10 and XFree86-4.2.0-8), I also provide binaries of the i830 driver module and of the two Linux kernel modules. These binaries are accessible via the links placed at the copy commands used to move the binaries to the right place in the installation instructions below. However, note that you download this entirely at your own risk. I do not provide any warranties whatsoever and would generally advise against downloading binary files from random places on the net and run them with root privileges.

Firstly, you need to get the XFree86 4.2.0 source distribution. If you are, like me, patching a binary distribution, you need to obtain the matching source package. In the case of RedHat 7.3, this is XFree86-4.2.0-8.src.rpm, which you can find on the source CD or on any RedHat ftp mirror. If you start from scratch, check out XFree's ftp server.

Secondly, unpack the source package and patch the i830 driver of the X server. To unpack, for the RedHat 7.3 source rpm, as root

% rpm -i XFree86-4.2.0-8.src.rpm
% cd /usr/src/redhat/SPECS
% rpm -bp XFree86.spec
% cd /usr/src/redhat/BUILD/XFree86-4.2.0/
% patch -p0 <i830_driver-1mb-stolen-hack.patch
If you are not using the RedHat package, unpack your distribution, enter the base directory, and apply the same patch command as above.

Thirdly, compile the beast as follows:

% cd xc
% echo "#define BuildServersOnly YES" >>config/cf/host.def
% make World WORLDOPTS=
<Go get a cup of tea or coffee and read a book for a while>

This takes a while as the whole X server gets compiled. (I don't know how to avoid this.) Finally, copy the patched i830 driver module to it's rightful place in the installation directory:

% cp exports/lib/modules/drivers/i810_drv.o /usr/X11R6/lib/modules/drivers

This will overwrite the original driver; if you want to keep it, move it to a save location first. If you are compiling the whole XFree86 package (instead of patching a binary distribution), just compile and install XFree86 as described in the standard XFree86 installation instructions.

Patching XFree86 Support in the Linux Kernel

XFree86's Direct Rendering Infrastructure (DRI) requires kernel support for accelerated graphics and, in particular, hardware-accelerated OpenGL support. This kernel support is implemented in two kernel modules, namely the i830-specific i830 module and the general AGP module agpgart. Unfortunately, we need to patch both of these modules. This is not too hard for the i830 module, as it is included in the XFree86 distribution; it is more of a hassle for agpgart, as we have to work from the Linux kernel distribution for that.

NB: It appears as if no kernel patches are required for users of the 2.4.19 kernel.

Let's start with the i830 module. It is in the XFree86 tree used in the above instructions. So, to patch, compile, and install the module, we can just carry on like this:

% cd programs/Xserver/hw/xfree86/os-support/linux/drm/kernel
% patch -p10 <i830-drm.patch
% make -f Makefile.linux
% cp i830.o /lib/modules/<version>/kernel/drivers/char/drm
where <version> is your kernel version (as reported by uname -r). If you want to preserve the original module, move it away before the last of the above commands.

To patch and recompile agpgart, you need a Linux kernel tree for the kernel version that you are running. In the case of RedHat 7.3 (including current updates), this is the kernel-source-2.4.18-10.i386.rpm package. In the following, I assume that you have installed the Linux source tree under /usr/src/linux-<version>/ as usual.

% cd /usr/src/linux-<version>/
% patch -p1 <agpgart-i830.patch
% cp configs/kernel-2.4.18-i686.config .config
% make oldconfig
% make dep
% make modules
The above mentioned configs/ directory will only be available if you are indeed compiling a RedHat source tree. Otherwise, I have provided the config file via the link above. You can, of course, also configure your own kernel, but then you may want to have a look at the kernel configuration hints above.

(The above patch assumes an extra argument to do_munmap(), which seems only to be present in kernels patched by RedHat. The vanilla 2.4.18 and 2.4.19 kernels don't have this argument. If you do not use a RedHat kernel ignore the patch lines that add the extra argument. If this constitutes a problem; e.g., as you don't know how to ignore them, please send me an email.)

When compilation finishes, all that remains is to copy the patched agpgart module into the module directory as follows:

% cp drivers/char/agp/agpgart.o /lib/modules/<version>/kernel/drivers/char/agp/
% depmod -a
where <version> is your kernel version.

Update [11 September 2]: *new* David Dawes announced a a re-work of the I830/I845 driver, which is already available from XFree86's CVS repository. I had a quick look at the code and it looks much saner than the previous stuff including my variant of Abraham vd Merwe's magic bit fiddling to solve the 1MB stolen memory problem. (Though, I haven't tried the code yet.)

Update [11 September 2]: *new* According to Calum Mackay, the revised driver mentioned in the previous paragraph works fine on the C400 without any need for extra patches if the 2.4.19 kernel is used. However, you need to perform a full X build and the new DRI driver can cause video hangs when switching VTs.

Configuring XFree86

Running XFree86 -configure didn't work properly for me; so, I proceeded to manually tweak the default configuration file. The device section can be kept quite short:

Section "Device"
	Identifier   "i830M"
        Driver       "i810"
	VideoRam     32768

All parameters expect the amount of video RAM to nick from main memory via the AGP GART interface are automagically determined by the driver. The use of 32MB of video RAM is one of many possible setting, you can choose to use more or less.

In addition, I am currently using the following screen section:

Section "Screen"
	Identifier   "Screen0"
        Device       "i830M"
        Monitor      "Monitor0"
	DefaultDepth 16

	Subsection "Display"
        	Depth       8
                Modes       "1024x768" "800x600" "640x480"
	Subsection "Display"
        	Depth       16
                Modes       "1024x768" "800x600" "640x480"

If you like, try my XF86Config-4.c400 by copying (or linking) it to /etc/X11/XF86Config-4 to use it as the default configuration on your machine.

The I830 Odyssey

The following archives the events since I first tried to run XFree86 on the i830 up to where Abraham vd Merwe produced a patch that circumvents the broken BIOS. There is no need to read this account to configure XFree86, but I left the information on this page in case somebody is interested in the development.

If you try to run XFree86 with 16bpp at 1024x768 (the native resolution of the LCD panel), the X server will terminate with an error message saying that the BIOS only supports 640x480 at the specified colour depth. As far as I understand the situation, this is for the following reason (see also Intel's support page concerning video memory in the i830M). The i830M manages two types of main video memory: (1) dynamically allocated memory and (2) legacy VGA/SVGA memory. The former is determined by the VideoRam declaration in the device section of the XFree68 configuration file and is used for realising accelerated 2D and 3D graphics via the DRI. The latter is determined by the BIOS (or OS) on system startup and is what restricts the available colour depth/resolution configurations. Intel claims on it's support page that the amount of legacy VGA/SVGA memory is an option in the BIOS setup. Unfortunately, this doesn't seem to be the case in the Dell BIOS that comes with the C400. Instead, this BIOS always selects to use 1MB of legacy VGA/SVGA memory, as witnessed by the following message of the agpgart.o kernel module at boot time:

agpgart: Detected an Intel 830M Chipset.
agpgart: detected 1024K stolen memory.

(From inspecting the kernel source, it seems that the stolen memory is what Intel calls legacy VGA/SVGA memory.)

The i830M supports three settings for legacy VGA/SVGA memory: 512kB, 1MB, and 8MB. To get the 1024x768 at 16bpp or even 24bpp, I guess that the i830M needs to be initialised with 8MB of legacy VGA/SVGA memory. (32bpp are not supported by the XFree86 driver for i810/i830.)

Update [3 January 2]: I have done some more experimenting and it seems rather clear at the moment that the main problem in getting 1024x768 to run at 16bpp is the Video BIOS. I have summarised my findings in a message to the XFree86 Xpert mailing list.

Update [11 January 2]: Abraham vd Merwe, the developer of the i830M support in XFree86 has kindly provided me with some more information. Intel's i830M BIOS does not support switching into 1024x768 at 16bpp or 32bpp with 1MB of stolen memory and Intel apparently refuses to add this functionality. According to Intel, OEMs are not supposed to release BIOSes that allow only 1MB of stolen memory. Hence, we need to get Dell to update the BIOS *sigh*

So, if you have a Dell C400 and want to have XFree86 work properly on the machine, call Dell support and urge them to update the BIOS to either steal 8MB video memory by default or allow the user to select the amount of stolen memory in the BIOS setup dialog.

There is one other way around the problem, namely to ignore the BIOS for setting video modes and to program the hardware directly in the video driver. I will try this when I get time.

Update [31 January 2]: XFree 4.2.0 is out and it contains support for the i830M; so, you don't need to compile from CVS anymore, but you still need to make sure that you get a sufficiently recent Linux kernel and possibly update the i830.o kernel module. Unfortunately, that does not help us with the C400 due to the BIOS issue outlined above. I did some experimenting with mode sets, but due to lack of documentation and time, I didn't get very far yet.

Update [20 February 2]: As has been pointed out by a couple of people, the BIOS update A03 from Dell does unfortunately not solve the problem with stolen memory.

Update [19 March 2]: Xi Graphics proprietary X server has has working support for the C400. (Both 16K colours and 16M colours as well as external monitors work with that X server.) This clearly demonstrates that it is the lack of support from Intel, which really prevents us running XFree86 properly on the C400. I am quite sure that Xi Graphics got the docs that we have been waiting to get for quite a while (in fact, I have specifically asked an Intel support person to provide me with a copy, which I haven't got). So, I'd propose that in addition to complaining to Dell, you also complain to Intel if you don't like the way they handle their customers.

Update [26 March 2]: The Sony R505DL and the Asus S1 seem to have the same problem with a BIOS that only pre-allocates 1MB of video memory.

Update [2 May 2]: The HP omnibook XT 6050 also has the same problem with a BIOS that only pre-allocates 1MB of video memory.

Update [4 June 2]: Philipp Holzschneider reports that the BIOS rev 0201 for the Asus S1 preallocates 8MB of video memory, and thus, solves the problem with XFree86.

Update [20 June 2]: I have had multiple reports saying that Dell's A04 BIOS update for the C400 does not solve the problem.

Update [21 June 2]: Abraham vd Merwe came up with a surprisingly simple change to make the XFree86 drivers work in higher colour mode on the C400. Jon Gans' Gateway 1450 page has the patch.

Update [8 July 2]: Gen IGUCHI reports that he got XFree86 to work on the Sony VAIO R505 X/PD using the patch from Abraham vd Merwe (linked in the previous entry [21 June 2]):

Kernel 2.4.18 with acpi-patch; XFree86 4.2.0 from CVS

1. I patched the "agpgart-I845G-fix-2.4.19-pre9.diff" patch and have rebuilt
  the kernel, following the instructions.

2. I downloaded the latest XFree86 from the CVS server, patched the
  "1mb-stolen-fix.diff" and have compiled it.
  As per the instructions, initially, I started my X with 8 bits, then
  switched to 24bits (16bits will work, too).
Update [12 July 2]: Guy Marcenac reports that he got his Dell Latitude C400 (with BIOS A04) running Basic Slackware 8.0 and kernel version 2.4.18 properly working with XFree 4.2.0 using 16bit colour depth. He compiled XFree from sources and applied the patch from Jon Gans' site (which was reported earlier). He also has to resort to the trick that he starts the server in 8bit mode first, quits, and then, restarts in 16bit mode.

This page is part of Manuel Chakravarty's Web space.

Last modified: Mon Jan 5 10:52:51 EST 2004