mirror of https://github.com/tLDP/LDP
1661 lines
64 KiB
Plaintext
1661 lines
64 KiB
Plaintext
<!doctype linuxdoc system>
|
|
|
|
<!-- Framebuffer HOWTO -->
|
|
|
|
<article>
|
|
|
|
<title>Framebuffer HOWTO
|
|
<author>Alex Buell, <tt/alex.buell@tahallah.clara.co.uk/
|
|
<date>v1.2, 27 Feb 2000
|
|
<abstract>
|
|
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.
|
|
</abstract>
|
|
|
|
<toc>
|
|
|
|
<!-- HOWTO proper -->
|
|
<sect>History
|
|
<p>
|
|
Revision history
|
|
</p><p>
|
|
19990607 - Release of 1.0
|
|
</p><p>
|
|
19990722 - Release of 1.1
|
|
</p><p>
|
|
20000222 - Release of 1.2
|
|
</p>
|
|
|
|
<sect>Contributors
|
|
<p>
|
|
Thanks go to these people listed below who helped improve the Framebuffer HOWTO.
|
|
|
|
<itemize>
|
|
<item>Jeff Noxon <tt/jeff@planetfall.com/
|
|
<item>Francis Devereux <tt/f.devereux@cs.ucl.ac.uk/
|
|
<item>Andreas Ehliar <tt/ehliar@futurniture.se/
|
|
<item>Martin McCarthy <tt/marty@ehabitat.demon.co.uk/
|
|
<item>Simon Kenyon <tt/simon@koala.ie/
|
|
<item>David Ford <tt/david@kalifornia.com/
|
|
<item>Chris Black <tt/cblack@cmpteam4.unil.ch/
|
|
<item>N Becker <tt/nbecker@fred.net/
|
|
<item>Bob Tracy <tt/rct@gherkin.sa.wlk.com/
|
|
<item>Marius Hjelle <tt/marius.hjelle@roman.uib.no/
|
|
<item>James Cassidy <tt/jcassidy@misc.dyn.ml.org/
|
|
<item>Andreas U. Trottmann <tt/andreas.trottmann@werft22.com/
|
|
<item>Lech Szychowski <tt/lech7@lech.pse.pl/
|
|
<item>Aaron Tiensivu <tt/tiensivu@pilot.msu.edu/
|
|
<item>Jan-Frode Myklebust for his info on permedia cards <tt/janfrode@ii.uib.no/
|
|
<item>Many others too numerous to add, but thanks!
|
|
</itemize>
|
|
|
|
Thanks go to Rick Niles <tt/frederick.a.niles@gsfc.nasa.gov/ who has very kindly
|
|
handed over his Multi-Head Mini-HOWTO for inclusion in this HOWTO.
|
|
|
|
Thanks to these people listed below who built libc5/glibc2 versions of the
|
|
XF86_FBdev X11 framebuffer driver for X11 on Intel platforms:
|
|
|
|
<itemize>
|
|
<item>Brion Vibber <tt/brion@pobox.com/
|
|
<item>Gerd Knorr <tt/kraxel@cs.tu-berlin.de/
|
|
</itemize>
|
|
|
|
and of course the authors of the framebuffer devices:
|
|
|
|
<itemize>
|
|
<item>Martin Schaller - original author of the framebuffer concept
|
|
<item>Roman Hodek <tt/Roman.Hodek@informatik.uni-erlangen.de/
|
|
<item>Andreas Schwab <tt/schwab@issan.informatik.uni-dortmund.de/
|
|
<item>Guenther Kelleter
|
|
<item>Geert Uytterhoeven <tt/Geert.Uytterhoeven@cs.kuleuven.ac.be/
|
|
<item>Roman Zippel <tt/roman@sodom.obdg.de/
|
|
<item>Pavel Machek <tt/pavel@atrey.karlin.mff.cuni.cz/
|
|
<item>Gerd Knorr <tt/kraxel@cs.tu-berlin.de/
|
|
<item>Miguel de Icaza <tt/miguel@nuclecu.unam.mx/
|
|
<item>David Carter <tt/carter@compsci.bristol.ac.uk/
|
|
<item>William Rucklidge <tt/wjr@cs.cornell.edu/
|
|
<item>Jes Sorensen <tt/jds@kom.auc.dk/
|
|
<item>Sigurdur Asgeirsson
|
|
<item>Jeffrey Kuskin <tt/jsk@mojave.stanford.edu/
|
|
<item>Michal Rehacek <tt/michal.rehacek@st.mff.cuni.edu/
|
|
<item>Peter Zaitcev <tt/zaitcev@lab.ipmce.su/
|
|
<item>David S. Miller <tt/davem@dm.cobaltmicro.com/
|
|
<item>Dave Redman <tt/djhr@tadpole.co.uk/
|
|
<item>Jay Estabrook
|
|
<item>Martin Mares <tt/mj@ucw.cz/
|
|
<item>Dan Jacobowitz <tt/dan@debian.org/
|
|
<item>Emmanuel Marty <tt/core@ggi-project.org/
|
|
<item>Eddie C. Dost <tt/ecd@skynet.be/
|
|
<item>Jakub Jelinek <tt/jj@ultra.linux.cz/
|
|
<item>Phil Blundell <tt/philb@gnu.org/
|
|
<item>Anyone else, stand up and be counted. :o)
|
|
</itemize>
|
|
|
|
<sect>What is a framebuffer device?
|
|
<p>
|
|
|
|
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]
|
|
|
|
<sect>What advantages does framebuffer devices have?
|
|
<p>
|
|
|
|
Penguin logo. :o) Seriously, the major advantage of the framebuffer drives
|
|
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 Intel
|
|
platform had console drivers completely different from the other console
|
|
drivers for other platforms. With the introduction of 2.1.109 all this
|
|
has changed for the better, and introduced more uniform handling of the
|
|
console under the Intel platforms and also introduced true bitmapped
|
|
graphical consoles bearing the Penguin logo on Intel 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 v0.9.x kernel port for m68k
|
|
platforms does have the framebuffer device support included.
|
|
|
|
<em/With the release of the 2.2.x kernel, 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 Intel platform./
|
|
|
|
<itemize>
|
|
<item>0.9.x (m68k) - introduced m68k framebuffer devices. Note that m68k 0.9.x
|
|
is functionally equivalent to Intel 1.0.9 (plus 1.2.x enhancements)
|
|
<item>2.1.107 - introduced Intel framebuffer/new console devices and
|
|
added generic support, without scrollback buffer support.
|
|
<item>2.1.113 - scrollback buffer support added to vgacon.
|
|
<item>2.1.116 - scrollback buffer support added to vesafb.
|
|
<item>2.2.x - includes matroxfb(Matrox) and atyfb(ATI).
|
|
</itemize>
|
|
|
|
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:
|
|
|
|
<itemize>
|
|
<item><tt/video=xxx:off/ - disable probing for a particular framebuffer
|
|
device
|
|
<item><tt/video=map:octal-number/ - maps the virtual consoles (VCs) to
|
|
framebuffer (FB) devices
|
|
<itemize>
|
|
<item><tt/video=map:01/ will map VC0 to FB0, VC1 to FB1, VC2 to FB0, VC3
|
|
to FB1..
|
|
<item><tt/video=map:0132/ will map VC0 to FB0, VC1 to FB1, VC2 to FB3, VC4
|
|
to FB2, VC5 to FB0..
|
|
</itemize>
|
|
</itemize>
|
|
|
|
Normally framebuffer devices are probed for in the order specified in the
|
|
kernel, but by specifying the <tt/video=xxx/ option, you can add the
|
|
specific framebuffer device you want probed before the others specified in
|
|
the kernel.
|
|
|
|
<sect>Using framebuffer devices on Intel platforms
|
|
|
|
<sect1>What is vesafb?
|
|
<p>
|
|
|
|
Vesafb is a framebuffer driver for Intel architecture that works with
|
|
VESA 2.0 compliant graphic cards. It is closely related to the framebuffer
|
|
device drivers in the kernel.
|
|
|
|
vesafb is a display driver that enables the use of graphical modes on your
|
|
Intel 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)
|
|
|
|
Unfortunately, you can not use vesafb successfully with VESA 1.2 cards.
|
|
This is because these 1.2 cards do not use <em/linear/ 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.
|
|
|
|
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 in cojunction 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.
|
|
|
|
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
|
|
<verb>ftp://ccssu.crimea.ua/pub/linux/kernel/v2.2/unofficial/s3new.diff.gz</verb>
|
|
|
|
<sect1>How do I activate the vesafb drivers?
|
|
<p>
|
|
Assuming you are using menuconfig, you will need to do the following
|
|
steps:
|
|
|
|
If your processor (on Intel 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.
|
|
|
|
<em/IMPORTANT: For 2.1.x kernels, go into the Code Maturity Level menu,
|
|
and enable the prompt for development and/<em/or incomplete drivers.
|
|
This is no longer necessary for the 2.2.x kernels./
|
|
|
|
Go into the Console Drivers menu, and enable the following:
|
|
|
|
<itemize>
|
|
<item>VGA Text Console
|
|
<item>Video Selection Support
|
|
<item>Support for frame buffer devices (experimental)
|
|
<item>VESA VGA Graphic console
|
|
<item>Advanced Low Level Drivers
|
|
<item>Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed pixel
|
|
drivers
|
|
</itemize>
|
|
|
|
VGA Chipset Support (text only) - vgafb - 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 (fbcon)
|
|
instead. VGA Character/Attributes is only used with VGA Chipset
|
|
Support, and doesn't need to be selected.
|
|
|
|
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.
|
|
|
|
There is also the option to compile in fonts into memory, but this isn't
|
|
really necessary, and you can always use kbd-0.99's (see section on fonts)
|
|
setfont utility to change fonts by loading fonts into the console device.
|
|
|
|
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]
|
|
|
|
You'll need to create the framebuffer device in /dev. You need one per
|
|
framebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0
|
|
for the first one. Subsequent ones would be in multiples of 32, so for example
|
|
to create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so on
|
|
up to the eighth framebuffer device (mknod /dev/fb7 c 29 224)
|
|
|
|
Then rebuild the kernel, modify /etc/lilo.conf to include the VGA=ASK
|
|
parameter, and run lilo, this is required in order for you to be able to
|
|
select the modes you wish to use.
|
|
|
|
Here's a sample LILO configuration (taken from my machine)
|
|
|
|
<verb>
|
|
# 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
|
|
</verb>
|
|
|
|
Reboot the kernel, and as a simple test, try entering 0301 at the VGA
|
|
prompt (this will give you 640x480 @ 256), and you should be able to see a
|
|
cute little Penguin logo.
|
|
|
|
Note, that at the VGA prompt, you're required to type in the number in
|
|
the format of "0" plus the 3 digit figure, and miss out the 'x'. This isn't
|
|
necessary if you're using LILO.
|
|
|
|
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 "VGA=x" parameter in lilo.conf. 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
|
|
"VGA=0x307"), and re-run lilo. That's all there it is to it.
|
|
For further references, read the LoadLin/LILO HOWTOs.
|
|
|
|
<em/NOTE!/ vesafb does not enable scrollback buffering as a default. You
|
|
will need to pass to the kernel the option to enable it. Use
|
|
video=vesa:ypan or video=vesa:ywrap to activate it. Both does the same
|
|
thing, but in different ways. ywrap is a lot faster than ypan but may not
|
|
work on slightly broken VESA 2.0 graphic cards. ypan is slower than ywrap
|
|
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.
|
|
|
|
<sect1>What VESA modes are available to me?
|
|
|
|
<p>
|
|
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.
|
|
|
|
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)
|
|
|
|
<verb>
|
|
Colours 640x400 640x480 800x600 1024x768 1152x864 1280x1024 1600x1200
|
|
--------+--------------------------------------------------------------
|
|
4 bits | ? ? 0x302 ? ? ? ?
|
|
8 bits | 0x300 0x301 0x303 0x305 0x161 0x307 0x31C
|
|
15 bits | ? 0x310 0x313 0x316 0x162 0x319 0x31D
|
|
16 bits | ? 0x311 0x314 0x317 0x163 0x31A 0x31E
|
|
24 bits | ? 0x312 0x315 0x318 ? 0x31B 0x31F
|
|
32 bits | ? ? ? ? 0x164 ?
|
|
</verb>
|
|
|
|
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 with a
|
|
32 bit PCI/VLB/EISA bus.
|
|
|
|
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.
|
|
|
|
<sect1>Got a Matrox card?
|
|
<p>
|
|
|
|
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:
|
|
|
|
You might want to upgrade the Matrox BIOS though, you can download the BIOS
|
|
upgrade from <verb>http://www.matrox.com/mgaweb/drivers/ftp_bios.htm</verb> Beware that
|
|
you will need DOS to do this.
|
|
|
|
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]
|
|
|
|
Go into the Console Drivers menu, and enable the following:
|
|
|
|
<itemize>
|
|
<item>VGA Text Console
|
|
<item>Video Selection Support
|
|
<item>Support for frame buffer devices (experimental)
|
|
<item>Matrox Acceleration
|
|
<item>Select the following depending on the card that you have
|
|
<itemize>
|
|
<item>Millennium I/II support
|
|
<item>Mystique support
|
|
<item>G100/G200 support
|
|
</itemize>
|
|
<item>Enable Multihead Support if you want to use more than one Matrox card
|
|
<item>Advanced Low Level Drivers
|
|
<item>Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed pixel
|
|
drivers
|
|
</itemize>
|
|
|
|
Rebuild your kernel. Then you will need to modify your lilo.conf file to
|
|
enable the Matroxfb device. The quickest and simplest way is re-use mine.
|
|
|
|
<verb>
|
|
# 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
|
|
</verb>
|
|
|
|
Lastly, you'll need to create the framebuffer device in /dev. You need one per
|
|
framebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0
|
|
for the first one. Subsequent ones would be in multiples of 32, so for example
|
|
to create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so on
|
|
up to the eight framebuffer device (mknod /dev/fb7 c 29 224)
|
|
|
|
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!
|
|
|
|
<sect1>Got a Permedia card?
|
|
<p>
|
|
|
|
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:
|
|
|
|
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]
|
|
|
|
Go into the Console Drivers menu and select the following:
|
|
|
|
<itemize>
|
|
<item>VGA Text Console
|
|
<item>Video Selection Support
|
|
<item>Support for frame buffer devices (experimental)
|
|
<item>Permedia2 support (experimental)
|
|
<item>Generic Permedia2 PCI board support
|
|
<item>Advanced Low Level Drivers
|
|
<item>Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed pixel drivers
|
|
<item>Optionally, select the following, if you wish to use the compiled in fonts
|
|
<itemize>
|
|
<item>Select compiled-in fonts
|
|
<item>Select Sparc console 12x22 font
|
|
</itemize>
|
|
</itemize>
|
|
|
|
Rebuild your kernel. Then you will need to modify your lilo.conf file to
|
|
enable the pm2fb device. The quickest and simplest way is re-use the following
|
|
|
|
<verb>
|
|
# 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
|
|
</verb>
|
|
|
|
The line "pm2fb:mode:1024x768-75,font:SUN12x22,ypan" indicates you are selecting
|
|
a 1024x768 mode at 75Hz, with the SUN12x22 font selected (if you did select it),
|
|
including ypan for scrollback support. You may select other modes if you desire.
|
|
|
|
Lastly, you'll need to create the framebuffer device in /dev. You need one per
|
|
framebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0
|
|
for the first one. Subsequent ones would be in multiples of 32, so for example
|
|
to create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so on
|
|
up to the eight framebuffer device (mknod /dev/fb7 c 29 224)
|
|
|
|
For more information on the other features of the Permedia framebuffer driver,
|
|
point your browser at: <verb>http://www.cs.unibo.it/~nardinoc/pm2fb/index.html</verb>
|
|
|
|
video=pm2fb:[option[,option[,option...]]]
|
|
|
|
where option is one of the following
|
|
|
|
<itemize>
|
|
<item>off to disable the driver.
|
|
<item>mode:resolution to set the console resolution. The modes have been
|
|
taken from the fb.modes.ATI file in Geert's fbset package. The depth for
|
|
all the modes is 8bpp. This is the list of the available modes:
|
|
<itemize>
|
|
<item>640x480-(60,72,75,90,100)
|
|
<item>800x600-(56,60,70,72,75,90,100)
|
|
<item>1024x768-(60,70,72,75,90,100,illo) illo=80KHz 100Hz
|
|
<item>1152x864-(60,70,75,80)
|
|
<item>1280x1024-(60,70,74,75)
|
|
<item>1600x1200-(60,66,76)
|
|
</itemize>
|
|
<item>The default resolution is 640x480-60.
|
|
<item>font:font name to set the console font. Example: font:SUN12x22
|
|
<item> ypan sets the current virtual height as big as video memory size permits.
|
|
<item>oldmem this option is for CybervisionPPC users only. Specify this if
|
|
your board has Fujitsu SGRAMs mounted on (all CVisionPPCs before 30-Dec-1998).
|
|
<item>virtual (temporary) specify this if the kernel remaps the PCI regions
|
|
on your platform.
|
|
</itemize>
|
|
|
|
<sect1>Got a ATI card?
|
|
<p>
|
|
|
|
[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)
|
|
|
|
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:
|
|
|
|
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]
|
|
|
|
Go into the Console Drivers menu and select the following:
|
|
|
|
<itemize>
|
|
<item>VGA Text Console
|
|
<item>Video Selection Support
|
|
<item>Support for frame buffer devices (experimental)
|
|
<item>ATI Mach64 display support
|
|
<item>Advanced Low Level Drivers
|
|
<item>Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed pixel drivers
|
|
<item>Optionally, select the following, if you wish to use the compiled in fonts
|
|
<itemize>
|
|
<item>Select compiled-in fonts
|
|
<item>Select Sparc console 12x22 font
|
|
</itemize>
|
|
</itemize>
|
|
|
|
Rebuild your kernel. Then you will need to modify your lilo.conf file to
|
|
enable the atyfb device. The quickest and simplest way is re-use the following
|
|
|
|
<verb>
|
|
# 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
|
|
</verb>
|
|
|
|
The line "atyfb:mode:1024x768,font:SUN12x22" indicates you are selecting
|
|
a 1024x768 mode.
|
|
|
|
Lastly, you'll need to create the framebuffer device in /dev. You need one per
|
|
framebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0
|
|
for the first one. Subsequent ones would be in multiples of 32, so for example
|
|
to create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so on
|
|
up to the eight framebuffer device (mknod /dev/fb7 c 29 224)
|
|
|
|
video=atyfb:[option[,option[,option...]]]
|
|
|
|
where option is one of the following
|
|
|
|
<itemize>
|
|
<item>font:STRING selects the built-in font (compiled into the kernel)
|
|
<item>noblink Turns off blinking
|
|
<item>noaccel Disables acceleration
|
|
<item>vram:ULONG Tells the atyfb driver how much memory you have
|
|
<item>pll:ULONG Unknown
|
|
<item>mclk:ULONG Unknown
|
|
<item>vmode:ULONG Unknown
|
|
<item>cmode:ULONG - sets depth - 0, 8, 15, 16, 24 and 32
|
|
</itemize>
|
|
|
|
<sect1>Which graphic cards are VESA 2.0 compliant?
|
|
<p>
|
|
This lists all the graphic cards that are known to work with the vesafb
|
|
device:
|
|
|
|
<itemize>
|
|
<item>ATI PCI VideoExpression 2MB (max. 1280x1024 @ 8bit)
|
|
<item>ATI PCI All-in-Wonder
|
|
<item>Matrox Millennium PCI - BIOS v3.0
|
|
<item>Matrox Millennium II PCI - BIOS v1.5
|
|
<item>Matrox Millennium II AGP - BIOS v1.4
|
|
<item>Matrox Millennium G200 AGP - BIOS v1.3
|
|
<item>Matrox Mystique & Mystique 220 PCI - BIOS v1.8
|
|
<item>Matrox Mystique G200 AGP - BIOS v1.3
|
|
<item>Matrox Productiva G100 AGP - BIOS v1.4
|
|
<item>All Riva 128 based cards
|
|
<item>Diamond Viper V330 PCI 4MB
|
|
<item>Genoa Phantom 3D/S3 ViRGE/DX
|
|
<item>Hercules Stingray 128/3D with TV output
|
|
<item>Hercules Stingray 128/3D without TV output - needs BIOS upgrade
|
|
(free from support@hercules.com)
|
|
<item>SiS 6326 PCI/AGP 4MB
|
|
<item>STB Lightspeed 128 (Nvida Riva 128 based) PCI
|
|
<item>STB Velocity 128 (Nvida Riva 128 based) PCI
|
|
<item>Jaton Video-58P ET6000 PCI 2MB-4MB (max. 1600x1200 @ 8bit)
|
|
<item>Voodoo2 2000
|
|
</itemize>
|
|
|
|
This list is composed of on-board chipsets on systems' motherboards:
|
|
|
|
<itemize>
|
|
<item>Trident Cyber9397
|
|
<item>SiS 5598
|
|
</itemize>
|
|
|
|
This list below blacklists graphic cards that doesn't work with the vesafb
|
|
device:
|
|
|
|
<itemize>
|
|
<item>TBA
|
|
</itemize>
|
|
|
|
<sect1> Can I make vesafb as a module?
|
|
<p>
|
|
|
|
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
|
|
<em/modprobed/. It's probably a lot wiser to leave it in the kernel, for
|
|
these cases when there are booting problems.
|
|
|
|
<sect1>How do I modify the cursor?
|
|
<p>
|
|
|
|
[Taken from VGA-softcursor.txt - thanks Martin Mares!]
|
|
|
|
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 #define TRIDENT_GLITCH in
|
|
drivers/char/ vga.c). 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.
|
|
|
|
The cursor appearance is controlled by a <verb><ESC>[?1;2;3c</verb> escape
|
|
sequence where 1, 2 and 3 are parameters described below. If you omit any
|
|
of them, they will default to zeroes.
|
|
|
|
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.
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
To get normal blinking underline, use: echo -e '\033[?2c'
|
|
To get blinking block, use: echo -e '\033[?6c'
|
|
To get red non-blinking block, use: echo -e '\033[?17;0;64c'
|
|
|
|
|
|
<sect>Using framebuffer devices on Atari m68k platforms
|
|
<p>
|
|
|
|
This section describes framebuffer options on Atari m68k platforms.
|
|
|
|
<sect1>What modes are available on Atari m68k platforms?
|
|
<p>
|
|
|
|
<verb>
|
|
Colours 320x200 320x480 640x200 640x400 640x480 896x608 1280x960
|
|
--------+---------------------------------------------------------
|
|
1 bit | sthigh vga2 falh2 tthigh
|
|
2 bits | stmid vga4
|
|
4 bits | stlow ttmid/vga16 falh16
|
|
8 bits | ttlow vga256
|
|
</verb>
|
|
|
|
<tt/ttlow, ttmid and tthigh/ are only used by the TT, whilst <tt/vga2,
|
|
vga4, vga15, vga256, falh3 and falh16/ are only used by the Falcon.
|
|
|
|
When used with the kernel option <tt/video=xxx/, 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:
|
|
|
|
<itemize>
|
|
<item><tt/ttmid/
|
|
<item><tt/tthigh/
|
|
<item><tt/vga16/
|
|
<item><tt/sthigh/
|
|
<item><tt/stmid/
|
|
</itemize>
|
|
|
|
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, <tt/video=vga16/ gives
|
|
you a 4 bit 640x480 display.
|
|
|
|
<sect1>Additional suboptions on Atari m68k platforms
|
|
<p>
|
|
|
|
There are a number of suboptions available with the <tt/video=xxx/
|
|
parameter:
|
|
|
|
<itemize>
|
|
<item><tt/inverse/ - 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.
|
|
<item><tt/font/ - sets the font to use in text modes. Currently you can
|
|
only select <tt/VGA8x8/, <tt/VGA8x16/, <tt/PEARL8x8/. The default is to
|
|
use the <tt/VGA8x8/ only if the vertical size of the display is less than
|
|
400 pixels, otherwise it defaults to <tt/VGA8x16/.
|
|
<item><tt/internal/ - a very interesting option. See the next section for
|
|
information.
|
|
<item><tt/external/ - as above.
|
|
<item><tt/monitorcap/ - describes the capabilities for multisyncs. DON'T
|
|
use with a fixed sync monitor!
|
|
</itemize>
|
|
|
|
<sect1>Using the internal suboption on Atari m68k platforms
|
|
<p>
|
|
|
|
Syntax: <tt/internal:(xres);(yres)[;(xres_max);(yres_max);(offset)]/
|
|
|
|
This option specifies the capabilities of some extended internal video
|
|
hardware, i.e OverScan modes. <tt/(xres)/ and <tt/(yres)/ gives the
|
|
extended dimensions of the screen.
|
|
|
|
If your OverScan mode needs a black border, you'll need to write the last
|
|
three arguments of the <tt/internal:/ suboption. <tt/(xres_max)/ is the
|
|
maximum line length that the hardware allows, <tt/(yres_max)/ is the
|
|
maximum number of lines, and <tt/(offset)/ is the offset of the visible
|
|
part of the screen memory to its physical start, in bytes.
|
|
|
|
Often extended internal video hardware has to be activated, for this you
|
|
will need the <tt/"switches=*"/ 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]
|
|
|
|
<sect1>Using the external suboption on Atari m68k platforms
|
|
<p>
|
|
|
|
Syntax:
|
|
<tt/external:(xres);(yres);(depth);(org);(scrmem)[;(scrlen)[;(vgabase)[;(colw)[;(coltype)[;(xres_virtual)]]]]]/
|
|
|
|
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)
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Following from this, you also need to tell the kernel how the video memory
|
|
is organised - supply a letter as the <tt/(org)/ parameter
|
|
|
|
<itemize>
|
|
<item><tt/n/ - use normal planes, i.e one whole plane after another
|
|
<item><tt/i/ - 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.
|
|
<item><tt/p/ - 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.
|
|
<item><tt/t/ - 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 - gives you 16.8 million
|
|
colours.
|
|
</itemize>
|
|
|
|
<em/However/, for monochrome modes, the <tt/(org)/ parameter has a
|
|
different meaning
|
|
|
|
<itemize>
|
|
<item><tt/n/ - use normal colours, i.e 0=white, 1=black
|
|
<item><tt/i/ - use inverted colours, i.e. 0=black, 1=white
|
|
</itemize>
|
|
|
|
The next important item about the video hardware is the base address of
|
|
the video memory. That is given by the <tt/(scrmem)/ parameter as a
|
|
hexadecimal number with an <tt/0x/ prefix. You will need to find this out
|
|
from the documentation that comes with your external video hardware.
|
|
|
|
The next paramter <tt/(scrlen)/ tells the kernel about the size of the
|
|
video memory. If it's missing, this is calculated from the <tt/(xres)/,
|
|
<tt/(yres)/ and <tt/(depth)/ 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 <tt/(vgabase)/ parameter, otherwise,
|
|
just leave it.
|
|
|
|
The <tt/(vgabase)/ 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 <em/clear/, <tt/(vgabase)/ is the <em/base/ address, i.e a 4k
|
|
aligned address. For reading/writing the colour registers, the kernel uses
|
|
the address range between <tt/(vgabase) + 0x3c7/ and <tt/(vgabase) +
|
|
0x3c9/. This parameter is given in hexadecimal and must have a <tt/0x/
|
|
prefix, just like <tt/(scrmem)/.
|
|
|
|
<tt/(colw)/ is only meaningful, if the <tt/(vgabase)/ 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.
|
|
|
|
<tt/(coltype)/ is used with the <tt/(vgabase)/ parameter, it tells the
|
|
kernel about the colour register model of your graphic board. Currently
|
|
the types supported are <tt/vga/ and <tt/mv300/. <tt/vga/ is the default.
|
|
|
|
<tt/(xres_virtual)/ 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.
|
|
|
|
<sect>Using framebuffer devices on Amiga m68k platforms
|
|
<p>
|
|
|
|
This section describes the options for Amigas, which are quite similiar to
|
|
that for the Atari m68k platforms.
|
|
|
|
<sect1>What modes are available for Amiga m68k platforms?
|
|
<p>
|
|
|
|
This depends on the chipset used in the Amiga. There are three main ones;
|
|
<tt/OCS, ECS and AGA/ which all uses the colour frame buffer device.
|
|
|
|
<itemize>
|
|
<item>NTSC modes
|
|
<itemize>
|
|
<item><tt/ntsc/ - 640x200
|
|
<item><tt/ntsc-lace/ - 640x400
|
|
</itemize>
|
|
<item>PAL modes
|
|
<itemize>
|
|
<item><tt/pal/ - 640x256
|
|
<item><tt/pal-lace/ - 640x512
|
|
</itemize>
|
|
<item>ECS modes - 2 bit colours on ECS, 8 bit colours on AGA chipsets
|
|
only.
|
|
<itemize>
|
|
<item><tt/multiscan/ - 640x480
|
|
<item><tt/multiscan-lace/ - 640x960
|
|
<item><tt/euro36/ - 640x200
|
|
<item><tt/euro36-lace/ - 640x400
|
|
<item><tt/euro72/ - 640x400
|
|
<item><tt/euro72-lace/ - 640x800
|
|
<item><tt/super72/ - 800x300
|
|
<item><tt/super72-lace/ - 800x600
|
|
<item><tt/dblntsc/ - 640x200
|
|
<item><tt/dblpal/ - 640x256
|
|
<item><tt/dblntsc-ff/ - 640x400
|
|
<item><tt/dblntsc-lace/ - 640x800
|
|
<item><tt/dblpal-ff/ - 640x512
|
|
<item><tt/dblpal-lace/ - 640x1024
|
|
</itemize>
|
|
<item>VGA modes - 2 bit colours on ECS, 8 bit colours on AGA chipsets
|
|
only.
|
|
<itemize>
|
|
<item><tt/vga/ - 640x480
|
|
<item><tt/vga70/ - 640x400
|
|
</itemize>
|
|
</itemize>
|
|
|
|
<sect1>Additional suboptions on Amiga m68k platforms
|
|
<p>
|
|
|
|
These are similar to the Atari m68k suboptions. They are:
|
|
|
|
<itemize>
|
|
<item><tt/depth/ - specifies the pixel bit depth.
|
|
<item><tt/inverse/ - does the same thing as the Atari suboption.
|
|
<item><tt/font/ - does the same thing as the Atari suboption, although the
|
|
<tt/PEARL8x8/ font is used instead of <tt/VGA8x8/ font, if the display
|
|
size is less than 400 pixel wide.
|
|
<item><tt/monitorcap/ - specifies the capabilities of the multisync
|
|
monitor. Do not use with fixed sync monitors.
|
|
</itemize>
|
|
|
|
<sect1>Supported Amiga graphic expansion boards
|
|
<p>
|
|
|
|
<itemize>
|
|
<item><tt/Phase5 CyberVision 64/ (S3 Trio64 chipset)
|
|
<item><tt/Phase5 CyverVision 64-3D/ (S3 ViRGE chipset)
|
|
<item><tt/MacroSystems RetinaZ3/ (NCR 77C32BLT chipset)
|
|
<item><tt/Helfrich Piccolo, SD64, GVP ECS Spectrum, Village Tronic Picasso
|
|
II/II+ and IV/ (Cirrus Logic GD542x/543x)
|
|
</itemize>
|
|
|
|
<sect>Using framebuffer devices on Macintosh m68k platforms
|
|
<p>
|
|
|
|
Currently, the framebuffer device implemented only supports the mode
|
|
selected in MacOS before booting into Linux, also supports 1, 2, 4 and 8
|
|
bit colours modes.
|
|
|
|
Framebuffer suboptions are selected using the following syntax
|
|
|
|
<verb>
|
|
video=macfb:<font>:<inverse>
|
|
</verb>
|
|
|
|
You can select fonts such as VGA8x8, VGA8x16 and 6x11 etc. The inverse
|
|
option allows you to use reverse video.
|
|
|
|
<sect>Using framebuffer devices on PowerPC platforms
|
|
<p>
|
|
|
|
The author would love to receive information on the use of framebuffers on
|
|
this platform.
|
|
|
|
<sect>Using framebuffer devices on Alpha platforms
|
|
|
|
<sect1>What modes are available to me?
|
|
<p>
|
|
|
|
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.
|
|
|
|
<sect1>Which graphic cards can work with the frambuffer device?
|
|
<p>
|
|
|
|
This lists all the graphic cards that are known to work:
|
|
|
|
<itemize>
|
|
<item><tt/DEC TGA PCI (DEC21030)/ - 640x480 @ 8 bit or 24/32 bit versions
|
|
</itemize>
|
|
|
|
<sect>Using framebuffer devices on SPARC platforms
|
|
|
|
<sect1>Which graphic cards can work with the framebuffer device?
|
|
<p>
|
|
This lists all the graphic cards available:
|
|
|
|
<itemize>
|
|
<item>MG1/MG2 - SBus or integrated on Sun3 - max. 1600x1280 @ mono (BWtwo)
|
|
<item>CGthree - Similar to MG1/MG2 but supports colour - max resolution ?
|
|
<item>GX - SBus - max. 1152x900 @ 8bit (CGsix)
|
|
<item>TurboGX - SBus - max. 1152x900 @ 8 bit (CGsix)
|
|
<item>SX - SS10/SS20 only - max. 1280x1024 @ 24 bit - (CGfourteen)
|
|
<item>ZX(TZX) - SBus - accelerated 24bit 3D card - max resolution ?
|
|
(Leo)
|
|
<item>TCX - AFX - for Sparc 4 only - max. 1280x1024 @ 8bit
|
|
<item>TCX(S24) - AFX - for Sparc 5 only - max. 1152x900 @ 24bit
|
|
<item>Creator - SBus - max. 1280x1024 @ 24bit (FFB)
|
|
<item>Creator3D - SBus - max. 1920x1200 @ 24bit (FFB)
|
|
<item>ATI Mach64 - accelerated 8/24bit for Sparc64 PCI only
|
|
</itemize>
|
|
|
|
There is the option to use the PROM to output characters to the display or
|
|
to a serial console.
|
|
|
|
Also, have a look at the Sparc Frame Buffer FAQ at
|
|
<verb>http://c3-a.snvl1.sfba.home.com/Framebuffer.html</verb>
|
|
|
|
<sect1>Configuring the framebuffer devices
|
|
<p>
|
|
|
|
During make config, you need to choose whether to compile <tt/promcon/
|
|
and/or <tt/fbcon/. You can select both, but if you do this, you will need
|
|
to set the kernel flags to select the device. <tt/fbcon/ always takes
|
|
precedence if not set. If <tt/promcon/ is not selected in, on boot up, it
|
|
defaults to <tt/dummycon/. If <tt/promcon/ is selected, it will use this
|
|
device. Once the buses are booted, and <tt/fbcon/ is compiled in, the
|
|
kernel probes for the above framebuffers and will use <tt/fbcon/. If there
|
|
is no framebuffer devices, it will default to <tt/promcon/.
|
|
|
|
Here are the kernel options
|
|
<verb>
|
|
video=sbus:options
|
|
where options is a comma separated list:
|
|
nomargins sets margins to 0,0
|
|
margins=12x24 sets margins to 12,24 (default is computed
|
|
from resolution)
|
|
off don't probe for any SBus/UPA framebuffers
|
|
font=SUN12x22 use a specific font
|
|
</verb>
|
|
|
|
So for example, booting with <verb> video=sbus:nomargins,font=SUN12x22
|
|
</verb> 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 Intel platform.
|
|
|
|
If you want to use the <tt/SUN12x22/ font, you need to enable it during
|
|
make config (disable the <tt/fontwidth != 8/ option). The accelerated
|
|
framebuffers can support any font width between 1 to 16 pixels, whilst
|
|
dumb frame buffers only supports 4, 8, 12 and 16 pixel font widths.
|
|
|
|
It is recommended that you grab a recent consoletools packages.
|
|
|
|
<sect>Using framebuffer devices on MIPS platforms
|
|
<p>
|
|
|
|
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.
|
|
|
|
<sect>Using framebuffer devices on ARM platforms
|
|
<p>
|
|
|
|
<sect1>Netwinders
|
|
<p>
|
|
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.
|
|
|
|
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]
|
|
|
|
<sect1>Acorn Archimedes
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Other ARM ports (SA 7110s et. al)
|
|
<p>
|
|
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!]
|
|
|
|
<sect>Using multi-headed framebuffers
|
|
<p>
|
|
|
|
This part of the document was very kindly donated by Frederick A. Niles,
|
|
who retains all rights to the information contained herewith this section of
|
|
the HOWTO.
|
|
|
|
<sect1>Introduction
|
|
<p>
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
** 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.
|
|
|
|
<sect1>Feedback
|
|
<p>
|
|
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:
|
|
Frederick.A.Niles@gsfc.nasa.gov.
|
|
|
|
<sect1>Contributors
|
|
<p>
|
|
The following people have contributed to this mini-HOWTO.
|
|
|
|
* Petr Vandrovec <tt/vandrove@vc.cvut.cz/
|
|
|
|
* Andreas Ehliar <tt/ehliar@lysator.liu.se/ (x2x)
|
|
|
|
* Marco Bizzarri <tt/m.bizzarri@icube.it/ (multiple X servers)
|
|
|
|
<sect1>Standard Disclaimer
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Copyright Information
|
|
<p>
|
|
This section of the document is copyrighted (c)1999 Frederick Niles and distributed
|
|
under the following terms:
|
|
|
|
* 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.
|
|
|
|
* 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.
|
|
|
|
* If you have questions, please contact, the Linux HOWTO coordinator,
|
|
at linux-howto@sunsite.unc.edu
|
|
|
|
<sect1>What hardware is supported?
|
|
<p>
|
|
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.
|
|
|
|
* 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
|
|
|
|
* MDA: This includes monochrome Hercules graphics adapter among others.
|
|
This for text only second head support.
|
|
|
|
Note: it's only the second adapter that has to be one of the above.
|
|
|
|
<sect1>Commercial support
|
|
<p>
|
|
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.
|
|
|
|
<sect1>Getting all the stuff.
|
|
<p>
|
|
You'll need the following patches and programs:
|
|
|
|
* "fbset" program
|
|
try: <verb>http://www.cs.kuleuven.ac.be/~geert/bin/</verb>
|
|
(note: this program comes with RedHat 6.0)
|
|
|
|
* "fbaddon" Matrox dual head patches for Linux kernel
|
|
try: <verb>ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/</verb>
|
|
|
|
* "con2fb" program
|
|
try: <verb>ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/</verb>
|
|
|
|
* The X11 frame buffer server XF86_FBDev. This is a standard
|
|
part of XFree86 3.3.1.
|
|
|
|
<sect1>Getting Started
|
|
<p>
|
|
The first thing you'll need to do is to patch a copy of the Linux
|
|
source with the "fbaddon" 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.
|
|
|
|
Now you need to install the "fbset" program and carefully read all
|
|
the documentation on how to adjust the settings. Using a
|
|
"/etc/fb.modes" 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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
<sect2>Move a console over...
|
|
<p>
|
|
Compile the "con2fb" program. If you run it without any arguments
|
|
you'll get the following usage message:
|
|
|
|
"usage: con2fb fbdev console".
|
|
|
|
Thus, an example command would be "con2fb /dev/fb1 /dev/tty6" 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.
|
|
|
|
<sect2>Use "fbset" to adjust the setting on this second monitor
|
|
<p>
|
|
Only set the "fbset" settings on the monitor you run the "fbset"
|
|
command on. Therefore, you must be careful to use the "-fb" 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.
|
|
|
|
e.g. "fbset -fb /dev/fb1 -vyres 600"
|
|
|
|
This will seriously slow down text mode, but X will be obnoxious
|
|
without it.
|
|
|
|
<sect2>Set up X for Frame Buffer support.
|
|
<p>
|
|
The framebuffer.txt file explains this better than I can, but here's
|
|
the two important points.
|
|
|
|
Make sure you set the link for "X" to point to "XF86_FBDev".
|
|
|
|
Next you need to add a monitor section to your XF86Config file
|
|
for the frame buffer device. Here's an example:
|
|
|
|
<verb>
|
|
# 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
|
|
</verb>
|
|
|
|
Use the "default" modes as I don't think any other one will work with
|
|
the Matrox frame buffer.
|
|
|
|
<sect2>Try starting the X server on the second monitor.
|
|
<p>
|
|
Set the variable FRAMEBUFFER to the second frame buffer.
|
|
|
|
"export FRAMEBUFFER=/dev/fb1"
|
|
|
|
or
|
|
|
|
"setenv FRAMEBUFFER /dev/fb1"
|
|
|
|
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.
|
|
|
|
e.g. "startx -- :0 -bpp 16 vt06"
|
|
|
|
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.
|
|
|
|
<sect1>Summary
|
|
<p>
|
|
The steps involved in getting an X server running on a second monitor
|
|
can be summarized as follows:
|
|
|
|
* Get the kernel patch, fbset, and con2fb.
|
|
|
|
* Patch the kernel, configure, rebuild, and reboot.
|
|
|
|
* Add XF86_FBDev section to XF86Config file and set X link.
|
|
|
|
Then each time you reboot:
|
|
|
|
* Move a console over. e.g. "con2fb /dev/fb1 /dev/tty6"
|
|
|
|
* Adjust the settings e.g. "fbset -fb /dev/fb1 1280x1024"
|
|
|
|
* Set the FRAMEBUFFER. e.g. "export FRAMEBUFFER=/dev/fb1"
|
|
|
|
* Start the X server. e.g. "startx -- -bpp 16 vt06"
|
|
|
|
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 C-shell alias to start up X on
|
|
a second fixed frequency monitor:
|
|
|
|
<verb>
|
|
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.
|
|
"
|
|
</verb>
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
<sect1>Other Notes and Problems
|
|
<p>
|
|
* Both "fbset" and "startx" 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.
|
|
|
|
* 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 x2x to switch
|
|
between them however...(see the next bullet)
|
|
|
|
* The inactive frame buffer will just hold the last image of when it
|
|
was active, no updates with occur.
|
|
|
|
* The monitor that's not selected doesn't always preseve it's state
|
|
when not active. (But it usually does.)
|
|
|
|
* 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. fbaddon) so it may never
|
|
be in the mainstream kernel tree. (This was heard third hand and
|
|
may be wildly untrue.)
|
|
|
|
* If you "break the rules" and start the X server (run "startx")
|
|
from a different monitor, the machine can eventually crash badly
|
|
with the keyboard and mouse input all mixed together.
|
|
|
|
* 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 ("default") setting at at time (the same one you had in text
|
|
mode).
|
|
|
|
* The XF86_FBDev is unaccelerated. However, there are patches for
|
|
accelerated Matrox support at
|
|
<verb>http://www.in-berlin.de/User/kraxel/xfree86/</verb>
|
|
|
|
<sect2>Getting "init level five" (i.e. xdm/gdm) to work
|
|
<p>
|
|
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 constrain 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.
|
|
|
|
<sect2>Using the x2x program.
|
|
<p>
|
|
There's a nice little program called x2x that will switch X servers
|
|
for you when you get to the edge of the screen. Last known home for
|
|
this program was: <verb>http://ftp.digital.com/pub/DEC/SRC/x2x/</verb> It's
|
|
also an optional Debian package. I haven't tried it yet but some
|
|
users have reported success.
|
|
|
|
<sect2>Other useful commands
|
|
<p>
|
|
These are existing linux commands that are worth remembering when
|
|
dealing with a multi-head configuration (especially in writing
|
|
scripts).
|
|
|
|
* "chvt" will allow you to switch between virtual terminals.
|
|
|
|
* "openvt" start a program on a new virtual terminal (VT).
|
|
|
|
* "tty" will report the name of the current terminal.
|
|
|
|
<sect2>Appendix A. Octave cvtmode.m script
|
|
<p>
|
|
(note the bpp setting)
|
|
<verb>
|
|
#!/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");
|
|
</verb>
|
|
|
|
<sect2>Appendix B. Borne Shell script "cvtfile"
|
|
<p>
|
|
(This calls the octave script "cvtmode")
|
|
<verb>
|
|
#!/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
|
|
</verb>
|
|
|
|
<sect>Using/Changing fonts
|
|
<p>
|
|
|
|
To get the capability to change fonts, you need kbd-0.99. You may obtain
|
|
this from <verb>ftp://ftp.win.tue.nl/pub/linux/utils/kbd</verb>
|
|
|
|
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 (It is tres chic to have three symbols on my keyboard, the dollar
|
|
sign, the English pound sign and the Euro sign!).
|
|
|
|
<sect>Changing console modes
|
|
<p>
|
|
|
|
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:
|
|
|
|
<verb>
|
|
http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz
|
|
</verb>
|
|
|
|
This comes with a full set of instructions on how to operate this.
|
|
|
|
<sect>Setting up the X11 FBdev driver
|
|
<p>
|
|
|
|
If you are not using XFree86 3.3.3.1 or later, you are urged to upgrade
|
|
to XFree86 3.3.3.1 - 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.
|
|
|
|
Go to <verb>http://www.xfree86.org</verb>, and download the latest XServers source archive,
|
|
unpack, and configure the drivers, following these steps:
|
|
|
|
<itemize>
|
|
<item>Edit xc/config/cf/xf86site.def, uncomment the #define for
|
|
XF68FBDevServer
|
|
<item>Comment out <em/all/ references to FB_VISUAL_STATIC_DIRECTCOLOR, as
|
|
these are bogus and aren't used any more. If you are using XFree86 3.3.3.1,
|
|
there is no need to do this step - as they have removed this.
|
|
<item>Edit xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c, and
|
|
change K_RAW to K_MEDIUMRAW.
|
|
</itemize>
|
|
|
|
and then build the driver. Don't worry about the m68k references, it
|
|
supports Intel platforms. Then build the whole thing - it'll take a long
|
|
time though as it's a large source tree.
|
|
|
|
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.
|
|
|
|
For libc5, use the one at:
|
|
|
|
<verb>
|
|
http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.gz
|
|
</verb>
|
|
For glibc2, download from these URLs.
|
|
|
|
<verb>
|
|
http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.libc6.gz
|
|
http://pobox.com/~brion/linux/fbxserver.html
|
|
</verb>
|
|
|
|
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.
|
|
|
|
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 MGA G-200 et. al.
|
|
|
|
To configure the XF86_FBdev driver with your X11 system, you'll need to
|
|
edit your XF86Config for the following:
|
|
|
|
<verb>
|
|
Section "Screen"
|
|
Driver "FBDev"
|
|
Device "Primary Card"
|
|
Monitor "Primary Monitor"
|
|
SubSection "Display"
|
|
Modes "default"
|
|
EndSubSection
|
|
EndSection
|
|
</verb>
|
|
|
|
You'll also need to set XkbDisable in the keyboard section as well, or
|
|
invoke the XF86_FBDev server with the '-kb' 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 .Xmodmap to straighten out the keyboard
|
|
mappings. Alternatively, you can edit your xkb to reflect the list below.
|
|
|
|
<em/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./
|
|
|
|
<verb>
|
|
! 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
|
|
</verb>
|
|
|
|
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.
|
|
|
|
Hopefully the X11 problems with supported graphic cards will be fixed in
|
|
future releases.
|
|
|
|
<sect>How do I convert XFree86 mode-lines into framebuffer device timings?
|
|
<p>
|
|
|
|
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 to the
|
|
required timings needed by the framebuffer devices.
|
|
|
|
The framebuffer device requires the following fields
|
|
<itemize>
|
|
<item>pixclock - pixel clock in pico seconds
|
|
<item>left_margin - time fron sync to picture
|
|
<item>right_margin - time from picture to sync
|
|
<item>upper_margin - time from sync to picture
|
|
<item>lower_margin - time from picture to sync
|
|
<item>hsync_len - length of horizontal sync
|
|
<item>vsync_len - length of vertical sync
|
|
</itemize>
|
|
|
|
<p>
|
|
An XFree86 mode line has the following fields
|
|
|
|
<verb>
|
|
Modeline "1280x1024" DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
|
|
</verb>
|
|
|
|
<p>
|
|
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.
|
|
|
|
<verb>
|
|
Modeline "1280x1024" 110.00 1280 1328 1512 1712 1024 1025 1028 1054
|
|
</verb>
|
|
|
|
<p>
|
|
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,
|
|
1,000,000 / 110.0 = 9090.9091
|
|
|
|
<p>
|
|
Now we need to calculate the horizontal timings.
|
|
<itemize>
|
|
<item>left_margin = HFL - SH2
|
|
<item>right_margin = SH1 - HR
|
|
<item>hsync_len = SH2 - SH1
|
|
</itemize>
|
|
|
|
<p>In our example, this would be:
|
|
<itemize>
|
|
<item>left_margin = 1712 - 1512 = 200
|
|
<item>right_margin = 1328 - 1280 = 48
|
|
<item>hsync_len = 1512 - 1328 = 184
|
|
</itemize>
|
|
|
|
<p>And now we need to calculate the vertical timings.
|
|
<itemize>
|
|
<item>upper_margin = VFL - SV2
|
|
<item>lower_margin = SV1 - VR
|
|
<item>vsync_len = SV2 - SV1
|
|
</itemize>
|
|
|
|
<p>For our example, this would be:
|
|
<itemize>
|
|
<item>upper_margin = 1054 - 1028 = 26
|
|
<item>lower_margin = 1025 - 1024 = 1
|
|
<item>vsync_len = 1028 - 1025 = 3
|
|
</itemize>
|
|
|
|
<p>
|
|
Now we can use this information to set up the framebuffer for the desired mode.
|
|
For example, for the matroxfb framebuffer, it requires:
|
|
|
|
<verb>
|
|
video=matrox:xres:<>,yres:<>,depth:<>,left:<>,right:<>,hslen:<>,upper:<>,lower:<>,vslen:<>
|
|
</verb>
|
|
|
|
I put in my /etc/lilo.conf the following line:
|
|
<verb>
|
|
append = "video=matrox:xres:1280,yres:1024,depth:32,left:200,right:48,hslen:184,upper:26,lower:0,vslen:3"
|
|
</verb>
|
|
|
|
<p>
|
|
Note that in this case the pixclock isn't used. It's only necessary if you don't like the default pixclock
|
|
rates. You can supply this as a parameter as well. Setting the pixclock is documented in other parts of this
|
|
HOWTO.
|
|
|
|
<sect>Changing the Linux logo
|
|
<p>
|
|
|
|
It can be customised by changing the file linux_logo.h in include/linux
|
|
directory. its a c header and pretty hard to change by hand however
|
|
there is a plugin available for gimp <verb>
|
|
http://registry.gimp.org/detailview.phtml?plugin=Linux+Logo </verb> that
|
|
will create one for you. all you need is a picture 80x80 with less than
|
|
224 colours. you can either let the plug in create the 3 varieties
|
|
(2,16,224) 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 in ($SRCDIR)/include/linux/linux_logo.h. 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.
|
|
|
|
<sect>Looking for further information?
|
|
<p>
|
|
|
|
For those of you interested in working with the framebuffer drivers,
|
|
point your browser at <verb>http://www.linux-fbdev.org </verb> for
|
|
information on programming.
|
|
|
|
French speakers, there is a translation at <verb>http://www.freenix.org/unix/linux/HOWTO/mini/Vesafb.html</verb>
|
|
</article>
|