mirror of https://github.com/tLDP/LDP
610 lines
23 KiB
Plaintext
610 lines
23 KiB
Plaintext
<!DOCTYPE Article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
|
|
|
|
<article>
|
|
|
|
<artheader>
|
|
|
|
<title>i810 with XFree86 4.x HOWTO</title>
|
|
<author>
|
|
<firstname>Toby</firstname><surname>Russell</surname>
|
|
</author>
|
|
<pubdate>May 2001</pubdate>
|
|
|
|
<revhistory>
|
|
<revision>
|
|
<revnumber>1.1</revnumber>
|
|
<date>2001-05-09</date>
|
|
<authorinitials>tr</authorinitials>
|
|
<revremark>
|
|
</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>1.0</revnumber>
|
|
<date>2001-05-01</date>
|
|
<authorinitials>tr</authorinitials>
|
|
<revremark>
|
|
Initial release.
|
|
</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
|
|
<abstract>
|
|
<para>
|
|
This HOWTO describes getting XFree86 4.x running on Intel's i810 graphics
|
|
chipset by using special features of the 2.2.18 and 2.4.x kernels.
|
|
</para>
|
|
</abstract>
|
|
</artheader>
|
|
|
|
<sect1>
|
|
<title>Introduction</title>
|
|
|
|
<para>
|
|
This document has a very specific purpose; to help people who are failing to
|
|
get X working on Intel's i810 graphics chipset (hereafter "the i810"). It is
|
|
written by a beginner (me), and it is imagined that it will be of use
|
|
primarily to other beginners. The author would be flattered to hear that he
|
|
has helped anyone more skilled than he. Furthermore, I know that the i810
|
|
works with XFree86 3.3.6, but I personally have not trod that path. My
|
|
experience comes purely from XFree86 4.0 (hereafter "X4.x") and the
|
|
i810/agpgart support available in the 2.2.18 and 2.4.x kernels, and
|
|
consequently this HOWTO tackles that solution, or procedure, alone. The
|
|
instructions that follow were written to the 2.4.x compile tune, but the
|
|
procedure is similar enough to be translatable to the 2.2.18. Use your head, as
|
|
Tony Buzan would say, and read the READMEs to be sure of any required alterations
|
|
of method.
|
|
</para>
|
|
|
|
<para>
|
|
Even though I know this procedure works I feel obliged to point out that what
|
|
I have recorded here is mostly that which I have worked out in my own bumbling
|
|
way. It may well be that others know a quicker and more efficient method than
|
|
that which follows. If so I will be happy to hear from them. As I mentioned
|
|
previously, the i810 will work with XFree86 3.3.6, if one also uses some
|
|
drivers designed by Intel for the task (namely XFCom_i810-1.2-3 and
|
|
I810Gtt-0.2-4) but, in the interests of Linux purity, and of course knowing
|
|
one does not have to use Intel's software, I recommend the method detailed
|
|
here. It does not need Intel drivers.
|
|
</para>
|
|
|
|
<para>
|
|
Finally, no introduction would be complete without the following words of
|
|
caution; this HOWTO should be regarded as a 'bare bones' set of
|
|
instructions and should therefore be followed with all relevant README
|
|
literature to hand. What follows is not exhaustive by any stretch of the
|
|
imagination, and needs, at least for beginners, said README stuff.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Down to business</title>
|
|
|
|
<note><title>Note</title>
|
|
<para>Do everything that follows logged on as root.</para>
|
|
</note>
|
|
|
|
<para>
|
|
There are three distinct stages that need <emphasis>not</emphasis> be followed
|
|
in the order listed here (please feel free to use your imagination). Said
|
|
stages are;
|
|
</para>
|
|
|
|
<itemizedlist mark=bullet>
|
|
|
|
<listitem>
|
|
<para>
|
|
get and install X4.x
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
get and compile kernel 2.2.18 or 2.4.x (including mknod agpgart stuff)
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
nimbly tweak XF86Config
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
|
|
<sect2>
|
|
<title>Getting and installing X4.x</title>
|
|
|
|
<para>
|
|
The first stage is of course listed only as a guide for those who have perhaps
|
|
tried getting XFree86 3.3.6 working with the i810 and failed, or perhaps those
|
|
who have not even heard that X4.x supports the i810 and have been struggling
|
|
vainly with their <filename class=headerfile>XF86Config</filename> file. I
|
|
suppose the majority of people who find these instructions useful will have
|
|
already loaded X4.x. You lot can skip this bit. Anyway, if you do need to
|
|
know, X4.x can be got from; <ulink
|
|
url="ftp://ftp.xfree86.org/pub/XFree86/4.0/binaries"></ulink>
|
|
</para>
|
|
|
|
<para>
|
|
But before you rush ahead and download away you must first be sure which
|
|
version of X4.x suits your system. So download <filename
|
|
class=headerfile>Xinstall.sh</filename> on its own and run (from within the
|
|
folder containing <filename class=headerfile>Xinstall.sh</filename>):
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>sh Xinstall.sh -check</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
The results will direct you to the correct folder within the above mentioned
|
|
URL from where the appropriate files for your system can be downloaded.
|
|
</para>
|
|
|
|
<para>
|
|
For a basic installation and to save time downloading one needs only the
|
|
following absolute necessities, without exception (the others are optional and
|
|
when included in the install process, I feel, increase the chances of things
|
|
going wrong for the unwary and inexperienced):
|
|
|
|
<simplelist type=vert columns=3>
|
|
<member><filename class=headerfile>extract[.exe]</filename></member>
|
|
<member><filename class=headerfile>Xbin.tgz</filename></member>
|
|
<member><filename class=headerfile>Xlib.tgz</filename></member>
|
|
<member><filename class=headerfile>Xman.tgz</filename></member>
|
|
<member><filename class=headerfile>Xdoc.tgz</filename></member>
|
|
<member><filename class=headerfile>Xfenc.tgz</filename></member>
|
|
<member><filename class=headerfile>Xfnts.tgz</filename></member>
|
|
<member><filename class=headerfile>Xetc.tgz</filename></member>
|
|
<member><filename class=headerfile>Xvar.tgz</filename></member>
|
|
<member><filename class=headerfile>Xxserv.tgz</filename></member>
|
|
<member><filename class=headerfile>Xmod.tgz</filename></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
Now knowing which set of files are suited to your system you can go ahead and
|
|
download whichever suits. Then install with the following command (from within
|
|
the folder containing freshly downloaded files):
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>sh Xinstall.sh</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
If you have been good everything will proceed smoothly. You will be asked some
|
|
questions which the README file can explain/answer better than I. If something
|
|
doesn't work as expected I refer you to the far more detailed, aforementioned
|
|
README file, which you should definitely peruse. As a newbie I always read the
|
|
readme files before downloading, installing, compiling and even getting up
|
|
from my seat to go to the toilette. You can never be too sure.
|
|
</para>
|
|
|
|
<para>
|
|
That is the end of this stage.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Get and compile kernel 2.2.18 or 2.4.x (including mknod agpgart
|
|
stuff)</title>
|
|
|
|
<para>
|
|
You can get either kernel from <ulink url="ftp://ftp.kernel.com"></ulink>. Of
|
|
course, read everything called README while you are at it. (In the README
|
|
literature that comes with the 2.4.x kernel, there is an important note about
|
|
where to unpack the source. Make sure you read it.) Put the kernel source file
|
|
in <filename class=directory>/usr/src/kernels</filename>, and
|
|
then run the following compile sequence, which I learned from a linuxnewbie
|
|
article (to which you should refer if my directions are not clear enough for
|
|
you, however it is specific to 2.2.x kernels). It can be found at the following address; <ulink
|
|
url="http://www.linuxnewbie.org/nfh/intel/compiling/kernel_update.html"></ulink>.
|
|
Of course, the location of the still-packed kernel is not really relevant, it
|
|
only matters that it is unpacked to an acceptable location. OK, now for the
|
|
commands:
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>tar -xzvf /usr/src/kernels/linux-2.4.x.tar.gz</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
or if you downloaded the better compressed bz2 version
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>bzcat /usr/src/kernels/linux-2.4.x.tar.bz2 | tar xv</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
and watch the screen spew out pages of information about what's happening.
|
|
When it is finished it will have created a new <filename
|
|
class=directory>linux</filename> folder.
|
|
</para>
|
|
|
|
<para>
|
|
OK, so, change to the new directory:
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>cd linux</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
and begin the compile process proper...
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>make config</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
<emphasis>Or preferably</emphasis>
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>make menuconfig</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
There's also <command>make xconfig</command>, but you haven't got X running,
|
|
or you wouldn't be reading this. So that won't work. And I'm embarrassed to
|
|
mention it in such an imperfect fashion but there is also something like
|
|
<command>make oldconfig</command> but I can't find any reference to it in my
|
|
books. In any case I am not addressing it here, though I am sure the procedure
|
|
for it is very similar to that which follows for <command>make
|
|
menuconfig</command>, should you be awkward and want to use it.
|
|
</para>
|
|
|
|
<para>
|
|
Now, I have gone through three text based kernel compiles (<command>make
|
|
config</command>) and know how long winded they are. I reommend <command>make
|
|
menuconfig</command> instead, which requires only that ncurses be loaded (you
|
|
don't need X) and you will be taken through the pretty face of kernel
|
|
recompilation. I loaded ncurses during a custom install of Red Hat 6.1, but I
|
|
forget exactly at which stage that option is available. Otherwise ncurses is,
|
|
I'm sure, on your distro's CD in rpm format, so if issuing <command>make
|
|
menuconfig</command> just produces errors, install ncurses and try
|
|
again.
|
|
</para>
|
|
|
|
<para>
|
|
The most relevant stages of the <command>make</command> process for solving
|
|
our particular problem are:
|
|
</para>
|
|
|
|
<itemizedlist mark=bullet>
|
|
<listitem>
|
|
<para>
|
|
to select EXPERIMENTAL early on (by hitting return while the very first option
|
|
is highlighted and then selecting the only suboption which is consequently
|
|
revealed),
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
towards the bottom of the base options, to enter "Character Devices" and
|
|
select (not as "M" but as "*") "/dev/agpgart (AGP) support" (only available if
|
|
the above instruction has been followed), and
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
select the appropriate sub-option of "/dev/agpgart (AGP) support" (again not
|
|
as a module "M" but as a static part of the kernel "*"), namely the "I810/I810
|
|
dc100I810e support" part.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note><title>Note</title>
|
|
<para>
|
|
The above explanation assumes you have run <command>make menuconfig</command>
|
|
and so a little thinkology will be required to map it to a situation where
|
|
<command>make</command> has been issued instead. But only a little.
|
|
</para>
|
|
</note>
|
|
|
|
<para>
|
|
(It has been pointed out to me that loading these features as modules would be
|
|
more logical, since they are not required until <command>startx</command> is
|
|
run. I have not tried the 'loadable module way' yet and will ammend this
|
|
section of the HOWTO after I have tested it. I recommend the static mode here
|
|
because I ran this procedure on a test version of the 2.4.x kernel and it was
|
|
suggested to me that loading statically was a safer and stabler way to go. Now
|
|
that 2.4.x is officially out there, perhaps modules will be more sensible.
|
|
I'll let you know how it goes. (Thanks to Heron Ordonez for this.))
|
|
</para>
|
|
|
|
<para>
|
|
When all is over and you feel calm enough, do this;
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><userinput>make dep</userinput></member>
|
|
<member><userinput>make clean</userinput> (not violently necessary but does no
|
|
harm)</member>
|
|
<member><userinput>make bzImage</userinput> (takes a while, this bit)</member>
|
|
<member><userinput>make modules</userinput></member>
|
|
<member><userinput>make modules_install</userinput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
Now have a look at the <filename class=directory>/boot</filename> directory.
|
|
You will probably see that <filename class=headerfile>System.map</filename> is
|
|
a symbolic link to <filename
|
|
class=headerfile>System.map-[your_kernel_version]</filename> and <filename
|
|
class=headerfile>vmlinuz</filename> is a symbolic link to <filename
|
|
class=headerfile>vmlinuz-[your_kernel_version]</filename>. This arrangement is
|
|
true for many distros, but not all. I think some store <filename
|
|
class=headerfile>vmlinuz</filename> in <filename class=directory>/</filename>,
|
|
while <filename class=headerfile>System.map</filename> resides in <filename
|
|
class=directory>/boot</filename>. Whatever the case is, use your brain and
|
|
apply these instructions accordingly. So, basically you need to remove the
|
|
symbolic links like so:
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><userinput>rm System.map</userinput></member>
|
|
<member><userinput>rm vmlinuz</userinput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
Then new symbolic links need to be created to the
|
|
about-to-be-copied-over-while-simultaneously-being-renamed, recently created
|
|
files. It goes like this (assuming you have an i386 computer):
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><userinput>cp /usr/src/kernels/linux/arch/i386/boot/bzImage
|
|
/boot/vmlinuz-2.4.x</userinput></member>
|
|
<member><userinput>ln -s /boot/vmlinuz-2.4.x
|
|
/boot/vmlinuz</userinput></member>
|
|
<member><userinput>cp /usr/src/kernels/linux/System.map
|
|
/boot/System.map-2.4.x</userinput></member>
|
|
<member><userinput>ln -s /boot/System.map-2.4.x
|
|
/boot/System.map</userinput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<tip>
|
|
<para>
|
|
You don't need to use absolute pathnames if you are in <filename
|
|
class=directory>/boot</filename>. But if you are the excessively cautious type
|
|
and do use absolute pathnames, you just have longer names for your symbolic
|
|
files. In fact the whole symbolic link thing here is only necessary if
|
|
you want to play it that way. Essentially, minimalistically, you can have
|
|
one kernel called <filename class=headerfile>vmlinuz</filename>
|
|
and name all the others by their version number (or just trash them!), and swap
|
|
all the names around when you want to boot another kernel. Or give each kernel a unique
|
|
name, and have one entry per kernel in <filename class=headerfile>/etc/lilo.conf</filename>.
|
|
It's up to you.
|
|
</para>
|
|
</tip>
|
|
|
|
<para>
|
|
Now you need to edit <filename class=headerfile>/etc/lilo.conf</filename>.
|
|
This is achieved thusly:
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><computeroutput>image=/boot/vmlinuz</computeroutput></member>
|
|
<member><computeroutput>label=[what-ever-you-want-that-is-relevant-easy-to-type-and-remember]</computeroutput></member>
|
|
<member><computeroutput>read-only</computeroutput></member>
|
|
<member><computeroutput>root=/dev/hda[n]</computeroutput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
After editing <filename class=headerfile>lilo.conf</filename> you must do this:
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>/sbin/lilo</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
so that the crisp, shiny, new linux kernel be made known to lilo, otherwise (I
|
|
have experienced this) the new kernel will not be available for booting. Which
|
|
would be silly. So after all this take a deep breath and reboot, select your
|
|
new kernel and with fingers crossed, watch. It should work. If it does, go and
|
|
celebrate a little. But don't let it get to your head because you have yet to
|
|
mknod the agpgart module, a simple yet essential procedure done thusly:
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><userinput>cd /dev</userinput></member>
|
|
<member><userinput>mknod agpgart c 10 175</userinput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
which basically creates the very essential character device (X won't run
|
|
without it) driver which acts kinda like a 'go-between' for the i810 chipset
|
|
and the X server. (Thanks to Heron Ordonez for saving me some embarrassment
|
|
here.) Pretty scientic stuff. Sorry about that.
|
|
</para>
|
|
|
|
<para>
|
|
That was the end of this stage.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Nimbly tweak XF86Config</title>
|
|
|
|
<para>
|
|
I've done a lot of this and it get's mighty tedious when it fails 23 times in
|
|
a row I CAN TELL YOU, so pay attention and read very closely the man page (run
|
|
<userinput>man XF86Config</userinput> at the command prompt). First of all I
|
|
recommend running the in-no-way-user-friendly <command>xf86config</command>
|
|
(<emphasis>observe case!</emphasis>) to genertate a base <filename
|
|
class=headerfile>XF86Config</filename> file as the other tools seem to produce
|
|
<filename class=headerfile>XF86Config</filename> files which are in my
|
|
experience incompatible with X4.x. When you run through the questions
|
|
<command>xf86config</command> asks and you reach the card section, there will
|
|
be nothing for you to choose, so choose that very nothing. You'll be entering
|
|
the right stuff later, after the base file has been created. Then, after
|
|
answering all the questions as well as you can, save the file as <filename
|
|
class=headerfile>/etc/X11/XF86Config</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
So, finally, the all important addition is:
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><computeroutput>Section "Device"</computeroutput></member>
|
|
<member><computeroutput> Identifier "i810"</computeroutput></member>
|
|
<member><computeroutput> Driver "i810"</computeroutput></member>
|
|
<member><computeroutput> VideoRam "4096"</computeroutput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
and it should be inserted in the Graphics Device Section. There should in any
|
|
case be an existing "Device" section which you could edit if you prefer. From
|
|
thereon you should, having defined the i810 for X, enter "i810" wherever you
|
|
see a "Device" field. I am including a couple of sections from my <filename
|
|
class=headerfile>XF86Config</filename> file as an example, and hopefully to
|
|
make a little clearer what I mean:
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><computeroutput>Section "Device"</computeroutput></member>
|
|
<member><computeroutput> Identifier "i810"</computeroutput></member>
|
|
<member><computeroutput> Driver "i810"</computeroutput></member>
|
|
<member><computeroutput> VideoRam "4096"</computeroutput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
<simplelist type=vert columns=1>
|
|
<member><computeroutput>Section "Screen"</computeroutput></member>
|
|
<member><computeroutput> Identifier "Screen 1"</computeroutput></member>
|
|
<member><computeroutput> Device "i810"</computeroutput></member>
|
|
<member><computeroutput> Monitor "Highscreen
|
|
17inch"</computeroutput></member>
|
|
<member><computeroutput> DefaultColorDepth 24</computeroutput></member>
|
|
<member><computeroutput> SubSection "Display"</computeroutput></member>
|
|
<member><computeroutput> Depth 8</computeroutput></member>
|
|
<member><computeroutput> Modes "1024x768"</computeroutput></member>
|
|
<member><computeroutput> EndSubSection</computeroutput></member>
|
|
<member><computeroutput> SubSection "Display"</computeroutput></member>
|
|
<member><computeroutput> Depth 15</computeroutput></member>
|
|
<member><computeroutput> Modes "1024x768"</computeroutput></member>
|
|
<member><computeroutput> EndSubSection</computeroutput></member>
|
|
<member><computeroutput> SubSection "Display"</computeroutput></member>
|
|
<member><computeroutput> Depth 16</computeroutput></member>
|
|
<member><computeroutput> Modes "1024x768"</computeroutput></member>
|
|
<member><computeroutput> EndSubSection</computeroutput></member>
|
|
<member><computeroutput> SubSection "Display"</computeroutput></member>
|
|
<member><computeroutput> Depth 24</computeroutput></member>
|
|
<member><computeroutput> Modes "1024x768"</computeroutput></member>
|
|
<member><computeroutput> EndSubSection</computeroutput></member>
|
|
<member><computeroutput> SubSection "Display"</computeroutput></member>
|
|
<member><computeroutput> Depth 32</computeroutput></member>
|
|
<member><computeroutput> Modes "1024x768"</computeroutput></member>
|
|
<member><computeroutput> EndSubSection</computeroutput></member>
|
|
<member><computeroutput>EndSection</computeroutput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<warning>
|
|
<para>
|
|
As you can see I have only given X the option of "1024x768", and have a
|
|
default colour depth of 24 bits, because I like it that way, and the i810 can
|
|
easily cope with that resolution and depth on my 17" monitor. How that would
|
|
work on a 21" I do not know. Experimentation will teach you.
|
|
</para>
|
|
</warning>
|
|
|
|
<para>
|
|
I am going to be boring and say it again, but a more complete understanding
|
|
than I can give here of the mysteries of the <filename
|
|
class=headerfile>XF86Config</filename> file can be achieved by closely reading
|
|
the man page (see above). This is really important if you want to have a
|
|
chance of solving any problems that are bound to come up now and again, that
|
|
have not been covered here.
|
|
</para>
|
|
|
|
<para>
|
|
That should do it. Now save <filename class=headerfile>XF86Config</filename>
|
|
and run:
|
|
</para>
|
|
|
|
<para>
|
|
<userinput>startx</userinput>
|
|
</para>
|
|
|
|
<para>
|
|
It should work. It did for me. You will be happy. If not contact me at
|
|
<email>trussl@hotmail.com</email> and I will endeavour to help you.
|
|
</para>
|
|
|
|
<note><title>Note</title>
|
|
<para>
|
|
This is a kind of a p.s. to this section but may be helpful. I had a wee
|
|
problem when going through the XF86Config part of this HOWTO during a test
|
|
run. It stemmed from having read but not fully understood some blurb about the
|
|
i810 and X4.x not working at all resolutions with a buffer extension (or
|
|
something like that). Anyway, I made no notes about this and cannot therefore
|
|
remember exactly what I read. Because I remember this vaguely I can only say
|
|
the following with certainty; you need the following stanza at the beginning
|
|
of your <filename class=headerfile>XF86Config</filename> file:
|
|
|
|
<simplelist type=vert columns=1>
|
|
<member><computeroutput># This loads the DBE extension
|
|
module</computeroutput></member>
|
|
<member><computeroutput> Load "dbe" # Double buffer
|
|
extension</computeroutput></member>
|
|
<member><computeroutput># This loads the miscellaneous extensions module, and
|
|
disables </computeroutput></member>
|
|
<member><computeroutput># initialisation of the XFree86-DGA extension within
|
|
that module.</computeroutput></member>
|
|
<member><computeroutput> SubSection "extmod"</computeroutput></member>
|
|
<member><computeroutput> Option "omit xfree86-dga" # don't initialise the
|
|
DGA extension</computeroutput></member>
|
|
<member><computeroutput> EndSubSection</computeroutput></member>
|
|
</simplelist>
|
|
</para>
|
|
|
|
<para>
|
|
So if X reports errors about a "shape extender" or "shape extension", you may
|
|
well find that your <filename class=headerfile>XF86Config</filename> file is
|
|
missing the above listed stanza.
|
|
</para>
|
|
</note>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1>
|
|
<title>Thank you</title>
|
|
|
|
<para>
|
|
I must point out that I would not have known how to fix the i810 and X4.x
|
|
problem if it were not for the pioneering efforts of Val Henson who guided me
|
|
through the process and recommended the 2.4.x kernel in the first place. And
|
|
now that this is an ammended version, I would also like to thank Heron Ordonez
|
|
for pointing out a few problems which I have in part addressed, and will fully
|
|
address in due course. Curtis Stone pointed out to me that the features I
|
|
thought only available in the 2.4.x kernel were present in 2.2.18. Thanks to
|
|
him too. I am now also endebted to Cameron Kerr for pointing out that the 2.4.x
|
|
kernel must not be unpacked in /usr/src/linux. I had no success with the
|
|
2.4.x until this was pointed out to me, but would have been OK had I read the
|
|
accompanying README, ie followed my own instructions.
|
|
</para>
|
|
|
|
<para>
|
|
If this process carries on in this fashion the 'Thank you' will one
|
|
day be the largest section of this HOWTO. This is an open process and all
|
|
comments (politely phrased of course!) are welcome.
|
|
</para>
|
|
</sect1>
|
|
|
|
</Article>
|
|
|
|
|