mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
81e62a36ec
commit
98f3bfdf58
|
@ -930,7 +930,7 @@ How to fix ugly and unreadable X Window fonts. </Para>
|
|||
i810-HOWTO</ULink>,
|
||||
<CiteTitle>i810 with XFree86 4.x HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: January 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: May 2001</CiteTitle>.
|
||||
Describes getting XFree86 4.x running on Intel's
|
||||
i810 graphics chipset by using special features of the 2.4.0
|
||||
kernel. </Para>
|
||||
|
|
|
@ -870,7 +870,7 @@ with Linux and some free software. </Para>
|
|||
i810-HOWTO</ULink>,
|
||||
<CiteTitle>i810 with XFree86 4.x HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: January 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: May 2001</CiteTitle>.
|
||||
Describes getting XFree86 4.x running on Intel's
|
||||
i810 graphics chipset by using special features of the 2.4.0
|
||||
kernel. </Para>
|
||||
|
|
|
@ -343,7 +343,7 @@ Also includes how to set up multi-headed displays. </Para>
|
|||
i810-HOWTO</ULink>,
|
||||
<CiteTitle>i810 with XFree86 4.x HOWTO</CiteTitle>
|
||||
</Para><Para>
|
||||
<CiteTitle>Updated: January 2001</CiteTitle>.
|
||||
<CiteTitle>Updated: May 2001</CiteTitle>.
|
||||
Describes getting XFree86 4.x running on Intel's
|
||||
i810 graphics chipset by using special features of the 2.4.0
|
||||
kernel. </Para>
|
||||
|
|
|
@ -8,11 +8,12 @@
|
|||
<author>
|
||||
<firstname>Toby</firstname><surname>Russell</surname>
|
||||
</author>
|
||||
<pubdate>v0.55, January 2001</pubdate>
|
||||
<pubdate>v1.00, May 2001</pubdate>
|
||||
|
||||
<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.0 kernels.
|
||||
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>
|
||||
|
@ -21,15 +22,38 @@ This HOWTO describes getting XFree86 4.x running on Intel's i810 graphics chipse
|
|||
<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.0 kernels, and consequently this HOWTO tackles that solution, or procedure, alone. The instructions that follow were written to the 2.2.18 compile tune, but the procedure is similar enough to be translatable to the 2.4.0 (if you feel safe with this beast (see below)). Use your head, as Tony Buzan would say.
|
||||
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.2.18 compile tune, but the
|
||||
procedure is similar enough to be translatable to the 2.4.x. Use your head, as
|
||||
Tony Buzan would say.
|
||||
</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 uses also 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.
|
||||
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; I feel 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.
|
||||
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>
|
||||
|
||||
|
@ -41,7 +65,9 @@ Finally, no introduction would be complete without the following words of cautio
|
|||
</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;
|
||||
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>
|
||||
|
@ -55,7 +81,7 @@ get and install X4.x
|
|||
|
||||
<listitem>
|
||||
<para>
|
||||
get and compile kernel 2.2.18 or 2.4.0 (including mknod agpgart stuff)
|
||||
get and compile kernel 2.2.18 or 2.4.x (including mknod agpgart stuff)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
@ -72,22 +98,36 @@ nimbly tweak XF86Config
|
|||
<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>
|
||||
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>):
|
||||
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>
|
||||
<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.
|
||||
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):
|
||||
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>
|
||||
|
@ -105,14 +145,21 @@ For a basic installation and to save time downloading one needs only the followi
|
|||
</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):
|
||||
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>
|
||||
<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.
|
||||
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>
|
||||
|
@ -121,61 +168,40 @@ That is the end of this stage.
|
|||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Get and compile kernel 2.2.18 or 2.4.0 (including mknod agpgart stuff)</title>
|
||||
<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. When I first fixed this i810 problem I used a test kernel (2.4.0-test1) which worked fine for me. Since the official 2.4.0 has come out I have tried to compile it on both Red Hat and Debian, but without success. At the moment my suspiscion is that there are errors in the Makefile (any help with this would be greatly appreciated!) which seem to be producing a bad bzImage. Anyway, at reboot the new kernel hangs before it even gets going. For this reason I suggest you use either 2.2.18, or if you are the daring kind, 2.4.0-test1. I know both of them work. If you have had no problems with the 2.4.0 kernel proper, please let me know.
|
||||
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>
|
||||
For each of the kernel updates/compiles I have done, I have always chucked the kernel source file in my home directory, then run the following sequence, which I learned from a linuxnewbie article (to which you should refer if my directions are not clear enough for you). 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 in a conventional place. I personally use my home directory for no stronger reason than it seems neat and is easy to remember. OK, now for the commands:
|
||||
|
||||
<simplelist type=vert columns=1>
|
||||
<member><userinput>cd /usr/src</userinput></member>
|
||||
<member><userinput>ls -l</userinput></member>
|
||||
</simplelist>
|
||||
<userinput>tar -xzvf /usr/src/kernels/linux-2.4.x.tar.gz</userinput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Revealed should be, amongst other things, a symbolic link from <filename class=symlink>linux</filename> to your existing kernel sources directory. Remove it as follows:
|
||||
or if you downloaded the better compressed bz2 version
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<userinput>rm linux</userinput>
|
||||
</para>
|
||||
|
||||
<tip>
|
||||
<para>
|
||||
If there is no symbolic link named <filename class=symlink>linux</filename> it's no big deal; not all distributions follow this method. In that case there may or may not be a folder named after the kernel running on your system (this depends on whether the kernel sources were included during installation), in which case there is no need to remove any symbolic link!
|
||||
</para>
|
||||
</tip>
|
||||
|
||||
<para>
|
||||
Then open the sources file
|
||||
<userinput>bzcat /usr/src/kernels/linux-2.4.x.tar.bz2 | tar xv</userinput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<userinput>tar -xzvf /home/[whatever]/linux-2.2.18.tar.gz</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=headerfile>linux</filename> folder. Rename it as follows:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<userinput>mv linux linux-2.2.18</userinput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
then create a new symbolic link as follows:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<userinput>ln -s linux-2.2.18 linux</userinput>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
This is a more important stage than it appears. Some scripts refer to <filename class=directory>/usr/src/linux</filename> and if they do not find it they will not run. And it is useful to name the kernel source folders themselves by their release number for two reasons. First for clarity and second because if you are compiling various kernels you will probably want to keep the ones you know are stable for safety reasons. If you are <emphasis>sure</emphasis> you will only need the 2.2.18 kernel, then you need only store the one source folder and call it simply <filename class=directory>/usr/src/linux</filename>, in which case, all the stuff I have included here is of no relevence to you. Again, I invite the reader to use his/her imagination.
|
||||
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>
|
||||
|
@ -203,53 +229,84 @@ and begin the compile process proper...
|
|||
</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>.
|
||||
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 the ncurses rpm and try again.
|
||||
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:
|
||||
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),
|
||||
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
|
||||
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.
|
||||
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>
|
||||
|
||||
<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.0 kernel and it was suggested to me that loading statically was a safer and stabler way to go. Now that 2.4.0 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>
|
||||
|
||||
<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.
|
||||
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 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>
|
||||
|
@ -257,7 +314,18 @@ When all is over and you feel calm enough, do this;
|
|||
</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:
|
||||
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>
|
||||
|
@ -266,27 +334,43 @@ Now have a look at the <filename class=directory>/boot</filename> directory. You
|
|||
</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):
|
||||
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/linux/arch/i386/boot/bzImage /boot/vmlinuz-2.2.18</userinput></member>
|
||||
<member><userinput>ln -s /boot/vmlinuz-2.2.18 /boot/vmlinuz</userinput></member>
|
||||
<member><userinput>cp /usr/src/linux/System.map /boot/System.map-2.2.18</userinput></member>
|
||||
<member><userinput>ln -s /boot/System.map-2.2.18 /boot/System.map</userinput></member>
|
||||
<member><userinput>cp /usr/src/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/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 within <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.
|
||||
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 tell <command>lilo</command> about all your masterly work. This is achieved thusly. First edit your <filename class=headerfile>/etc/lilo.conf</filename> file as follows, by adding the following type of thing somewhere after the first (generic) stanza:
|
||||
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-2.2.18</computeroutput></member>
|
||||
<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>
|
||||
|
@ -302,7 +386,12 @@ After editing <filename class=headerfile>lilo.conf</filename> you must do this:
|
|||
</para>
|
||||
|
||||
<para>
|
||||
so that the crisp, shiny, new linux kernel is known by 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:
|
||||
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>
|
||||
|
@ -311,11 +400,14 @@ so that the crisp, shiny, new linux kernel is known by lilo, otherwise (I have e
|
|||
</para>
|
||||
|
||||
<para>
|
||||
which basically creates the very essential (X won't run without it) driver (character special file) which acts kinda like a 'go-between' for the i810 and the X server. (Thanks to Heron Ordonez for saving me some embarrassment here.) Pretty scientic stuff there. Sorry about that.
|
||||
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 is the end of this stage.
|
||||
That was the end of this stage.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
|
@ -323,7 +415,19 @@ That is the end of this stage.
|
|||
<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>.
|
||||
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>
|
||||
|
@ -338,7 +442,12 @@ I've done a lot of this and it get's mighty tedious when it fails 23 times in a
|
|||
</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:
|
||||
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>
|
||||
|
@ -353,7 +462,8 @@ and it should be inserted in the Graphics Device Section. There should in any ca
|
|||
<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> Monitor "Highscreen
|
||||
17inch"</computeroutput></member>
|
||||
<member><computeroutput> DefaultColorDepth 24</computeroutput></member>
|
||||
<member><computeroutput> SubSection "Display"</computeroutput></member>
|
||||
<member><computeroutput> Depth 8</computeroutput></member>
|
||||
|
@ -381,16 +491,25 @@ and it should be inserted in the Graphics Device Section. There should in any ca
|
|||
|
||||
<warning>
|
||||
<para>
|
||||
As you can see I have only given X the option of "1024x768", and have a default colour depth of 24 bits, which you should only use <emphasis>if you know your monitor can handle it</emphasis>. Consult the accompanying monitor literature or the monitor manufacturer if you are unsure. If you can not put your hands on any clear information use a default colour depth of 8. Probably you can't do any damage at that setting. As for the resolution, use whatever you prefer and you should be ready to rock.
|
||||
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.
|
||||
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:
|
||||
That should do it. Now save <filename class=headerfile>XF86Config</filename>
|
||||
and run:
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -398,26 +517,41 @@ That should do it. Now save <filename class=headerfile>XF86Config</filename> and
|
|||
</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.
|
||||
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:
|
||||
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># 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> 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.
|
||||
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>
|
||||
|
||||
|
@ -429,8 +563,26 @@ So if X reports errors about a "shape extender" or "shape extension", you may we
|
|||
<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.0 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.0 kernel were present in 2.2.18. Thanks to him too. 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.
|
||||
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 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>
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue