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.
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
Laptops that are equipped with the newer I845 chipset have the same problem.No matching modes found in the configuration file. Only the following modes are supported by the bios in this bpp: 640x480
Before getting to the actual installation and configuration of GNU/Linux, first a couple of remarks regarding the hardware.
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
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
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
Fn-A. [This has been kindly pointed out by
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
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
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
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
vga=773 to fix it
properly (as mentioned below).
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
searching for the card named
"Intersil PRISM2 11 Mbps Wireless
Adapter" and changing the
bind declaration from
"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,
/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
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.
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.)
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
"yes". This instructs the
APM daemon to shutdown and restart the entire PCMCIA subsystem before
and after suspension.
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.
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.
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.)
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
220.127.116.11, 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.
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 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).
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
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
If you are not using the RedHat package, unpack your distribution, enter the base directory, and apply the same% 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
patchcommand 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.
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
agpgart. Unfortunately, we need to patch both of
these modules. This is not too hard for the
as it is included in the XFree86 distribution; it is more of a hassle
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:
where <version> is your kernel version (as reported by% 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
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.
The above mentioned% 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
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
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:
where <version> is your kernel version.% cp drivers/char/agp/agpgart.o /lib/modules/<version>/kernel/drivers/char/agp/ % depmod -a
Update [11 September 2]: 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]: 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.
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 EndSection
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" EndSubsection Subsection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubsection EndSection
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 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
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
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]):
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.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).
This page is part of Manuel Chakravarty's Web space.
Last modified: Mon Jan 5 10:52:51 EST 2004