mirror of https://github.com/tLDP/LDP
2779 lines
90 KiB
XML
2779 lines
90 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
|
"http://docbook.org/xml/4.4/docbookx.dtd">
|
|
<!--
|
|
Framebuffer HOWTO document
|
|
|
|
Alex Buell <alex.buell@munted.org.uk>
|
|
-->
|
|
<article id="Framebuffer-HOWTO">
|
|
<articleinfo>
|
|
<title>Framebuffer HOWTO</title>
|
|
<author>
|
|
<firstname>Alex</firstname>
|
|
<surname>Buell</surname>
|
|
<affiliation><address><email>alex.buell@munted.org.uk</email></address></affiliation>
|
|
</author>
|
|
|
|
<pubdate>2010-08-05, version 1.3</pubdate>
|
|
|
|
<abstract><title></title>
|
|
<para>This document describes how to use the
|
|
framebuffer devices in Linux with a variety of
|
|
platforms. This also includes how to set up
|
|
multi-headed displays.</para> </abstract>
|
|
|
|
<revhistory id="revhistory">
|
|
<revision>
|
|
<revnumber>v1.3</revnumber>
|
|
<date>2010-08-05</date>
|
|
<revremark>Converted to DocBook from
|
|
LinuxDoc</revremark> </revision>
|
|
<revision>
|
|
<revnumber>v1.2</revnumber>
|
|
<date>2000-01-22</date>
|
|
<revremark>Last public release</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>v1.1</revnumber>
|
|
<date>1999-07-22</date>
|
|
<revremark>With some additional information</revremark>
|
|
</revision>
|
|
<revision>
|
|
<revnumber>v1.0</revnumber>
|
|
<date>1999-06-07</date>
|
|
<revremark>First public release</revremark>
|
|
</revision>
|
|
</revhistory>
|
|
</articleinfo>
|
|
|
|
<para>Copyright © 1999—2010 Alex Buell, GNU Free Documentation Licence (GFPL)</para>
|
|
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
|
document under the terms of the GNU Free Documentation License,
|
|
Version 1.2 or any later version published by the Free Software
|
|
Foundation. A copy of the licence can be retrieved from <ulink
|
|
url="http://www.gnu.org/copyleft">the Free Software
|
|
Foundation.</ulink></para>
|
|
|
|
<section>
|
|
<title>Contributors</title>
|
|
<para>Thanks go to those people listed below who helped improve the Framebuffer HOWTO. I've taken the
|
|
liberty of removing e-mail addresses as this document is more than ten years old!</para>
|
|
<itemizedlist>
|
|
<listitem><para>Jeff Noxon</para></listitem>
|
|
<listitem><para>Francis Devereux</para></listitem>
|
|
<listitem><para>Andreas Ehliar</para></listitem>
|
|
<listitem><para>Martin McCarthy</para></listitem>
|
|
<listitem><para>Simon Kenyon</para></listitem>
|
|
<listitem><para>David Ford</para></listitem>
|
|
<listitem><para>Chris Black</para></listitem>
|
|
<listitem><para>N. Becker</para></listitem>
|
|
<listitem><para>Bob Tracy</para></listitem>
|
|
<listitem><para>Marius Hjelle</para></listitem>
|
|
<listitem><para>James Cassidy</para></listitem>
|
|
<listitem><para>Andreas U. Trottmann</para></listitem>
|
|
<listitem><para>Lech Szychowski</para></listitem>
|
|
<listitem><para>Aaron Tiensivu</para></listitem>
|
|
<listitem><para>Jan-Frode Myklebust for his info on permedia cards</para></listitem>
|
|
<listitem><para>Many others too numerous to add, but thanks!</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Thanks go to Rick Niles who has very kindly handed over
|
|
his Multi-Head Mini-HOWTO for inclusion in this HOWTO.</para>
|
|
|
|
<para>Thanks to these people listed below who built libc5/glibc2 versions of the
|
|
XF86_FBdev X11 framebuffer driver for X11 on x86 platforms:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Brion Vibber</para></listitem>
|
|
<listitem><para>Gerd Knorr</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>And, of course, the authors of the framebuffer device drivers:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Martin Schaller - original author of the framebuffer driver concept</para></listitem>
|
|
<listitem><para>Roman Hodek</para></listitem>
|
|
<listitem><para>Andreas Schwab</para></listitem>
|
|
<listitem><para>Günther Kelleter</para></listitem>
|
|
<listitem><para>Geert Uytterhoeven</para></listitem>
|
|
<listitem><para>Roman Zippel</para></listitem>
|
|
<listitem><para>Pavel Machek</para></listitem>
|
|
<listitem><para>Gerd Knorr</para></listitem>
|
|
<listitem><para>Miguel de Icaza</para></listitem>
|
|
<listitem><para>David Carter</para></listitem>
|
|
<listitem><para>William Ricklidge</para></listitem>
|
|
<listitem><para>Jes Sorensen</para></listitem>
|
|
<listitem><para>Sigurdur Asgeirsson</para></listitem>
|
|
<listitem><para>Jeffrey Kuskin</para></listitem>
|
|
<listitem><para>Michal Rehacek</para></listitem>
|
|
<listitem><para>Peter Zaitcev</para></listitem>
|
|
<listitem><para>David S. Miller</para></listitem>
|
|
<listitem><para>Dave Redman</para></listitem>
|
|
<listitem><para>Jay Estabrook</para></listitem>
|
|
<listitem><para>Martin Mares</para></listitem>
|
|
<listitem><para>Dan Jacobowitz</para></listitem>
|
|
<listitem><para>Emmnauel Marty</para></listitem>
|
|
<listitem><para>Eddie C. Dost</para></listitem>
|
|
<listitem><para>Jakub Jelinek</para></listitem>
|
|
<listitem><para>Philip Blundell</para></listitem>
|
|
<listitem><para>Anyone else, stand up and be counted!</para></listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section>
|
|
<title>What is a framebuffer device?</title>
|
|
<para>A framebuffer device is an abstraction for the graphic
|
|
hardware. It represents the frame buffer of some video
|
|
hardware, and allows application software to access the
|
|
graphic hardware through a well-defined interface, so
|
|
that the software doesn't need to know anything about
|
|
the low-level interface stuff [Taken from Geert
|
|
Uytterhoeven's framebuffer.txt in the linux kernel
|
|
sources]</para>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>What advantages does framebuffer devices have?</title>
|
|
<para>Penguin logo! :o) Seriously, the major advantage of the
|
|
framebuffer devices is that it presents a generic
|
|
interface across all platforms. It was the case until
|
|
late in the 2.1.x kernel development process that the
|
|
x86 platform had console drivers completely different
|
|
from the other console drivers for other platforms.
|
|
With the introduction of the 2.1.109 kernel, all this
|
|
has changed for the better, and introduced more uniform
|
|
handling of the console under the x86 platforms and
|
|
also introduced true bitmapped graphical consoles
|
|
bearing the Penguin logo on x86 for the first time, and
|
|
allowed code to be shared across different platforms.
|
|
Note that 2.0.x kernels do not support framebuffer
|
|
devices, but it is possible someday someone will
|
|
backport the code from the 2.1.x kernels to 2.0.x
|
|
kernels. There is an exception to that rule in that
|
|
the 0.9.x kernel port for m68k platforms does have the
|
|
framebuffer device support included.</para>
|
|
<para><emphasis>With the release of the 2.2.x kernels,
|
|
framebuffer device support is very solid and
|
|
stable. You should use the framebuffer device
|
|
if your graphic card supports it, if you are
|
|
using 2.2.x kernels. Older 2.0.x kernels does
|
|
not support framebuffer devices, at least on
|
|
the x86 platform.</emphasis></para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>0.9.x - introduced m68k framebuffer
|
|
devices. Note that m68k 0.9.x is
|
|
functionally equivalent to x86 1.0.9
|
|
(plus 1.2.x
|
|
enhancements)</para></listitem>
|
|
<listitem><para>2.1.107 - introduced x86
|
|
framebuffer/new console devices and
|
|
added generic support, without
|
|
scrollback buffer
|
|
support.</para></listitem>
|
|
<listitem><para>2.1.113 - scrollback buffer support
|
|
added to vgacon.</para></listitem>
|
|
<listitem><para>2.1.116 - scrollback buffer support
|
|
added to vesafb.</para></listitem>
|
|
<listitem><para>2.2.x - includes matroxfb (Matrox
|
|
cards) and atyfb (ATI
|
|
cards).</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>There are some cool features of the framebuffer devices,
|
|
in that you can give generic options to the kernel at
|
|
bootup-time, including options specific to a particular
|
|
framebuffer device. These are:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>video=xxx:off</code> - disable
|
|
probing for a particular framebuffer
|
|
device</para></listitem>
|
|
<listitem><para><code>video=map:octal-number</code> -
|
|
maps the virtual consoles (VCs) to
|
|
framebuffer (FB)
|
|
devices</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>video=map:01</code> will
|
|
map VC0 to FB0, VC1 to FB1, VC2
|
|
to FB0, VC3 to
|
|
FB1...</para></listitem>
|
|
<listitem><para><code>video=map:0132</code>
|
|
will map VC0 to FB0, VC1 to
|
|
FB1, VC2 to FB3, VC4 to FB2,
|
|
VC5 to FB0...</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Normally framebuffer devices are probed for in the order
|
|
specified in the kernel, but by specifying the
|
|
<code>video=xxx</code> option, you can add the specific
|
|
framebuffer device you want probed before the others
|
|
specified in the kernel.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on x86 platforms</title>
|
|
<section><title>What is vesafb?</title>
|
|
|
|
<para>Vesafb is a framebuffer driver for x86
|
|
architecture that works with VESA 2.0 compliant
|
|
graphic cards. It is closely related to the
|
|
framebuffer device drivers in the
|
|
kernel.</para>
|
|
|
|
<para>vesafb is a display driver that enables the use
|
|
of graphical modes on your x86 platform for
|
|
bitmapped text consoles. It can also display a
|
|
logo, which is probably the main reason why
|
|
you'd want to use vesafb :o)</para>
|
|
|
|
<para>Unfortunately, you can not use vesafb
|
|
successfully with VESA 1.2 cards. This is
|
|
because these 1.2 cards do not use
|
|
<emphasis>linear</emphasis> frame buffering.
|
|
Linear frame buffering simply means that the
|
|
system's CPU is able to access every bit of the
|
|
display. Historically, older graphic adapters
|
|
could allow the CPU to access only 64K at a
|
|
time, hence the limitations of the dreadful
|
|
CGA/EGA graphic modes! It may be that someone
|
|
will write a vesafb12 device driver for these
|
|
cards, but this will use up precious kernel
|
|
memory and involve a nasty hack.</para>
|
|
|
|
<para>There is however a potential workaround to add
|
|
VESA 2.0 extensions for your legacy VESA 1.2
|
|
card. You may be able to download a TSR type
|
|
program that will run from DOS, and used with
|
|
loadlin, can help configure the card for the
|
|
appropriate graphic console modes. Note that
|
|
this will not always work, as an example some
|
|
Cirrus Logic cards such as the VLB 54xx series
|
|
are mapped to a range of memory addresses (for
|
|
example, within the 15MB-16MB range) for frame
|
|
buffering which preludes these from being used
|
|
successfully with systems that have more than
|
|
32MB of memory. There is a way to make this
|
|
work, i.e. if you have a BIOS option to leave a
|
|
memory hole at 15MB-16MB range, it might work,
|
|
Linux doesn't support the use of memory holes.
|
|
However there are patches for this option
|
|
though [Who has these and where do one gets
|
|
them from?]. If you wish to experiment with
|
|
this option, there are plenty of TSR style
|
|
programs available, a prime example is UNIVBE,
|
|
which can be found on the Internet.</para>
|
|
|
|
<para>Alternatively, you may be able to download kernel
|
|
patches to allow your VESA 1.2 card to work
|
|
with the VESA framebuffer driver. For example,
|
|
there are patches for use with older S3 boards
|
|
(such as S3 Trio, S3 Virge) that supports VESA
|
|
1.2. For these cards, you can pick up patches
|
|
from <ulink
|
|
url="ftp://ccssu.crimea.ua/pub/linux/kernel/v2.2/unofficial/s3new.diff.gz"></ulink>.
|
|
</para>
|
|
</section>
|
|
|
|
<section><title>How do I activate the vesafb drivers?</title>
|
|
<para>Assuming you are using menuconfig, you will need
|
|
to do the following steps:</para>
|
|
|
|
<para>If your processor (on x86 platforms) supports
|
|
MTRRs, enable this. It speeds up memory copies
|
|
between the processor and the graphic card, but
|
|
not strictly necessary. You can of course, do
|
|
this after you have the console device
|
|
working.</para>
|
|
|
|
<para><emphasis>IMPORTANT: For 2.1.x kernels, go into
|
|
the Code Maturity Level menu, and
|
|
enable the prompt for development
|
|
and / or incomplete drivers. This is
|
|
no longer necessary for the 2.2.x
|
|
kernels.</emphasis></para>
|
|
|
|
<para>Go into the Console Drivers menu, and enable the
|
|
following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>VGA Text Console</para></listitem>
|
|
<listitem><para>Video Selection
|
|
Support</para></listitem>
|
|
<listitem><para>Support for frame buffer
|
|
devices
|
|
(experimental)</para></listitem>
|
|
<listitem><para>VESA VGA Graphic
|
|
console</para></listitem>
|
|
<listitem><para>Advanced Low Level
|
|
Drivers</para></listitem>
|
|
<listitem><para>Select Mono, 2bpp, 4bpp, 8bpp,
|
|
16bpp, 24bpp and 32bpp packed
|
|
pixel drivers</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>VGA Chipset Support (text only) -
|
|
<code>vgafb</code> - used to be part of the
|
|
list above, but it has been removed as it is
|
|
now deprecated and no longer supported. It will
|
|
be removed shortly. Use VGA Text Console
|
|
(<code>fbcon</code>) instead. VGA
|
|
Character/Attributes is only used with VGA
|
|
Chipset Support, and doesn't need to be
|
|
selected.</para>
|
|
|
|
<para>Ensure that the Mac variable bpp packed pixel
|
|
support is not enabled. Linux kernel release
|
|
2.1.111 (and 112) seemed to enable this
|
|
automatically if Advanced Low Level Drivers was
|
|
selected for the first time. This no longer
|
|
happens with 2.1.113.</para>
|
|
|
|
<para>There is also the option to compile in fonts into
|
|
memory, but this isn't really necessary, and
|
|
you can always use <code>kbd-0.99</code>'s (see
|
|
section on fonts) setfont utility to change
|
|
fonts by loading fonts into the console
|
|
device.</para>
|
|
|
|
<para>Make sure these aren't going to be modules. [Not
|
|
sure if it's possible to build them as modules
|
|
yet - please correct me on this]</para>
|
|
|
|
<para>You'll need to create the framebuffer device in
|
|
<code>/dev</code>. You need one per framebuffer
|
|
device, so all you need to do is to type in
|
|
<code>mknod /dev/fb0 c 29 0</code> for the
|
|
first one. Subsequent ones would be in
|
|
multiples of 32, so for example to create
|
|
<code>/dev/fb1</code>, you would need to type
|
|
in <code>mknod /dev/fb1 c 29 32</code>, and so
|
|
on up to the eighth framebuffer device
|
|
(<code>mknod /dev/fb7 c 29 224</code>)</para>
|
|
|
|
<para>Then rebuild the kernel, modify
|
|
<code>/etc/lilo.conf</code> to include the
|
|
<code>VGA=ASK</code> parameter, and run
|
|
<code>lilo</code>, this is required in order
|
|
for you to be able to select the modes you wish
|
|
to use.</para>
|
|
|
|
<para>Here's a sample LILO configuration (taken from my
|
|
machine)</para>
|
|
|
|
<para><literallayout><code>
|
|
# LILO configuration file
|
|
boot = /dev/hda3
|
|
delay = 30
|
|
prompt
|
|
vga = ASK # Let user enter the desired modes
|
|
image = /vmlinuz
|
|
root = /dev/hda3
|
|
label = Linux
|
|
read-only # Non-UMSDOS filesystems should be mounted read-only for checking
|
|
</code></literallayout></para>
|
|
|
|
<para>Reboot the kernel, and as a simple test, try
|
|
entering <code>0301</code> at the VGA prompt
|
|
(this will give you 640x480 @ 256), and you
|
|
should be able to see a cute little Penguin
|
|
logo.</para>
|
|
|
|
<para>Note, that at the VGA prompt, you're required to
|
|
type in the number in the format of "0" plus
|
|
the three-digit number, and miss out the 'x'.
|
|
This isn't necessary if you're using
|
|
LILO.</para>
|
|
|
|
<para>Once you can see that's working well, you can
|
|
explore the various VESA modes (see below) and
|
|
decide on the one that you like the best, and
|
|
hardwire that into the "<code>VGA=x</code>" parameter in
|
|
<code>lilo.conf</code>. When you have chosen
|
|
the one you like the best, look up the
|
|
equivalent hexadecimal number from the table
|
|
below and use that (i.e. for 1280x1024 @ 256,
|
|
you just use "<code>VGA=0x307</code>"), and
|
|
re-run lilo. That's all there it is to it. For
|
|
further references, read the LoadLin/LILO
|
|
HOWTOs.</para>
|
|
|
|
<para><emphasis>NOTE!</emphasis> vesafb does not enable
|
|
scrollback buffering as a default. You will
|
|
need to pass to the kernel the option to enable
|
|
it. Use <code>video=vesa:ypan</code> or
|
|
<code>video=vesa:ywrap</code> to activate it.
|
|
Both does the same thing, but in different
|
|
ways. <code>ywrap</code> is a lot faster than
|
|
<code>ypan</code> but may not work on slightly
|
|
broken VESA 2.0 graphic cards.
|
|
<code>ypan</code> is slower than
|
|
<code>ywrap</code> but a lot more compatible.
|
|
This option is only present in kernel 2.1.116
|
|
and above. Earlier kernels did not have the
|
|
ability to allow scrollback buffering in
|
|
vesafb.</para>
|
|
</section>
|
|
<section><title>What VESA modes are available to me?</title>
|
|
<para>This really depends on the type of VESA 2.0
|
|
compliant graphic card that you have in your
|
|
system, and the amount of video memory
|
|
available. This is just a matter of testing
|
|
which modes work best for your graphic
|
|
card.</para>
|
|
|
|
<para>The following table shows the mode numbers you
|
|
can input at the VGA prompt or for use with the
|
|
LILO program. (actually these numbers are plus
|
|
0x200 to make it easier to refer to the
|
|
table)</para>
|
|
|
|
<table><title>VESA modes</title>
|
|
<tgroup cols="8">
|
|
<colspec align="right"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<thead>
|
|
<row>
|
|
<entry>Depth</entry>
|
|
<entry>640x400</entry>
|
|
<entry>640x480</entry>
|
|
<entry>800x600</entry>
|
|
<entry>1024x768</entry>
|
|
<entry>1152x864</entry>
|
|
<entry>1280x1024</entry>
|
|
<entry>1600x1200</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>4 bits</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
<entry>0x302</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
</row>
|
|
<row>
|
|
<entry>8 bits</entry>
|
|
<entry>0x300</entry>
|
|
<entry>0x301</entry>
|
|
<entry>0x303</entry>
|
|
<entry>0x305</entry>
|
|
<entry>0x161</entry>
|
|
<entry>0x307</entry>
|
|
<entry>0x31C</entry>
|
|
</row>
|
|
<row>
|
|
<entry>15 bits</entry>
|
|
<entry>?</entry>
|
|
<entry>0x310</entry>
|
|
<entry>0x313</entry>
|
|
<entry>0x316</entry>
|
|
<entry>0x162</entry>
|
|
<entry>0x319</entry>
|
|
<entry>0x31D</entry>
|
|
</row>
|
|
<row>
|
|
<entry>16 bits</entry>
|
|
<entry>?</entry>
|
|
<entry>0x311</entry>
|
|
<entry>0x314</entry>
|
|
<entry>0x317</entry>
|
|
<entry>0x163</entry>
|
|
<entry>0x31A</entry>
|
|
<entry>0x31E</entry>
|
|
</row>
|
|
<row>
|
|
<entry>24 bits</entry>
|
|
<entry>?</entry>
|
|
<entry>0x312</entry>
|
|
<entry>0x315</entry>
|
|
<entry>0x318</entry>
|
|
<entry>?</entry>
|
|
<entry>0x31B</entry>
|
|
<entry>0x31F</entry>
|
|
</row>
|
|
<row>
|
|
<entry>32 bits</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
<entry>0x164</entry>
|
|
<entry>?</entry>
|
|
<entry>?</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
<para>Key: 8 bits = 256 colours, 15 bits = 32,768
|
|
colours, 16 bits = 65,536 colours, 24 bits =
|
|
16.8 million colours, 32 bits - same as 24
|
|
bits, but the extra 8 bits can be used for
|
|
other things, and fits perfectly on a 32 bit
|
|
PCI/VLB/EISA bus.</para>
|
|
|
|
<para>Additional modes are at the discretion of the
|
|
manufacturer, as the VESA 2.0 document only
|
|
defines modes up to 0x31F. You may need to do
|
|
some fiddling around to find these extra
|
|
modes.</para>
|
|
</section>
|
|
|
|
<section><title>Got a Matrox card?</title>
|
|
<para>If you've got a Matrox graphic card, you don't
|
|
actually need vesafb, you need the matroxfb
|
|
driver instead. This greatly enhances the
|
|
capabilities of your card. Matroxfb will work
|
|
with Matrox Mystique Millennium I & II,
|
|
G100 and G200. It also supports multiheaded
|
|
systems (that is, if you have two Matrox cards
|
|
in your machine, you can use two displays on
|
|
the same machine!). To configure for Matrox,
|
|
you will need to do the following:</para>
|
|
|
|
<para>You might want to upgrade the Matrox BIOS first,
|
|
you can download the BIOS upgrade from <ulink
|
|
url="http://www.matrox.com/mgaweb/drivers/ftp_bios.htm"></ulink>
|
|
Beware that you will need DOS to do
|
|
this.</para>
|
|
|
|
<para>Go into the Code Maturity Level menu, and enable
|
|
the prompt for development and/or incomplete
|
|
drivers [note this may change for future
|
|
kernels - when this happens, this HOWTO will be
|
|
revised]</para>
|
|
|
|
<para>Go into the Console Drivers menu, and enable the
|
|
following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>VGA Text
|
|
Console</para></listitem>
|
|
<listitem><para>Video Selection
|
|
Support</para></listitem>
|
|
<listitem><para>Support for frame buffer
|
|
devices
|
|
(experimental)</para></listitem>
|
|
<listitem><para>Matrox
|
|
Acceleration</para></listitem>
|
|
<listitem><para>Select the following depending
|
|
on the card that you
|
|
have</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para>Millennium I /
|
|
II
|
|
support</para></listitem>
|
|
<listitem><para>Mystique
|
|
support</para></listitem>
|
|
<listitem><para>G100 / G200
|
|
support</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
<listitem><para>Enable Multihead Support if you
|
|
want to use more than one
|
|
Matrox card</para></listitem>
|
|
<listitem><para>Advanced Low Level
|
|
Drivers</para></listitem>
|
|
<listitem><para>elect Mono, 2bpp, 4bpp, 8bpp,
|
|
16bpp, 24bpp and 32bpp packed
|
|
pixel drivers</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Rebuild your kernel. Then you will need to modify
|
|
your <code>lilo.conf</code> file to enable the
|
|
Matroxfb device. The quickest and simplest way
|
|
is re-use mine.</para>
|
|
|
|
|
|
<para><literallayout><code>
|
|
# LILO configuration file
|
|
boot = /dev/hda3
|
|
delay = 30
|
|
prompt
|
|
vga = 792 # You need to do this so it boots up in a sane state
|
|
# Linux bootable partition config begins
|
|
image = /vmlinuz
|
|
append = "video=matrox:vesa:440" # then switch to Matroxfb
|
|
root = /dev/hda3
|
|
label = Linux
|
|
read-only # Non-UMSDOS filesystems should be mounted read-only for checking
|
|
</code></literallayout></para>
|
|
|
|
<para>Lastly, you'll need to create the framebuffer
|
|
device in <code>/dev</code>. You need one per
|
|
framebuffer device, so all you need to do is to
|
|
type in <code>mknod /dev/fb0 c 29 0</code> for
|
|
the first one. Subsequent ones would be in
|
|
multiples of 32, so for example to create
|
|
<code>/dev/fb1</code>, you would need to type
|
|
in <code>mknod /dev/fb1 c 29 32</code>, and so
|
|
on up to the eight framebuffer device
|
|
(<code>mknod /dev/fb7 c 29 224i</code>)</para>
|
|
|
|
<para>And that should be it! [NOTE: Is anyone using
|
|
this multiheaded support, please get in touch
|
|
with me ASAP - I need to talk to you about it
|
|
so I can document it!</para>
|
|
</section>
|
|
|
|
<section><title>Got a Permedia card?</title>
|
|
<para>Permedia cards cannot be used with the vesafb
|
|
driver, but fortunately, there is the Permedia
|
|
framebuffer driver available to use. Assuming
|
|
you are using menuconfig, do the
|
|
following:</para>
|
|
|
|
<para>Go into the Code Maturity Level menu, and enable
|
|
the prompt for development and/or incomplete
|
|
drivers [note this may change for future
|
|
kernels - when this happens, this HOWTO will be
|
|
revised]</para>
|
|
|
|
<para>Go into the Console Drivers menu and select the
|
|
following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>VGA Text
|
|
Console</para></listitem>
|
|
<listitem><para>Video Selection
|
|
Support</para></listitem>
|
|
<listitem><para>Support for frame buffer
|
|
devices
|
|
(experimental)</para></listitem>
|
|
<listitem><para>Permedia2 support
|
|
(experimental)</para></listitem>
|
|
<listitem><para>Generic Permedia2 PCI board
|
|
support</para></listitem>
|
|
<listitem><para>Advanced Low Level
|
|
Drivers</para></listitem>
|
|
<listitem><para>Select Mono, 2bpp, 4bpp, 8bpp,
|
|
16bpp, 24bpp and 32bpp packed
|
|
pixel drivers</para></listitem>
|
|
<listitem><para>Optionally, select the
|
|
following, if you wish to use
|
|
the compiled in
|
|
fonts</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para>Select
|
|
compiled-in
|
|
fonts</para></listitem>
|
|
<listitem><para>Select Sparc
|
|
console 12x22
|
|
font</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Rebuild your kernel. Then you will need to modify
|
|
your <code>lilo.conf</code> file to enable the
|
|
pm2fb device. The quickest and simplest way is
|
|
re-use the following:</para>
|
|
|
|
<para><literallayout><code>
|
|
# LILO configuration file
|
|
boot = /dev/hda3
|
|
delay = 30
|
|
prompt
|
|
vga = 792 # You need to do this so it boots up in a sane state
|
|
# Linux bootable partition config begins
|
|
image = /vmlinuz
|
|
append = "video=pm2fb:mode:1024x768-75,font:SUN12x22,ypan" # then switch to pm2fb
|
|
root = /dev/hda3
|
|
label = Linux
|
|
read-only # Non-UMSDOS filesystems should be mounted read-only for checking
|
|
</code></literallayout></para>
|
|
|
|
<para>The line
|
|
"<code>pm2fb:mode:1024x768-75,font:SUN12x22,ypan</code>"
|
|
indicates you are selecting a 1024x768 mode at
|
|
75Hz, with the <code>SUN12x22</code> font
|
|
selected (if you did select it), including ypan
|
|
for scrollback support. You may select other
|
|
modes if you desire.</para>
|
|
|
|
<para>Lastly, you'll need to create the framebuffer
|
|
device in <code>/dev</code>. You need one per
|
|
framebuffer device, so all you need to do is to
|
|
type in <code>mknod /dev/fb0 c 29 0</code> for
|
|
the first one. Subsequent ones would be in
|
|
multiples of 32, so for example to create
|
|
<code>/dev/fb1</code>, you would need to type
|
|
in <code>mknod /dev/fb1 c 29 32</code>, and so
|
|
on up to the eight framebuffer device
|
|
(<code>mknod /dev/fb7 c 29 224</code>)</para>
|
|
|
|
<para>For more information on the other features of the
|
|
Permedia framebuffer driver, point your browser
|
|
at <ulink
|
|
url="http://www.cs.unibo.it/~nardinoc/pm2fb/index.html"></ulink></para>
|
|
|
|
<para><code>video=pm2fb:[option[,option[,option...]]]</code></para>
|
|
|
|
<para>where option is one of the following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>off</code> - disables the
|
|
driver</para></listitem>
|
|
<listitem><para><code>mode:resolution</code> -
|
|
sets the console resolution.
|
|
The modes have been taken from
|
|
the <code>fb.modes.ATI</code>
|
|
file in Geert's
|
|
<code>fbset</code> package. The
|
|
depth for all the modes is 8
|
|
bpp. This the list of available
|
|
modes:</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>640x480-(60,72,75,90,100)</code></para></listitem>
|
|
<listitem><para><code>640x480-(60,72,75,90,100)</code></para></listitem>
|
|
<listitem><para><code>1024x768-(60,70,72,75,90,100,illo)
|
|
illo=80KHz
|
|
100Hz</code></para></listitem>
|
|
<listitem><para><code>152x864-(60,70,75,80)</code></para></listitem>
|
|
<listitem><para><code>1280x1024-(60,70,74,75)</code></para></listitem>
|
|
<listitem><para><code>1600x1200-(60,66,76)</code></para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
<listitem override="none"><para>The default
|
|
resolution is
|
|
640x480-60</para></listitem>
|
|
<listitem><para><code>font:name</code> - sets
|
|
the console font. Example
|
|
<code>font:SUN12x12</code></para></listitem>
|
|
<listitem><para><code>ypan</code> - sets the
|
|
current virtual height as big
|
|
as video memory
|
|
permits.</para></listitem>
|
|
<listitem><para><code>oldmem</code> - used for
|
|
CybervisionPPC boards only with
|
|
Fujitsi SGRAMs mounted. Applies
|
|
to all CyberVisionPPCs made
|
|
before
|
|
30-Dec-1998.</para></listitem>
|
|
<listitem><para><code>virtual</code> - used
|
|
with kernels capable of
|
|
remapping the PCI
|
|
regions</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section><title>Got an ATI card?</title>
|
|
<para>[Note: This information is at best, only
|
|
second-hand or third-hand, since I don't have
|
|
an ATI card to test it with. Feel free to
|
|
correct me if I am wrong or flame me!] 8)</para>
|
|
|
|
<para>ATI cards can be used with the vesafb driver, but
|
|
you may or may not have problems, depending on
|
|
how horribly broken the card is. Fortunately,
|
|
there is the atyfb framebuffer driver available
|
|
to use. Assuming you are using menuconfig, do
|
|
the following:</para>
|
|
|
|
<para>Go into the Code Maturity Level menu, and enable
|
|
the prompt for development and/or incomplete
|
|
drivers [note this may change for future
|
|
kernels - when this happens, this HOWTO will be
|
|
revised]</para>
|
|
|
|
<para>Go into the Console Drivers menu and select the
|
|
following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>VGA Text
|
|
Console</para></listitem>
|
|
<listitem><para>Video Selection
|
|
Support</para></listitem>
|
|
<listitem><para>Support for frame buffer
|
|
devices
|
|
(experimental)</para></listitem>
|
|
<listitem><para>ATI Mach64 display
|
|
support</para></listitem>
|
|
<listitem><para>Advanced Low Level
|
|
Drivers</para></listitem>
|
|
<listitem><para>Select Mono, 2bpp, 4bpp, 8bpp,
|
|
16bpp, 24bpp and 32bpp packed
|
|
pixel drivers</para></listitem>
|
|
<listitem><para>Optionally, select the
|
|
following, if you wish to use
|
|
the compiled in
|
|
fonts</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para>Select
|
|
compiled-in
|
|
fonts</para></listitem>
|
|
<listitem><para>Select Sparc
|
|
console 12x22
|
|
font</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Rebuild your kernel. Then you will need to modify
|
|
your <code>lilo.conf</code> file to enable the
|
|
<code>atyfb</code> device. The quickest and
|
|
simplest way is re-use the following:</para>
|
|
|
|
<para><literallayout><code>
|
|
# LILO configuration file
|
|
boot = /dev/hda3
|
|
delay = 30
|
|
prompt
|
|
vga = 792 # You need to do this so it boots up in a sane state
|
|
# Linux bootable partition config begins
|
|
image = /vmlinuz
|
|
append = "video=atyfb:mode:1024x768,font:SUN12x22"
|
|
root = /dev/hda3
|
|
label = Linux
|
|
read-only # Non-UMSDOS filesystems should be mounted read-only for checking
|
|
</code></literallayout></para>
|
|
|
|
<para>The line "<code>atyfb:mode:1024x768,font:SUN12x22</code>"
|
|
indicates you are selecting a 1024x768
|
|
mode.</para>
|
|
|
|
<para>Lastly, you'll need to create the framebuffer
|
|
device in <code>/dev</code>. You need one per
|
|
framebuffer device, so all you need to do is to
|
|
type in <code>mknod /dev/fb0 c 29 0</code> for
|
|
the first one. Subsequent ones would be in
|
|
multiples of 32, so for example to create
|
|
<code>/dev/fb1</code>, you would need to type
|
|
in <code>mknod /dev/fb1 c 29 32</code>, and so
|
|
on up to the eight framebuffer device
|
|
(<code>mknod /dev/fb7 c 29 224</code>)</para>
|
|
|
|
<para><code>video=atyfb:[option[,option[,option...]]]</code></para>
|
|
|
|
<para>where option is one of the following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>font</code> - selects
|
|
font to use (compiled into
|
|
kernel)</para></listitem>
|
|
<listitem><para><code>noblink</code> - turns
|
|
off blinking</para></listitem>
|
|
<listitem><para><code>noaccel</code> - disables
|
|
acceleration</para></listitem>
|
|
<listitem><para><code>vram</code> - how much
|
|
video memory is there on the
|
|
card</para></listitem>
|
|
<listitem><para><code>pll</code> -
|
|
unknown</para></listitem>
|
|
<listitem><para><code>mclk</code> -
|
|
unknown</para></listitem>
|
|
<listitem><para><code>vmode</code> -
|
|
unknown</para></listitem>
|
|
<listitem><para><code>cmode</code> - sets
|
|
colour depth (4, 8, 15, 16, 24
|
|
and 32)</para></listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section><title>Which graphic cards are VESA 2.0 compliant?</title>
|
|
<para>This lists all the graphic devices that are known
|
|
to work with the vesafb device driver:</para>
|
|
<itemizedlist>
|
|
<listitem><para>ATI PCI VideoExpression 2MB
|
|
(max. 1280x1024 @
|
|
8bit)</para></listitem>
|
|
<listitem><para>ATI PCI
|
|
All-in-Wonder</para></listitem>
|
|
<listitem><para>Matrox Millennium PCI - BIOS
|
|
v3.0</para></listitem>
|
|
<listitem><para>Matrox Millennium II PCI - BIOS
|
|
v1.5</para></listitem>
|
|
<listitem><para>Matrox Millennium II AGP - BIOS
|
|
v1.4</para></listitem>
|
|
<listitem><para>Matrox Millennium G200 AGP -
|
|
BIOS v1.3</para></listitem>
|
|
<listitem><para>Matrox Mystique & Mystique
|
|
220 PCI - BIOS
|
|
v1.8</para></listitem>
|
|
<listitem><para>Matrox Mystique G200 AGP - BIOS
|
|
v1.3</para></listitem>
|
|
<listitem><para>Matrox Productiva G100 AGP -
|
|
BIOS v1.4</para></listitem>
|
|
<listitem><para>All Riva 128 based
|
|
cards</para></listitem>
|
|
<listitem><para>Diamond Viper V330 PCI
|
|
4MB</para></listitem>
|
|
<listitem><para>Genoa Phantom 3D/S3
|
|
ViRGE/DX</para></listitem>
|
|
<listitem><para>Hercules Stingray 128/3D with
|
|
TV output</para></listitem>
|
|
<listitem><para>Hercules Stingray 128/3D
|
|
without TV output - needs BIOS
|
|
upgrade (free from
|
|
support@hercules.com)</para></listitem>
|
|
<listitem><para>SiS 6326 PCI/AGP
|
|
4MB</para></listitem>
|
|
<listitem><para>STB Lightspeed 128 (Nvida Riva
|
|
128 based)
|
|
PCI</para></listitem>
|
|
<listitem><para>STB Velocity 128 (Nvida Riva
|
|
128 based)
|
|
PCI</para></listitem>
|
|
<listitem><para>Jaton Video-58P ET6000 PCI
|
|
2MB-4MB (max. 1600x1200 @
|
|
8bit)</para></listitem>
|
|
<listitem><para>Voodoo2 2000</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>This list below blacklists graphic cards that
|
|
doesn't work with the vesafb device:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>TBD</para></listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section><title>Can I compile vesafb as a module?</title>
|
|
<para>As far as is known, vesafb can't be modularised,
|
|
although at some point in time, the developer
|
|
of vesafb may decide to modify the sources for
|
|
modularising. Note that even if modularising is
|
|
possible, at boot time you will not be able to
|
|
see any output on the display until vesafb is
|
|
modprobed. It's probably a lot wiser to leave
|
|
it in the kernel, for these cases when there
|
|
are booting problems.</para>
|
|
</section>
|
|
|
|
<section><title>How do I modify the cursor</title>
|
|
|
|
<para>With thanks to Martin Mares, taken from his
|
|
VGA-softcursor.txt document.</para>
|
|
|
|
<para>Linux now has some ability to manipulate cursor
|
|
appearance. Normally, you can set the size of
|
|
hardware cursor (and also work around some ugly
|
|
bugs in those miserable Trident cards -- see
|
|
<code>#define TRIDENT_GLITCH</code> in
|
|
<code>drivers/char/vga.c</code>). In case you
|
|
enable "Software generated cursor" in the
|
|
system configuration, you can play a few new
|
|
tricks: you can make your cursor look like a
|
|
non-blinking red block, make it inverse
|
|
background of the character it's over or to
|
|
highlight that character and still choose
|
|
whether the original hardware cursor should
|
|
remain visible or not. There may be other
|
|
things I have never thought of.</para>
|
|
|
|
<para>The cursor appearance is controlled by a
|
|
<code><ESC>[?1;2;3c</code> escape
|
|
sequence where 1, 2 and 3 are parameters
|
|
described below. If you omit any of them, they
|
|
will default to zeroes.</para>
|
|
|
|
<para>Parameter 1 specifies cursor size (0 = default, 1
|
|
= invisible, 2 = underline, ..., 8 = full
|
|
block) + 16 if you want the software cursor to
|
|
be applied + 32 if you want to always change
|
|
the background colour + 64 if you dislike
|
|
having the background the same as the
|
|
foreground. Highlights are ignored for the
|
|
last two flags.</para>
|
|
|
|
<para>The second parameter selects character attribute
|
|
bits you want to change (by simply XORing them
|
|
with the value of this parameter). On standard
|
|
VGA, the high four bits specify background and
|
|
the low four the foreground. In both groups,
|
|
low three bits set colour (as in normal colour
|
|
codes used by the console) and the most
|
|
significant one turns on highlight (or
|
|
sometimes blinking - it depends on the
|
|
configuration of your VGA).</para>
|
|
|
|
<para>The third parameter consists of character
|
|
attribute bits you want to set. Bit setting
|
|
takes place before bit toggling, so you can
|
|
simply clear a bit by including it in both the
|
|
set mask and the toggle mask.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>To get normal blinking
|
|
underline, use: <code>echo -e
|
|
'\033<ESC>[?2c'</code></para></listitem>
|
|
<listitem><para>To get blinking block, use:
|
|
<code>echo -e
|
|
'\033<ESC>[?6c'</code></para></listitem>
|
|
<listitem><para>To get red non-blinking block,
|
|
use: <code>echo -e
|
|
'\033i<ESC>[?17;0;64c'</code></para></listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on m68k platforms</title>
|
|
|
|
<section><title>Atari platforms</title>
|
|
<para>This section describe framebuffer options on Atari platforms</para>
|
|
|
|
<section><title>What modes are available?</title>
|
|
|
|
<table><title>Atari modes</title>
|
|
<tgroup cols="8">
|
|
<colspec align="right"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<colspec align="center"></colspec>
|
|
<thead>
|
|
<row>
|
|
<entry>Depth</entry>
|
|
<entry>320x200</entry>
|
|
<entry>320x480</entry>
|
|
<entry>640x200</entry>
|
|
<entry>640x400</entry>
|
|
<entry>640x480</entry>
|
|
<entry>896x608</entry>
|
|
<entry>1280x960</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>1 bit</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>sthigh</entry>
|
|
<entry>vga2</entry>
|
|
<entry>falh2</entry>
|
|
<entry>tthigh</entry>
|
|
</row>
|
|
<row>
|
|
<entry>2 bits</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>stmid</entry>
|
|
<entry></entry>
|
|
<entry>vga4</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry>4 bits</entry>
|
|
<entry>stlow</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>ttmid/vga16</entry>
|
|
<entry>falh16</entry>
|
|
<entry></entry>
|
|
</row>
|
|
<row>
|
|
<entry>8 bits</entry>
|
|
<entry></entry>
|
|
<entry>ttlow</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
<entry>vga256</entry>
|
|
<entry></entry>
|
|
<entry></entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para><emphasis>ttlow, ttmid and
|
|
ttmhigh</emphasis> are only
|
|
used on the TT, whilst <emphasis>vga2,
|
|
vga4, vga16, vga256, falh3 and
|
|
falh16</emphasis> are only used
|
|
on the Falcon.</para>
|
|
|
|
<para>When used with the kernel option
|
|
<code>video=xxx</code>, and no
|
|
suboption is given, the kernel will
|
|
probe for the modes in the following
|
|
order until it finds a mode that is
|
|
possible with the given
|
|
hardware:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>ttmid</code></para></listitem>
|
|
<listitem><para><code>tthigh</code></para></listitem>
|
|
<listitem><para><code>vga16</code></para></listitem>
|
|
<listitem><para><code>sthigh</code></para></listitem>
|
|
<listitem><para><code>stmid</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>You may specify the particular mode you
|
|
wish to use, if you don't wish to
|
|
auto-probe for the modes you desire.
|
|
For example, <code>video=vga16</code>
|
|
gives you a 4 bit 640x480
|
|
display.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Additional suboptions</title>
|
|
|
|
<para>There are a number of suboptions
|
|
available with the
|
|
<code>video=xxx</code>
|
|
parameter:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>inverse</code> -
|
|
inverts the display so
|
|
that the
|
|
background/foreground
|
|
colours are reversed.
|
|
Normally the background
|
|
is black, but with this
|
|
suboption, it gets sets
|
|
to
|
|
white.</para></listitem>
|
|
<listitem><para><code>font</code> -
|
|
sets the font to use in
|
|
text modes. Currently
|
|
you can only select
|
|
<code>VGA8x8</code>,
|
|
<code>VGA8x16</code>,
|
|
<code>PEARL8x8</code>.
|
|
The default is to use
|
|
the <code>VGA8x8</code>
|
|
only if the vertical
|
|
size of the display is
|
|
less than 400 pixels,
|
|
otherwise it defaults
|
|
to
|
|
<code>VGA8x16</code>.</para></listitem>
|
|
<listitem><para><code>internal</code> -
|
|
a very interesting
|
|
option. See the next
|
|
section for
|
|
information.</para></listitem>
|
|
<listitem><para><code>external</code>
|
|
- as
|
|
above.</para></listitem>
|
|
<listitem><para><code>monitorcap</code>
|
|
- describes the
|
|
capabilities
|
|
for multisyncs.
|
|
DON'T use with
|
|
a fixed sync
|
|
monitor!</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<section><title>Using the <code>internal</code>
|
|
suboption</title>
|
|
|
|
<para>Syntax:
|
|
<code>internal:(xres);(yres)[;(xres_max);(yres_max);(offset)]</code></para>
|
|
|
|
<para>This option specifies the
|
|
capabilities of some extended
|
|
internal video hardware, i.e
|
|
OverScan modes.
|
|
<code>(xres)</code> and
|
|
<code>(yres)</code> gives the
|
|
extended dimensions of the
|
|
screen.</para>
|
|
|
|
<para>If your OverScan mode needs a
|
|
black border, you'll need to
|
|
write the last three arguments
|
|
of the <code>internal:</code>
|
|
suboption.
|
|
<code>(xres_max)</code> is the
|
|
maximum line length that the
|
|
hardware allows,
|
|
<code>(yres_max)</code> is the
|
|
maximum number of lines, and
|
|
<code>(offset)</code> is the
|
|
offset of the visible part of
|
|
the screen memory to its
|
|
physical start, in
|
|
bytes.</para>
|
|
|
|
<para>Often extended internal video
|
|
hardware has to be activated,
|
|
for this you will need the
|
|
<code>"switches=*"</code>
|
|
options. [Note: Author would
|
|
like extra information on this,
|
|
please. The m68k documentation
|
|
in the kernel isn't clear
|
|
enough on this point, and he
|
|
doesn't have an Atari! Examples
|
|
would be helpful too]</para>
|
|
</section>
|
|
|
|
<section><title>Using the <code>external</code> suboption</title>
|
|
|
|
<para>Syntax:
|
|
<code>external:(xres);(yres);(depth);(org);(scrmem)[;(scrlen)[;(vgabase)[;(colw)[;(coltype)[;(xres_virtual)]]]]]</code></para>
|
|
|
|
|
|
<para>This is quite complicated, so
|
|
this document will attempt to
|
|
explain as clearly as possible,
|
|
but the Author would appreciate
|
|
if someone would give this a
|
|
look over and see that he
|
|
hasn't fscked something up!
|
|
:o)</para>
|
|
|
|
<para>This suboption specifies that you
|
|
have an external video hardware
|
|
(most likely a graphic board),
|
|
and how to use it with Linux.
|
|
The kernel is basically limited
|
|
to what it knows of the
|
|
internal video hardware, so you
|
|
have to supply the parameters
|
|
it needs in order to be able to
|
|
use external video hardware.
|
|
There are two limitations; you
|
|
must switch to that mode before
|
|
booting, and once booted, you
|
|
can't change modes.</para>
|
|
|
|
<para>The first three parameters are
|
|
obvious; gives the dimensions
|
|
of the screen as pixel height,
|
|
width and depth. The depth
|
|
supplied should be the number
|
|
of colours is 2^n that of the
|
|
number of planes required. For
|
|
example, if you desire to use a
|
|
256 colour display, then you
|
|
need to give 8 as the depth.
|
|
This depends on the external
|
|
graphic hardware, though so you
|
|
will be limited by what the
|
|
hardware can do.</para>
|
|
|
|
<para>Following from this, you also
|
|
need to tell the kernel how the
|
|
video memory is organised -
|
|
supply a letter as the
|
|
<code>(org)</code>
|
|
parameter</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>n</code>
|
|
- use normal
|
|
planes, i.e one
|
|
whole plane
|
|
after another
|
|
</para></listitem>
|
|
<listitem><para><code>i</code>
|
|
- use
|
|
interleaved
|
|
planes, i.e.
|
|
16 bits of the
|
|
first plane,
|
|
then the 16
|
|
bits of the
|
|
next plane and
|
|
so on. Only
|
|
built-in Atari
|
|
video modes
|
|
uses this - and
|
|
there are no
|
|
graphic card
|
|
that supports
|
|
this mode.
|
|
</para></listitem>
|
|
<listitem><para><code>p</code>
|
|
- use packed
|
|
pixels, i.e
|
|
consecutive
|
|
bits stands for
|
|
all planes for
|
|
a pixel. This
|
|
is the most
|
|
common mode for
|
|
256 colour
|
|
displays
|
|
on graphic cards.</para></listitem>
|
|
<listitem><para><code>t</code>
|
|
- use true
|
|
colour, i.e
|
|
this is
|
|
actually packed
|
|
pixels, but
|
|
does not
|
|
require a
|
|
colour lookup
|
|
table like what
|
|
other packed
|
|
pixel modes
|
|
uses. These
|
|
modes are
|
|
normally 24 bit
|
|
displays, and
|
|
provides 16.8
|
|
million
|
|
colours.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para><emphasis>However</emphasis>, for
|
|
monochrome modes, the
|
|
<code>(org)</code> parameter
|
|
has a different meaning:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>n</code>
|
|
- use normal
|
|
colours, i.e. 0
|
|
= white, 1 =
|
|
black</para></listitem>
|
|
<listitem><para><code>i</code>
|
|
- use inverted
|
|
colours, i.e. 0
|
|
= black, 1 =
|
|
white</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>The next important item about the
|
|
video hardware is the base
|
|
address of the video memory.
|
|
That is given by the
|
|
<code>(scrmem)</code> parameter
|
|
as a hexadecimal number with an
|
|
<code>0x</code> prefix. You
|
|
will need to find this out from
|
|
the documentation that comes
|
|
with your external video
|
|
hardware.</para>
|
|
|
|
<para>The next paramter
|
|
<code>(scrlen)</code> tells the
|
|
kernel about the size of the
|
|
video memory. If it's missing,
|
|
this is calculated from the
|
|
<code>(xres)</code>, and
|
|
<code>(depth)</code>
|
|
parameters. It's not useful to
|
|
write a value here these days
|
|
anyway. To leave this empty,
|
|
give two consecutive semicolons
|
|
if you need to give the
|
|
<code>(vgabase)</code>
|
|
parameter, otherwise, just
|
|
leave it.</para>
|
|
|
|
<para>The <code>(vgabase)</code>
|
|
parameter is optional. If it
|
|
isn't given, the kernel can't
|
|
read/write any colour registers
|
|
of the video hardware, and thus
|
|
you have to set up the
|
|
appropriate colours before you
|
|
boot Linux. But if your card is
|
|
VGA compatible, you can give it
|
|
the address where it can locate
|
|
the VGA register set so it can
|
|
change the colour lookup
|
|
tables. This information can be
|
|
found in your external video
|
|
hardware documentation. To make
|
|
this
|
|
<emphasis>clear</emphasis>,
|
|
<code>(vgabase)</code> is the
|
|
<code>base</code> address, i.e
|
|
a 4k aligned address. For
|
|
reading/writing the colour
|
|
registers, the kernel uses the
|
|
address range between
|
|
<code>(vgabase) + 0x3c7</code> and
|
|
<code>(vgabase) + 0x3c9</code>.
|
|
This parameter is given in
|
|
hexadecimal and must have a
|
|
<code>0x</code> prefix, just
|
|
like <code>(scrmem)</code>.
|
|
<code>(colw)</code> is only
|
|
meaningful, if the
|
|
<code>(vgabase)</code>
|
|
parameter is specified. It
|
|
tells the kernel how wide each
|
|
of the colour register is, i.e
|
|
the number of bits per single
|
|
colour (red/green/blue).
|
|
Default is usually 6 bits, but
|
|
it is also common to specify 8
|
|
bits.</para>
|
|
|
|
<para><code>(xres_virtual)</code> is
|
|
only required for the
|
|
ProMST/ET4000 cards where the
|
|
physical linelength differs
|
|
from the visible length. With
|
|
ProMST, you need to supply
|
|
2048, whilst for ET4000, it
|
|
depends on the initialisation
|
|
of the video board.</para>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Amiga platforms</title>
|
|
|
|
<para>This section describes the options for Amigas,
|
|
which are quite similar to those of the Atari
|
|
platform</para>
|
|
|
|
<section><title>What modes are available?</title>
|
|
|
|
<para>This depends on the chipset used in the
|
|
Amiga. There are three main ones;
|
|
<code>OCS</code>, <code>ECS</code> and
|
|
<code>AGA</code> which all uses the
|
|
colour frame buffers.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>NTSC modes</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>ntsc</code>
|
|
-
|
|
640x200</para></listitem>
|
|
<listitem><para><code>ntsc-lace</code>
|
|
-
|
|
640x400</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
<listitem><para>PAL
|
|
modes</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>pal</code>
|
|
-
|
|
640x256</para></listitem>
|
|
<listitem><para><code>pal-lace</code>
|
|
-
|
|
640x512</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
<listitem><para>ECS modes - 2 bit
|
|
colours on ECS
|
|
chipsets, 8 bit colours
|
|
on AGA chipsets
|
|
only</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>multiscan</code>
|
|
-
|
|
640x480</para></listitem>
|
|
<listitem><para><code>multiscan-lace</code>
|
|
-
|
|
640x960</para></listitem>
|
|
<listitem><para><code>euro36</code>
|
|
-
|
|
640x200</para></listitem>
|
|
<listitem><para><code>euro36-lace</code>
|
|
-
|
|
640x400</para></listitem>
|
|
<listitem><para><code>euro72</code>
|
|
-
|
|
640x480</para></listitem>
|
|
<listitem><para><code>euro72-lace</code>
|
|
-
|
|
640x800</para></listitem>
|
|
<listitem><para><code>super72</code>
|
|
-
|
|
800x300</para></listitem>
|
|
<listitem><para><code>super72-lace</code>
|
|
-
|
|
800x400</para></listitem>
|
|
<listitem><para><code>dblntsc</code>
|
|
-
|
|
640x200</para></listitem>
|
|
<listitem><para><code>dblpal</code>
|
|
-
|
|
640x256</para></listitem>
|
|
<listitem><para><code>dblntsc-ff</code>
|
|
-
|
|
640x400</para></listitem>
|
|
<listitem><para><code>dblntsc-lace</code>
|
|
-
|
|
640x800</para></listitem>
|
|
<listitem><para><code>dblpal-ff</code>
|
|
-
|
|
640x512</para></listitem>
|
|
<listitem><para><code>dblpal-lace</code>
|
|
-
|
|
640x1024</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
<listitem><para>VGA modes - 2 bit
|
|
colours on ECS
|
|
chipsets, 8 bit colours
|
|
on AGA
|
|
chipsets</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>vga</code>
|
|
-
|
|
640x480</para></listitem>
|
|
<listitem><para><code>vga70</code>
|
|
-
|
|
640x400</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section><title>Additional suboptions</title>
|
|
|
|
<para>These are similar to the Atari
|
|
suboptions. They are:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>depth</code> -
|
|
specifies the pixel bit
|
|
depth</para></listitem>
|
|
<listitem><para><code>inverse</code> -
|
|
does the same thing as
|
|
the Atari
|
|
suboption</para></listitem>
|
|
<listitem><para><code>font</code> -
|
|
does the same thing as
|
|
the Atari suboption,
|
|
although the
|
|
<code>PEARL8x8</code>
|
|
font is used instead of
|
|
the <code>VGA8x8</code>
|
|
font if the display
|
|
size is less than 400
|
|
pixels
|
|
wide.</para></listitem>
|
|
<listitem><para><code>monitorcap</code>
|
|
- specifies the
|
|
capabilities of the
|
|
multisync monitor. Do
|
|
not use with fixed sync
|
|
monitors</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section><title>Supported Amiga graphic expansion
|
|
boards</title>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>Phase5
|
|
CyberVision
|
|
64</code> (S3
|
|
Trio64
|
|
chipset)</para></listitem>
|
|
<listitem><para><code>Phase5
|
|
CyberVision 64
|
|
3D</code> (S3
|
|
ViRGE
|
|
chipset)</para></listitem>
|
|
<listitem><para><code>MacroSystems
|
|
Retina
|
|
Z3</code> (NCR
|
|
77C32BLT
|
|
chipset)</para></listitem>
|
|
<listitem><para><code>Helfrich Piccolo,
|
|
SD64, GVP ECS
|
|
Spectrum,
|
|
Village Tronic
|
|
Picasso II /
|
|
II+ and
|
|
IV</code>
|
|
(Cirrus Logic GD542x /
|
|
543x
|
|
chipsets)</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section><title>Macintosh platforms</title>
|
|
|
|
<para>Currently, the framebuffer device
|
|
implemented only supports the mode
|
|
selected in MacOS before booting into
|
|
Linux, and also supports 1, 2, 4 and 8
|
|
bit colours modes.</para>
|
|
|
|
<para>Framebuffer suboptions are selected using
|
|
the following syntax:</para>
|
|
|
|
<para><code>video=macfb:<font>:<inverse></code></para>
|
|
|
|
<para>You can select fonts such as VGA8x8,
|
|
VGA8x16 and 6x11 etc. The inverse
|
|
option allows you to use reverse
|
|
video.</para>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on PowerPC platforms</title>
|
|
|
|
<para>The author would love to receive information on the use
|
|
of framebuffer device drivers on this platform.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on Alpha platforms</title>
|
|
|
|
<section><title>What modes are available?</title>
|
|
|
|
<para>So far, there is only the TGA PCI card, which
|
|
only does 80x30 with a resolution of 640x480 at
|
|
either 8 bits or 24 / 32 bits.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Which graphic cards can work on Alpha?</title>
|
|
|
|
<para>This lists all the graphic cards that are known
|
|
to work:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>DEC TGA PCI
|
|
(DEC21030)</code> -
|
|
640x480 & 8 bits or 24 / 32
|
|
bits versions</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on SPARC platforms</title>
|
|
|
|
<section><title>Which graphic cards can work on the SPARC</title>
|
|
|
|
<para>This lists all the graphic cards
|
|
available:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>MG1 / MG2</code> - SBus
|
|
or integrated on Sun3 - max
|
|
1600 x 1200 & mono
|
|
(<code>BWtwo</code>)</para></listitem>
|
|
<listitem><para><code>CGthree</code> - Similar
|
|
to MG1 / MG2 but supports
|
|
colour</para></listitem>
|
|
<listitem><para>GX - SBus - max. 1152 x 900
|
|
& 8 bit
|
|
(<code>CGsix</code>)</para></listitem>
|
|
<listitem><para>TurboGX - SBus - max. 1152 x
|
|
900 & 8 bit
|
|
(<code>CGsix</code>)</para></listitem>
|
|
<listitem><para>SX (SS10 / SS20 only) - max.
|
|
1280 x 1024 & 24 bit
|
|
(<code>CGfourteen</code>)</para></listitem>
|
|
<listitem><para>ZX (TZX) - SBus - accelerated
|
|
24 bit 3D card
|
|
(<code>Leo</code>)</para></listitem>
|
|
<listitem><para>TCX (Sparc 4 only) - max 1280 x
|
|
1024 & 8
|
|
bit</para></listitem>
|
|
<listitem><para>TCX (Sparc 5 only) - max 1152 x
|
|
900 & 24
|
|
bit</para></listitem>
|
|
<listitem><para>Creator - SBus - max 1280 x
|
|
1024 & 24 bit
|
|
(<code>FFB</code></para></listitem>
|
|
<listitem><para>Creator3D - SBus - max 1920 x
|
|
1200 & 24 bit
|
|
(<code>FFB</code></para></listitem>
|
|
<listitem><para>ATI Mach64 - PCI - accelerated
|
|
8 / 24 bit UltraSparc
|
|
only</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>There is the option to use the PROM to output
|
|
characters to the display or to a serial
|
|
console.</para>
|
|
|
|
<para>Also, have a look at the Sparc Frame Buffer FAQ
|
|
at <ulink
|
|
url="http://c3-a.snvl1.sfba.home.com/Framebuffer.html"></ulink></para>
|
|
|
|
</section>
|
|
|
|
<section><title>Configuring the framebuffer devices</title>
|
|
|
|
<para>During make config, you need to choose whether to
|
|
compile <code>promcon</code> and / or
|
|
<code>fbcon</code>. You can select both, but if
|
|
you do this, you will need to set the kernel
|
|
flags to select the device. <code>fbcon</code>
|
|
always takes precedence if not set. If
|
|
<code>promcon</code> is not selected in, on
|
|
boot up, it defaults to <code>dummycon</code>.
|
|
If <code>promcon</code> is selected, it will
|
|
use this device. Once the buses are booted, and
|
|
<code>fbcon</code> is compiled in, the kernel
|
|
probes for the above framebuffers and will use
|
|
<code>fbcon</code>. If there is no framebuffer
|
|
devices, it will default to
|
|
<code>promcon</code></para>
|
|
|
|
<para>Here are the kernel options</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>video=sbus:options</code></para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para>where options
|
|
is a comma
|
|
separated
|
|
list:</para></listitem>
|
|
<listitem override="none">
|
|
<itemizedlist>
|
|
<listitem><para><code>nomargins</code>
|
|
-
|
|
sets
|
|
margins
|
|
to
|
|
0,
|
|
0</para></listitem>
|
|
<listitem><para><code>margins=12x24</code>
|
|
-
|
|
sets
|
|
margins
|
|
to
|
|
12,
|
|
24
|
|
(default
|
|
is
|
|
computed
|
|
from
|
|
resolution)</para></listitem>
|
|
<listitem><para><code>off</code>
|
|
-
|
|
don't
|
|
probe
|
|
for
|
|
any
|
|
SBus
|
|
/
|
|
UPA
|
|
framebuffers</para></listitem>
|
|
<listitem><para><code>font=SUN12x22</code>
|
|
-
|
|
use
|
|
a
|
|
specific
|
|
font</para></listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>So for example, booting with
|
|
<code>video=sbus:nomargins,font=SUN12x22</code>
|
|
gives you a nice fast text console with a text
|
|
resolution of 96x40, looks similar to a Solaris
|
|
console but with colours and virtual terminals
|
|
just like on the x86 platform.</para>
|
|
|
|
<para>If you want to use the <code>SUN12x22</code>
|
|
font, you need to enable it during make config
|
|
(disable the <code>fontwidth != 8</code>
|
|
option). The accelerated framebuffers can
|
|
support any font width between one to sixteen
|
|
pixels, whilst dumb frame buffers only supports
|
|
4, 8, 12 and 16 pixel font widths.</para>
|
|
|
|
<para>It is recommended that you grab a recent
|
|
consoletools packages.</para>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on MIPS platforms</title>
|
|
|
|
<para>There is no need to change anything for this platform,
|
|
this is all handled for you automatically. Indys in
|
|
particular are hardwired to use a console size of
|
|
160x64. However, moves are afoot to rewrite the console
|
|
code for these Indys, so keep an eye on this
|
|
section.</para>
|
|
</section>
|
|
|
|
<section><title>Using framebuffer devices on ARM platforms</title>
|
|
|
|
<section><title>Netwinders</title>
|
|
|
|
<para>For the Netwinders (which uses the ARM SA110 RISC chip -
|
|
a lovely British processor), there are two versions of
|
|
the Cyber2000 framebuffer driver - one for 2.0.x
|
|
kernels and one for 2.2.x kernels. It is quite
|
|
straightforward to enable and use this driver on both
|
|
kernels, however, the older version is hardcoded for
|
|
depth and resolution (blech), but the good news is that
|
|
the newer version in the 2.2.x kernels is much more
|
|
flexible, but currently in a state of flux as it is
|
|
still in development. To get this up and running, your
|
|
best bet is to read the documentation that comes with
|
|
the ARM port of the kernel sources.</para>
|
|
|
|
<para>The Netwinders uses a VGA compatible chipset, but
|
|
unfortunately noone has ported vgafb to it yet. That
|
|
might happen if someone has some time on their
|
|
hands. [I would do it if someone would give me a
|
|
NetWinder to play with]</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Acorn Archimedes</title>
|
|
|
|
<para>Acorns have always had framebuffer support since
|
|
the Linux 1.9.x days. However the Acornfb
|
|
driver in 2.2.x is totally new since the
|
|
generic framebuffer interface changed during
|
|
the development of 2.1.x kernels (which, of
|
|
course, became 2.2.x). As previously, it is a
|
|
simple matter to activate the driver and
|
|
set depths and resolutions.</para>
|
|
</section>
|
|
|
|
<section><title>Other ARM ports (SA7710s et. al.)</title>
|
|
|
|
<para>Surprisingly, there is even a framebuffer driver
|
|
for the Psion 5 and the Geofox! I have been
|
|
told that it displays the Penguin quite well.
|
|
[Someone please donate me a Psion 5!]</para>
|
|
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Using multi-headed framebuffers</title>
|
|
|
|
<para>This part of the document was very kindly donated by
|
|
Frederick A. Niles, who retains all rights to the
|
|
information contained herewith in this section of the
|
|
HOWTO.</para>
|
|
|
|
<section><title>Introduction</title>
|
|
|
|
<para>The main goal of this document is to get you
|
|
started with running a dual head configuration
|
|
of Linux. While this process is pretty
|
|
straight forward there are numerous things that
|
|
one can do wrong along the way.</para>
|
|
|
|
<para>The example I concentrate on is getting an
|
|
X-server running on a second monitor. I find
|
|
this nice as you can usually find old large 19"
|
|
to 21" fixed frequency monitors around that
|
|
people are giving away because they can't use
|
|
them. This way you can boot off a small
|
|
multisync and then use X on a nice big
|
|
monitor.</para>
|
|
|
|
<para>Please understand dual head support is currently
|
|
developing so this information changes rapidly.
|
|
Anything in this document could be out of date
|
|
or just plain incorrect by the time you are
|
|
reading this.</para>
|
|
|
|
<para>** WARNING ** This document was written before
|
|
any XFree86 4.0 release. If you are reading
|
|
this and XFree86 4.0 is already released many
|
|
things may have changed. Try getting a newer
|
|
version of this document if it's
|
|
available.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Feedback</title>
|
|
|
|
<para>Feedback is most certainly welcome for this
|
|
document. Without your submissions and input,
|
|
this document wouldn't exist. So, please post
|
|
your additions, comments and criticisms to:
|
|
<email>Frederick.A.Niles@gsfc.nasa.gov</email>.</para>
|
|
</section>
|
|
|
|
<section><title>Contributors</title>
|
|
|
|
<para>The following people have contributed to this
|
|
mini-HOWTO.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Petr
|
|
Vandrovec</para></listitem>
|
|
<listitem><para>Andreas Ehliar
|
|
(x2x)</para></listitem>
|
|
<listitem><para>Marco Bizzarri (multiple X
|
|
servers)</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</section>
|
|
|
|
<section><title>Standard Disclaimer</title>
|
|
|
|
<para>No liability for the contents of this document
|
|
can be accepted. Use the concepts, examples
|
|
and other content at your own risk. As this is
|
|
a new edition of this document, there may be
|
|
errors and inaccuracies that could be damaging
|
|
to your system. Proceed with caution, and
|
|
although this is highly unlikely, I don't take
|
|
any responsibility for that.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Copyright Information</title>
|
|
|
|
<para>This section of the document is copyrighted
|
|
© 1999 Frederick Niles and distributed
|
|
under the following terms:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Linux HOWTO documents may be
|
|
reproduced and distributed in
|
|
whole or in part, in any medium
|
|
physical or electronic, as long
|
|
as this copyright notice is
|
|
retained on all copies.
|
|
Commercial redistribution is
|
|
allowed and encouraged;
|
|
however, the author would like
|
|
to be notified of any such
|
|
distributions.</para></listitem>
|
|
|
|
<listitem><para>All translations, derivative
|
|
works, or aggregate works
|
|
incorporating any Linux HOWTO
|
|
documents must be covered under
|
|
this copyright notice. That
|
|
is, you may not produce a
|
|
derivative work from a HOWTO
|
|
and impose additional
|
|
restrictions on its
|
|
distribution. Exceptions to
|
|
these rules may be granted
|
|
under certain conditions;
|
|
please contact the Linux HOWTO
|
|
coordinator at the address
|
|
given below.</para></listitem>
|
|
|
|
<listitem><para>If you have questions, please
|
|
contact, the Linux HOWTO
|
|
coordinator, at
|
|
<email>linux-howto@sunsite.unc.edu</email></para></listitem>
|
|
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section><title>What hardware is supported?</title>
|
|
|
|
<para>Most video cards assume they will be the only one
|
|
in the system and are permanently set with the
|
|
addressing of the primary display adapter.
|
|
There are a few exceptions.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Matrox cards: This includes
|
|
Matrox Millennium, Matrox
|
|
Millennium II, Matrox Mystique,
|
|
Matrox Mystique 220, Matrox
|
|
Productiva G100, Matrox
|
|
Mystique G200, Matrox
|
|
Millennium G200 and Matrox
|
|
Marvel G200 video
|
|
cards</para></listitem>
|
|
<listitem><para>MDA: This includes monochrome
|
|
Hercules graphics adapters among
|
|
others. This for text only
|
|
second head
|
|
support.</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Note: it's only the second adapter that
|
|
has to be one of the above.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Commercial support</title>
|
|
|
|
<para>This mini-HOWTO in primarily concerned with free
|
|
software. However, there are commercial X
|
|
servers with multi-head support. These include
|
|
Metro Link's (www.metrolink.com) Metro-X and Xi
|
|
Graphics' (www.xig.com) Accelerated-X.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Getting all the stuff</title>
|
|
|
|
<para>You'll need the following patches and programs:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>fbset</code> program -
|
|
try <ulink
|
|
url="http://www.cs.kuleuven.ac.be/~geert/bin/"></ulink>
|
|
(note: RedHat 6.0 already has
|
|
this program
|
|
included)</para></listitem>
|
|
<listitem><para><code>fbaddon</code> Matrix
|
|
dual head patches for Linux
|
|
kernel - try <ulink
|
|
url="ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/"></ulink></para></listitem>
|
|
<listitem><para><code>con2fb</code> program -
|
|
try <ulink
|
|
url="ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/"></ulink></para></listitem>
|
|
<listitem><para>The X11 frame buffer server
|
|
<code>XF86_FBDev</code>. This
|
|
is a standard part of XFree86
|
|
3.3.1.</para></listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section><title>Getting Started</title>
|
|
|
|
<para>The first thing you'll need to do is to patch a
|
|
copy of the Linux source with the
|
|
"<code>fbaddon</code>" patch. Then you need to
|
|
configure the kernel and turn on frame buffer
|
|
support. If you have Matrox cards turn on
|
|
Matrox unified accelerated driver support as
|
|
well as the particular type of card you have.
|
|
Don't turn on VESA frame buffer support. It can
|
|
cause a conflict. Do turn on multi-head
|
|
support (obviously). Build the kernel and
|
|
reboot.</para>
|
|
|
|
<para>Now you need to install the "<code>fbset</code>"
|
|
program and carefully read all the
|
|
documentation on how to adjust the settings.
|
|
Using a "<code>/etc/fb.modes</code>" file is
|
|
highly recommended once you've decided on your
|
|
settings. The fbset program includes a Perl
|
|
script to convert your XF86Config file to
|
|
fb.modes settings. I've included my
|
|
octave/Borne shell script to convert your
|
|
XF86Config file in Appendix A & B.</para>
|
|
|
|
<para>You need to get comfortable with using the frame
|
|
buffer device on one monitor, understanding any
|
|
issues that can arise from your set up that
|
|
have nothing to do with multi-head support.
|
|
This can save a lot of head scratching
|
|
later.</para>
|
|
|
|
<para>I'm going to concentrate my explanation on
|
|
getting X running on the second monitor as
|
|
doing most other configurations will just be a
|
|
obvious subset of the procedure.</para>
|
|
|
|
<section><title>Move a console over...</title>
|
|
|
|
<para>Compile the "con2fb" program. If you run
|
|
it without any arguments you'll get the
|
|
following usage message: "<code>usage:
|
|
con2fb fbdev
|
|
console</code>".</para>
|
|
|
|
<para>Thus, an example command would be
|
|
"<code>con2fb /dev/fb1
|
|
/dev/tty6</code>" to move
|
|
virtual console number six over to the
|
|
second monitor. Use Ctrl-Alt-F6 to
|
|
move over to that console and see that
|
|
it does indeed show up on the second
|
|
monitor.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Use "<code>fbset</code>" to adjust the
|
|
settings on this second display</title>
|
|
|
|
<para>Only set the "<code>fbset</code>"
|
|
settings on the monitor you run the
|
|
"<code>fbset</code>" command on.
|
|
Therefore, you must be careful to use
|
|
the "<code>-fb</code>" flag on the
|
|
second monitor. In particular, if you
|
|
do nothing else you'll probably want to
|
|
at least set the virtual vertical
|
|
resolution to your actually vertical
|
|
resolution.</para>
|
|
|
|
<para>e.g. "<code>fbset -fb /dev/fb1 -vyres
|
|
600</code>"</para>
|
|
|
|
<para>This will seriously slow down text mode,
|
|
but X will be obnoxious without
|
|
it.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Set up X for framebuffer support.</title>
|
|
|
|
<para>The framebuffer.txt file explains this
|
|
better than I can, but here's the two
|
|
important points.</para>
|
|
|
|
<para>Make sure you set the link for "X" to
|
|
point to "XF86_FBDev".</para>
|
|
|
|
<para>Next you need to add a monitor section to
|
|
your XF86Config file for the frame
|
|
buffer device. Here's an example:</para>
|
|
|
|
<para><literallayout><code>
|
|
# The Frame Buffer server
|
|
|
|
Section "Screen"
|
|
Driver "fbdev"
|
|
Device "Millennium"
|
|
Monitor "NEC MultiSync 5FGp"
|
|
Subsection "Display"
|
|
Depth 8
|
|
Modes "default"
|
|
ViewPort 0 0
|
|
EndSubsection Subsection "Display"
|
|
Depth 16
|
|
Modes "default"
|
|
ViewPort 0 0
|
|
EndSubsection
|
|
Subsection "Display"
|
|
Depth 24
|
|
Modes "default"
|
|
ViewPort 0 0
|
|
EndSubsection
|
|
Subsection "Display"
|
|
Depth 32
|
|
Modes "default"
|
|
ViewPort 0 0
|
|
EndSubsection
|
|
EndSection
|
|
</code></literallayout></para>
|
|
|
|
<para>Use the "<code>default</code>" modes as I don't think
|
|
any other ones will work with the Matrox
|
|
frame buffer.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Try starting the X server on the second
|
|
display</title>
|
|
|
|
<para>Set the environment variable
|
|
<code>FRAMEBUFFER</code> to the second
|
|
frame buffer.</para>
|
|
|
|
<para>"<code>export
|
|
FRAMEBUFFER=/dev/fb1</code>" or
|
|
"<code>setenv FRAMEBUFFER
|
|
/dev/fb1</code>"</para>
|
|
|
|
<para>You need to start the X server so that it
|
|
both matches the selected color depth
|
|
and it appears on the same monitor you
|
|
start the X server from.</para>
|
|
|
|
<para>e.g. "<code>startx -- :0 -bpp 16
|
|
vt06</code>"</para>
|
|
|
|
<para>This example will start the "zeroth" X
|
|
server on virtual console six with 16
|
|
bit color. Using ":1" when launching
|
|
another X server for the other frame
|
|
buffer will allow you to have two X
|
|
servers running.</para>
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Summary</title>
|
|
|
|
<para>The steps involved in getting a X server running
|
|
on a second display can be summrized as
|
|
follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Get the kernel patch,
|
|
<code>fbset</code> and
|
|
<code>con2fb</code></para></listitem>
|
|
<listitem><para>Patch the kerenl, configure,
|
|
rebuild and
|
|
reboot</para></listitem>
|
|
<listitem><para>Add <code>XF86_FBDev</code>
|
|
section to XF86Config file and
|
|
set X symbolic
|
|
link</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Then each time you reboot:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Move a console over e.g.
|
|
"<code>con2fb /dev/fb1
|
|
/dev/tty6</code>"</para></listitem>
|
|
<listitem><para>Adjust the settings e.g.
|
|
"<code>fbset -fb /dev/fb1
|
|
1280x1024</code>"</para></listitem>
|
|
<listitem><para>Set the FRAMEBUFFER e.g. "<code>export FRAMEBUFFER=/dev/fb1</code>"</para></listitem>
|
|
<listitem><para>Start the X server e.g. "<code>startx -- -bpp 16 vt06</code>"</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>You can automate this each time you reboot via a
|
|
shell alias. It must be an alias and not a
|
|
shell script since it needs to detect the
|
|
current console number. This is my csh alias
|
|
to start up X on a second fixed frequency
|
|
monitor:</para>
|
|
|
|
<para><literallayout><code>
|
|
alias startxfb = "
|
|
setenv FRAMEBUFFER /dev/fb\!*; # Set the env var to the cmd arg.
|
|
con2fb $FRAMEBUFFER /dev/$tty; # Move the fb to the current tty.
|
|
fbset -fb $FRAMEBUFFER 1280x1024@62; # Favorite from /etc/fb.modes
|
|
startx -- :\!* -bpp 16 vt0`echo $tty | cut -dy f 2`' # X on this tty.
|
|
"
|
|
</code></literallayout></para>
|
|
|
|
<para>In my .cshrc file these are all on the same line
|
|
together without the comments, but it's easier
|
|
to read here with line breaks and comments
|
|
inserted. I just give the number of the frame
|
|
buffer as an argument and it starts right
|
|
up.</para>
|
|
|
|
<para>I'm not sure how to do this same alias in bash.
|
|
I don't know how to determine the current tty
|
|
or get the arguments to an alias in bash. If
|
|
someone lets me know I'll insert it here.
|
|
However, you can use the "tty" command to get
|
|
the name of the current VT and just make two
|
|
separate aliases for each X server.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Other Notes and Problems</title>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Both "<code>fbset</code>" and
|
|
"<code>startx</code>" commands
|
|
MUST be run from the same frame
|
|
buffer as the one being
|
|
affected. This places serious
|
|
limits on how much of these
|
|
commands can be automated via
|
|
scripts.</para></listitem>
|
|
|
|
<listitem><para>XFree86 4.0 will have "proper"
|
|
multi-head support, but 3.3.1
|
|
does not. You can run two
|
|
servers with 3.3.1 and use
|
|
"<code>x2x</code>" to switch
|
|
between them
|
|
however...(see the next
|
|
bullet)</para></listitem>
|
|
|
|
<listitem><para>The inactive frame buffer will
|
|
just hold the last image of
|
|
when it was active, no updates
|
|
with occur.</para></listitem>
|
|
|
|
<listitem><para>The monitor that's not selected
|
|
doesn't always preseve it's
|
|
state when not active. (But it
|
|
usually does)</para></listitem>
|
|
|
|
<listitem><para>Geert Uytterhoeven (the frame
|
|
buffer maintainer) and Linus
|
|
Torvalds don't agree with the
|
|
current "frame buffer per VT"
|
|
multi-head console support
|
|
changes (i.e.
|
|
"<code>fbaddon</code>") so it
|
|
may never be in the mainstream
|
|
kernel tree. (This was heard
|
|
third hand and may be wildly
|
|
untrue.)</para></listitem>
|
|
|
|
<listitem><para>If you "break the rules" and
|
|
start the X server (run
|
|
"<code>startx</code>") from a
|
|
different monitor, the machine
|
|
can eventually crash badly with
|
|
the keyboard and mouse input
|
|
all mixed
|
|
together.</para></listitem>
|
|
|
|
<listitem><para>The documentation
|
|
framebuffer.txt in the kernel
|
|
source explains that you can
|
|
use the Modeline settings in
|
|
your XF86Config file directly
|
|
when running X. Using the
|
|
Matrox frame buffer seems to
|
|
force the X server to drop all
|
|
of those. So you can only have
|
|
the one
|
|
("<code>default</code>")
|
|
setting at a time (the same
|
|
one you had in text
|
|
mode).</para></listitem>
|
|
|
|
<listitem><para>The XF86_FBDev driver is
|
|
unaccelerated. However, there
|
|
are patches for accelerated
|
|
Matrox support at <ulink
|
|
url="http://www.in-berlin.de/User/kraxel/xfree86/"></ulink></para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<section><title>Getting "<code>init level 5</code>"
|
|
(i.e. <code>xdm</code> /
|
|
<code>gdm</code>) to work</title>
|
|
|
|
<para>I have not yet figured out a way to boot
|
|
with init level 5 with a dual monitor
|
|
configuration (and actually have the
|
|
server on either the second montior or
|
|
both). While it seems easy enough to
|
|
add a line to the gdm/xdm Xservers
|
|
file, the constraint that you must start
|
|
the X server from the same frame buffer
|
|
prevents the obvious solution from
|
|
working. If anyone finds a way please
|
|
e-mail me and I'll add it here.</para>
|
|
</section>
|
|
|
|
<section><title>Using the "<code>x2x</code>" program</title>
|
|
|
|
<para>There's a nice little program called
|
|
<code>x2x</code> that will switch X
|
|
servers for you when you get to the
|
|
edge of the screen. Last known home
|
|
for this program was: <ulink
|
|
url="http://ftp.digital.com/pub/DEC/SRC/x2x/"></ulink>
|
|
It's also an optional Debian package.
|
|
I haven't tried it yet but some users
|
|
have reported success.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Other useful commands</title>
|
|
|
|
<para>These are existing linux commands that
|
|
are worth remembering when dealing with
|
|
a multi-head configuration (especially
|
|
in writing scripts).</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem><para>"<code>chvt</code>"
|
|
will allow you to
|
|
switch between virtual
|
|
terminals.</para></listitem>
|
|
<listitem><para>"<code>openvt</code>"
|
|
start a program on a
|
|
new virtual terminal
|
|
(VT).</para></listitem>
|
|
<listitem><para>"<code>tty</code>" will
|
|
report the name of the
|
|
current
|
|
terminal.</para></listitem>
|
|
|
|
</itemizedlist>
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Appendix A. Octave "<code>ctmodem.m</code>" script</title>
|
|
|
|
<para>(note the bpp settings)</para>
|
|
|
|
<para><literallayout><code>
|
|
#!/usr/bin/octave -q
|
|
bpp = 16;
|
|
DCF = sscanf(argv(1,:), "%f");
|
|
HR = sscanf(argv(2,:), "%f");
|
|
SH1 = sscanf(argv(3,:), "%f");
|
|
SH2 = sscanf(argv(4,:), "%f");
|
|
HFL = sscanf(argv(5,:), "%f");
|
|
VR = sscanf(argv(6,:), "%f");
|
|
SV1 = sscanf(argv(7,:), "%f");
|
|
SV2 = sscanf(argv(8,:), "%f");
|
|
VFL = sscanf(argv(9,:), "%f");
|
|
pixclock = 1000000 / DCF;
|
|
left_margin = HFL - SH2;
|
|
right_margin = SH1 - HR;
|
|
hsync_len = SH2 - SH1;
|
|
|
|
# 3) vertical timings:
|
|
upper_margin = VFL - SV2;
|
|
lower_margin = SV1 - VR;
|
|
vsync_len = SV2 - SV1;
|
|
|
|
RR = DCF / (HFL * VFL) *1e6;
|
|
HSF = DCF / HFL * 1e3;
|
|
printf("mode \"%dx%d\"\n",HR,VR);
|
|
printf(" # D: %3.2f MHz, H: %3.2f kHz, V: %2.2f Hz\n", DCF, HSF, RR);
|
|
printf(" geometry %d %d %d %d %d\n", HR, VR, HR, VR, bpp);
|
|
printf(" timings %d %d %d %d %d %d %d\n", ...
|
|
pixclock, left_margin, right_margin, ...
|
|
upper_margin, lower_margin, ...
|
|
hsync_len, vsync_len);
|
|
printf("endmode\n");
|
|
</code></literallayout></para>
|
|
|
|
</section>
|
|
|
|
<section><title>Appendix B. Bourne Shell "<code>cvtfile</code>"
|
|
script</title>
|
|
|
|
<para>(This calls the octave script
|
|
"<code>cvtmode</code>")</para>
|
|
|
|
<para><literallayout><code>
|
|
#!/bin/sh
|
|
|
|
# Shell script to convert XF86Config file to fb.modes file.
|
|
# Uses octave script cvtmode.m
|
|
|
|
if [ -z $1 ]; then
|
|
FILE=/etc/X11/XF86Config
|
|
else
|
|
FILE=$1
|
|
fi
|
|
|
|
i=1
|
|
LEN=`grep Modeline $FILE | wc -l`
|
|
while expr $i \< $LEN > /dev/null ;
|
|
do
|
|
CURLINE=`grep Modeline $FILE | cut -d'"' -f 3-20 | head -$i | tail -1 `
|
|
./cvtmode.m $CURLINE
|
|
echo " "
|
|
i=`expr $i + 1`
|
|
done
|
|
</code></literallayout></para>
|
|
</section>
|
|
</section>
|
|
|
|
<section><title>Using / Changing Fonts</title>
|
|
|
|
<para>To get the capability to change fonts, you need kbd-0.99.
|
|
You may obtain this from <ulink
|
|
url="ftp://ftp.win.tue.nl/pub/linux/utils/kbd"></ulink></para>
|
|
|
|
<para>One advantage of downloading and installing kbd-0.99 is
|
|
that you will be able to load international fonts (i.e
|
|
Euro symbol) into your console device. On my keyboard I
|
|
can have three symbols on my keyboard, the dollar sign,
|
|
the English pound sign and the Euro sign.</para>
|
|
</section>
|
|
|
|
<section><title>Changing Console Modes</title>
|
|
|
|
<para>To get the capability to change modes (i.e 640x480,
|
|
800x800 etc), you need fbset (currently
|
|
fbset-19990118.tar.gz) - you may ftp it from <ulink
|
|
url="http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz"></ulink>.
|
|
This comes with a full set of instructions on how to
|
|
operate this.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Setting up the X11 FBdev driver</title>
|
|
|
|
<para>If you are not using XFree86 3.3.3.1 or later, you are
|
|
urged to upgrade to XFree86 3.3.3.1, as it includes a
|
|
FBdev X driver for framebuffer devices. Otherwise,
|
|
follow the steps below to either download or build your
|
|
own FBdev driver for older XFree86 versions such as
|
|
3.3.2, 3.3.3 etc.</para>
|
|
|
|
<para>Go to <ulink url="http://www.xfree86.org"></ulink>, and
|
|
download the latest XServer sources archive, unpack,
|
|
and configure the drivers, following these
|
|
steps:</para>
|
|
|
|
<itemizedlist> <listitem><para>Edit
|
|
<code>xc/config/cf/xf86site.def</code>,
|
|
uncomment the <code>#define</code> for
|
|
<code>XF68FBDevServer</code></para></listitem>
|
|
<listitem><para>Comment out <emphasis>all</emphasis>
|
|
references to
|
|
<code>FB_VISUAL_STATIC_DIRECTCOLOR</code>,
|
|
as those are bogus and are not used any
|
|
more. If you are using XFree86 3.3.3.1,
|
|
there is no need to do this step as
|
|
this has all been
|
|
removed.</para></listitem>
|
|
<listitem><para>Edit
|
|
<code>xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c</code>,
|
|
and change <code>K_RAW</code> to
|
|
<code>K_MEDIUMRAW</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>And then build the driver. Don't worry about the m68k
|
|
references, it supports x86 platforms. Then build the
|
|
whole thing - it'll take a long time though as it's a
|
|
large source tree.</para>
|
|
|
|
<para>Alternatively, if you don't have the time to spare, you
|
|
can obtain the binaries from the sites below. Please
|
|
note that these are 'unofficial' builds and you use
|
|
them at your risk.</para>
|
|
|
|
<para>For libc5, use the one at: <ulink
|
|
url="http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.gz"></ulink>.
|
|
For glibc2, download from these URLs (<ulink
|
|
url="http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.libc6.gz"></ulink>
|
|
or <ulink url="
|
|
http://pobox.com/~brion/linux/fbxserver.html"></ulink></para>
|
|
|
|
<para>There have been reports that X11 is non functional on
|
|
certain graphic cards with this vesafb feature enabled,
|
|
if this is happening, try the new XF86_FBdev driver for
|
|
X11.</para>
|
|
|
|
<para>This driver, along with vesafb can also help run X11 in
|
|
higher graphic resolutions with certain graphic
|
|
chipsets which are not supported by any of the current
|
|
X11 drivers. Examples are Matrox G200 et. al.</para>
|
|
|
|
<para>To configure the XF86_FBdev driver with your X11 system,
|
|
you'll need to edit your XF86Config for the
|
|
following:</para>
|
|
|
|
<para><literallayout><code>
|
|
Section "Screen"
|
|
Driver "FBDev"
|
|
Device "Primary Card"
|
|
Monitor "Primary Monitor"
|
|
SubSection "Display"
|
|
Modes "default"
|
|
EndSubSection
|
|
EndSection
|
|
</code></literallayout></para>
|
|
|
|
<para>You'll also need to set XkbDisable in the keyboard
|
|
section as well, or invoke the XF86_FBDev server with
|
|
the '<code>-kb</code>' option to set up your keyboard
|
|
so it works properly. If you forget to set XkbDisable,
|
|
you will have to put the following lines in your
|
|
<code>.Xmodmap</code> to straighten out the keyboard
|
|
mappings. Alternatively, you can edit your xkb to
|
|
reflect the list below.</para>
|
|
|
|
<para><emphasis>This is fixed in XFree86 3.3.3.1, and it is a
|
|
good idea to upgrade to this version anyway
|
|
because there are quite a few bug fixes, and
|
|
also, it includes FBDev as one of the drvers,
|
|
as I've mentioned previously.</emphasis></para>
|
|
|
|
<para><literallayout><code>
|
|
! Keycode settings required
|
|
keycode 104 = KP_Enter
|
|
keycode 105 = Control_R
|
|
keycode 106 = KP_Divide
|
|
keycode 108 = Alt_R Meta_R
|
|
keycode 110 = Home
|
|
keycode 111 = Up
|
|
keycode 112 = Prior
|
|
keycode 113 = Left
|
|
keycode 114 = Right
|
|
keycode 115 = End
|
|
keycode 116 = Down
|
|
keycode 117 = Next
|
|
keycode 118 = Insert
|
|
keycode 119 = Delete
|
|
</code></literallayout></para>
|
|
|
|
<para>You may need to do some fiddling around with this (try
|
|
copying the original definition from the original X11
|
|
driver that you were using and editing the name of the
|
|
driver to FBDev), but basically this is what you need
|
|
to do to use the vesafb X11 driver.</para>
|
|
|
|
<para>Hopefully the X11 problems with supported graphic cards
|
|
will be fixed in future releases.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>How do I convert XFree86 mode-lines into framebuffer device timings?</title>
|
|
|
|
<para>If you have XFree86 (X11) installed on your machine, and
|
|
you can use it successfully, it is a simple matter to
|
|
convert the mode-lines in your XF86Config file to the
|
|
required timings needed by the framebuffer
|
|
devices.</para>
|
|
|
|
<para>The framebuffer device requires the following
|
|
fields:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>pixclock</code> - pixel clock in
|
|
pico seconds</para></listitem>
|
|
<listitem><para><code>left_margin</code> - time between
|
|
sync to display</para></listitem>
|
|
<listitem><para><code>right_margin</code> - time
|
|
between display to
|
|
sync</para></listitem>
|
|
<listitem><para><code>upper_margin</code> - time
|
|
between sync to
|
|
display</para></listitem>
|
|
<listitem><para><code>lower_margin</code> - time
|
|
between display to
|
|
sync</para></listitem>
|
|
<listitem><para><code>hsync_len</code> - horizontal
|
|
sync length </para></listitem>
|
|
<listitem><para><code>vsync_len</code> - vertical sync
|
|
length</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>An XFree86 mode line has the following fields:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>Modeline "1280x1024" DCF HR SH1
|
|
SH2 HFL VR SV1 SV2
|
|
VFL</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>It is necessary to do some simple calculations to
|
|
translate the XF86 mode-lines into a set of framebuffer
|
|
device timings. As an example, we shall examine how to
|
|
convert a mode-line taken from my XF86Config file:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>Modeline "1280x1024" 110.0 1280
|
|
1328 1512 1712 1024 1025 1028
|
|
1054</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>First, calculate the required pixclock rate. XFree86 uses
|
|
megahertz whilst framebuffer devices uses picoseconds
|
|
(Why, I don't know). Divide one million by DCF. For
|
|
example: <code>1,000,000 / 110.0 =
|
|
9090.9091</code></para>
|
|
|
|
<para>Now we need to calculate the horizontal timings:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>left_margin = HFL -
|
|
SH2</code></para></listitem>
|
|
<listitem><para><code>right_margin = SH1 -
|
|
HR</code></para></listitem>
|
|
<listitem><para><code>hsync_len = SH2 -
|
|
SH1</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>In our example, this would be:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>left_margin = 1712 - 1512 =
|
|
200</code></para></listitem>
|
|
<listitem><para><code>right_margin = 1328 - 1280 =
|
|
48</code></para></listitem>
|
|
<listitem><para><code>hsync_len = 1512 - 1328 =
|
|
184</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>And now we need to calculate the vertical timings.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>upper_margin = VFL -
|
|
SV2</code></para></listitem>
|
|
<listitem><para><code>lower_margin = SV1 -
|
|
VR</code></para></listitem>
|
|
<listitem><para><code>vsync_len = SV2 -
|
|
SV1</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>For our example, this would be:</para>
|
|
<itemizedlist>
|
|
<listitem><para><code>upper_margin = 1054 - 1028 =
|
|
26</code></para></listitem>
|
|
<listitem><para><code>lower_margin = 1025 - 1024 =
|
|
1</code></para></listitem>
|
|
<listitem><para><code>vsync_len = 1028 - 1025 =
|
|
3</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Now we can use this information to set up the framebuffer
|
|
for the desired mode. For example, for the matroxfb
|
|
framebuffer driver, it requires the following:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>video=matrox:xres:<>,yres:<>,depth:<>,left:<>,right:<>,hslen:<>,upper:<>,lower:<>,vslen:<></code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>I put into my <code>/etc/lilo.conf</code> the following line:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para><code>append =
|
|
"video=matroxfb:xres:1280,yres:1024,depth:32,left:200,right:48,hslen:184,upper:26,lower:0,vslen:3"</code></para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Note that in this case the pixel clock isn't used. It's
|
|
only necessary if you don't like the default pixel
|
|
clock rates. You can supply this as a parameter as
|
|
well. Setting the pixclock is documented in other parts
|
|
of this HOWTO.</para>
|
|
</section>
|
|
|
|
<section><title>Changing the Linux Logo</title>
|
|
|
|
<para>It can be customised by changing the file
|
|
<code>linux_logo.h</code> in <code>include/linux</code>
|
|
directory. It is a C header file, and pretty hard to
|
|
change by hand, however there is a plugin available for
|
|
Gimp from <ulink
|
|
url="http://registry.gimp.org/detailview.phtml?plugin=Linux+Logo"></ulink>
|
|
that will create one for you. All you need is a picture
|
|
80 pixels in height and width, with less than 224
|
|
colours. You can either let Gimp create the three
|
|
varieties (2, 16, 224 colours), or create them yourself
|
|
and use them with the plug-in. It will ask you where
|
|
you want to store the file, and if you are game you can
|
|
put it into
|
|
<code>($SRCDIR)/include/linux/linux_logo.h</code>. Once
|
|
that is finished all you need to do is recompile the
|
|
kernel as usual, reboot, and if framebuffer is working,
|
|
you will see your new logo upon bootup.</para>
|
|
|
|
</section>
|
|
|
|
<section><title>Looking for further information</title>
|
|
|
|
<para>For those of you interested in working with the
|
|
framebuffer drivers, point your web browser at <ulink
|
|
url="http://www.linux-fbdev.org"></ulink> for
|
|
more information on programming.</para>
|
|
|
|
<para>Parlez-vous Francais? There is a translation at <ulink
|
|
url="http://www.freenix.org/unix/linux/HOWTO/mini/Vesafb.html"></ulink></para>
|
|
|
|
</section>
|
|
</article>
|
|
|