1592 lines
68 KiB
Plaintext
1592 lines
68 KiB
Plaintext
|
||
Framebuffer HOWTO
|
||
|
||
Alex Buell
|
||
|
||
<alex.buell@munted.org.uk>
|
||
|
||
2010-08-05, version 1.3
|
||
Revision History
|
||
Revision v1.3 2010-08-05
|
||
Converted to DocBook from LinuxDoc
|
||
Revision v1.2 2000-01-22
|
||
Last public release
|
||
Revision v1.1 1999-07-22
|
||
With some additional information
|
||
Revision v1.0 1999-06-07
|
||
First public release
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
Table of Contents
|
||
1. Contributors
|
||
2. What is a framebuffer device?
|
||
3. What advantages does framebuffer devices have?
|
||
4. Using framebuffer devices on x86 platforms
|
||
|
||
4.1. What is vesafb?
|
||
4.2. How do I activate the vesafb drivers?
|
||
4.3. What VESA modes are available to me?
|
||
4.4. Got a Matrox card?
|
||
4.5. Got a Permedia card?
|
||
4.6. Got an ATI card?
|
||
4.7. Which graphic cards are VESA 2.0 compliant?
|
||
4.8. Can I compile vesafb as a module?
|
||
4.9. How do I modify the cursor
|
||
|
||
5. Using framebuffer devices on m68k platforms
|
||
|
||
5.1. Atari platforms
|
||
5.2. Amiga platforms
|
||
|
||
6. Using framebuffer devices on PowerPC platforms
|
||
7. Using framebuffer devices on Alpha platforms
|
||
|
||
7.1. What modes are available?
|
||
7.2. Which graphic cards can work on Alpha?
|
||
|
||
8. Using framebuffer devices on SPARC platforms
|
||
|
||
8.1. Which graphic cards can work on the SPARC
|
||
8.2. Configuring the framebuffer devices
|
||
|
||
9. Using framebuffer devices on MIPS platforms
|
||
10. Using framebuffer devices on ARM platforms
|
||
|
||
10.1. Netwinders
|
||
10.2. Acorn Archimedes
|
||
10.3. Other ARM ports (SA7710s et. al.)
|
||
|
||
11. Using multi-headed framebuffers
|
||
|
||
11.1. Introduction
|
||
11.2. Feedback
|
||
11.3. Contributors
|
||
11.4. Standard Disclaimer
|
||
11.5. Copyright Information
|
||
11.6. What hardware is supported?
|
||
11.7. Commercial support
|
||
11.8. Getting all the stuff
|
||
11.9. Getting Started
|
||
11.10. Summary
|
||
11.11. Other Notes and Problems
|
||
11.12. Appendix A. Octave "" script
|
||
11.13. Appendix B. Bourne Shell "" script
|
||
|
||
12. Using / Changing Fonts
|
||
13. Changing Console Modes
|
||
14. Setting up the X11 FBdev driver
|
||
15. How do I convert XFree86 mode-lines into framebuffer device
|
||
timings?
|
||
|
||
16. Changing the Linux Logo
|
||
17. Looking for further information
|
||
|
||
Copyright <20> 1999--2010 Alex Buell, GNU Free Documentation Licence
|
||
(GFPL)
|
||
|
||
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 the Free Software Foundation.
|
||
________________________________________________________________
|
||
|
||
1. Contributors
|
||
|
||
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!
|
||
|
||
* Jeff Noxon
|
||
* Francis Devereux
|
||
* Andreas Ehliar
|
||
* Martin McCarthy
|
||
* Simon Kenyon
|
||
* David Ford
|
||
* Chris Black
|
||
* N. Becker
|
||
* Bob Tracy
|
||
* Marius Hjelle
|
||
* James Cassidy
|
||
* Andreas U. Trottmann
|
||
* Lech Szychowski
|
||
* Aaron Tiensivu
|
||
* Jan-Frode Myklebust for his info on permedia cards
|
||
* Many others too numerous to add, but thanks!
|
||
|
||
Thanks go to Rick Niles 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 x86 platforms:
|
||
|
||
* Brion Vibber
|
||
* Gerd Knorr
|
||
|
||
And, of course, the authors of the framebuffer device drivers:
|
||
|
||
* Martin Schaller - original author of the framebuffer driver
|
||
concept
|
||
* Roman Hodek
|
||
* Andreas Schwab
|
||
* G<>nther Kelleter
|
||
* Geert Uytterhoeven
|
||
* Roman Zippel
|
||
* Pavel Machek
|
||
* Gerd Knorr
|
||
* Miguel de Icaza
|
||
* David Carter
|
||
* William Ricklidge
|
||
* Jes Sorensen
|
||
* Sigurdur Asgeirsson
|
||
* Jeffrey Kuskin
|
||
* Michal Rehacek
|
||
* Peter Zaitcev
|
||
* David S. Miller
|
||
* Dave Redman
|
||
* Jay Estabrook
|
||
* Martin Mares
|
||
* Dan Jacobowitz
|
||
* Emmnauel Marty
|
||
* Eddie C. Dost
|
||
* Jakub Jelinek
|
||
* Philip Blundell
|
||
* Anyone else, stand up and be counted!
|
||
________________________________________________________________
|
||
|
||
2. What is a framebuffer device?
|
||
|
||
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]
|
||
________________________________________________________________
|
||
|
||
3. What advantages does framebuffer devices have?
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
* 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)
|
||
* 2.1.107 - introduced x86 framebuffer/new console devices and
|
||
added generic support, without scrollback buffer support.
|
||
* 2.1.113 - scrollback buffer support added to vgacon.
|
||
* 2.1.116 - scrollback buffer support added to vesafb.
|
||
* 2.2.x - includes matroxfb (Matrox cards) and atyfb (ATI cards).
|
||
|
||
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:
|
||
|
||
* video=xxx:off - disable probing for a particular framebuffer
|
||
device
|
||
* video=map:octal-number - maps the virtual consoles (VCs) to
|
||
framebuffer (FB) devices
|
||
*
|
||
+ video=map:01 will map VC0 to FB0, VC1 to FB1, VC2 to FB0,
|
||
VC3 to FB1...
|
||
+ video=map:0132 will map VC0 to FB0, VC1 to FB1, VC2 to FB3,
|
||
VC4 to FB2, VC5 to FB0...
|
||
|
||
Normally framebuffer devices are probed for in the order specified in
|
||
the kernel, but by specifying the video=xxx option, you can add the
|
||
specific framebuffer device you want probed before the others
|
||
specified in the kernel.
|
||
________________________________________________________________
|
||
|
||
4. Using framebuffer devices on x86 platforms
|
||
|
||
4.1. What is vesafb?
|
||
|
||
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.
|
||
|
||
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)
|
||
|
||
Unfortunately, you can not use vesafb successfully with VESA 1.2
|
||
cards. This is because these 1.2 cards do not use 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 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
|
||
[ftp://ccssu.crimea.ua/pub/linux/kernel/v2.2/unofficial/s3new.diff.gz
|
||
]
|
||
ftp://ccssu.crimea.ua/pub/linux/kernel/v2.2/unofficial/s3new.diff.gz.
|
||
________________________________________________________________
|
||
|
||
4.2. How do I activate the vesafb drivers?
|
||
|
||
Assuming you are using menuconfig, you will need to do the following
|
||
steps:
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Go into the Console Drivers menu, and enable the following:
|
||
|
||
* VGA Text Console
|
||
* Video Selection Support
|
||
* Support for frame buffer devices (experimental)
|
||
* VESA VGA Graphic console
|
||
* Advanced Low Level Drivers
|
||
* Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed
|
||
pixel drivers
|
||
|
||
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)
|
||
|
||
# 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
|
||
|
||
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 three-digit number, 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.
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
4.3. What VESA modes are available to me?
|
||
|
||
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)
|
||
|
||
Table 1. VESA modes
|
||
Depth 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 ? ?
|
||
|
||
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.
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
4.4. Got a Matrox card?
|
||
|
||
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 first, you can download the
|
||
BIOS upgrade from [http://www.matrox.com/mgaweb/drivers/ftp_bios.htm]
|
||
http://www.matrox.com/mgaweb/drivers/ftp_bios.htm 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:
|
||
|
||
* VGA Text Console
|
||
* Video Selection Support
|
||
* Support for frame buffer devices (experimental)
|
||
* Matrox Acceleration
|
||
* Select the following depending on the card that you have
|
||
*
|
||
+ Millennium I / II support
|
||
+ Mystique support
|
||
+ G100 / G200 support
|
||
* Enable Multihead Support if you want to use more than one Matrox
|
||
card
|
||
* Advanced Low Level Drivers
|
||
* elect Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed pixel
|
||
drivers
|
||
|
||
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.
|
||
|
||
# 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
|
||
|
||
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 224i)
|
||
|
||
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!
|
||
________________________________________________________________
|
||
|
||
4.5. Got a Permedia card?
|
||
|
||
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:
|
||
|
||
* VGA Text Console
|
||
* Video Selection Support
|
||
* Support for frame buffer devices (experimental)
|
||
* Permedia2 support (experimental)
|
||
* Generic Permedia2 PCI board support
|
||
* Advanced Low Level Drivers
|
||
* Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed
|
||
pixel drivers
|
||
* Optionally, select the following, if you wish to use the compiled
|
||
in fonts
|
||
*
|
||
+ Select compiled-in fonts
|
||
+ Select Sparc console 12x22 font
|
||
|
||
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:
|
||
|
||
# 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
|
||
|
||
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
|
||
[http://www.cs.unibo.it/~nardinoc/pm2fb/index.html]
|
||
http://www.cs.unibo.it/~nardinoc/pm2fb/index.html
|
||
|
||
video=pm2fb:[option[,option[,option...]]]
|
||
|
||
where option is one of the following:
|
||
|
||
* off - disables the driver
|
||
* mode:resolution - sets 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 8 bpp. This the list of available
|
||
modes:
|
||
*
|
||
+ 640x480-(60,72,75,90,100)
|
||
+ 640x480-(60,72,75,90,100)
|
||
+ 1024x768-(60,70,72,75,90,100,illo) illo=80KHz 100Hz
|
||
+ 152x864-(60,70,75,80)
|
||
+ 1280x1024-(60,70,74,75)
|
||
+ 1600x1200-(60,66,76)
|
||
* The default resolution is 640x480-60
|
||
* font:name - sets the console font. Example font:SUN12x12
|
||
* ypan - sets the current virtual height as big as video memory
|
||
permits.
|
||
* oldmem - used for CybervisionPPC boards only with Fujitsi SGRAMs
|
||
mounted. Applies to all CyberVisionPPCs made before 30-Dec-1998.
|
||
* virtual - used with kernels capable of remapping the PCI regions
|
||
________________________________________________________________
|
||
|
||
4.6. Got an ATI card?
|
||
|
||
[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:
|
||
|
||
* VGA Text Console
|
||
* Video Selection Support
|
||
* Support for frame buffer devices (experimental)
|
||
* ATI Mach64 display support
|
||
* Advanced Low Level Drivers
|
||
* Select Mono, 2bpp, 4bpp, 8bpp, 16bpp, 24bpp and 32bpp packed
|
||
pixel drivers
|
||
* Optionally, select the following, if you wish to use the compiled
|
||
in fonts
|
||
*
|
||
+ Select compiled-in fonts
|
||
+ Select Sparc console 12x22 font
|
||
|
||
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:
|
||
|
||
# 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
|
||
|
||
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:
|
||
|
||
* font - selects font to use (compiled into kernel)
|
||
* noblink - turns off blinking
|
||
* noaccel - disables acceleration
|
||
* vram - how much video memory is there on the card
|
||
* pll - unknown
|
||
* mclk - unknown
|
||
* vmode - unknown
|
||
* cmode - sets colour depth (4, 8, 15, 16, 24 and 32)
|
||
________________________________________________________________
|
||
|
||
4.7. Which graphic cards are VESA 2.0 compliant?
|
||
|
||
This lists all the graphic devices that are known to work with the
|
||
vesafb device driver:
|
||
|
||
* ATI PCI VideoExpression 2MB (max. 1280x1024 @ 8bit)
|
||
* ATI PCI All-in-Wonder
|
||
* Matrox Millennium PCI - BIOS v3.0
|
||
* Matrox Millennium II PCI - BIOS v1.5
|
||
* Matrox Millennium II AGP - BIOS v1.4
|
||
* Matrox Millennium G200 AGP - BIOS v1.3
|
||
* Matrox Mystique & Mystique 220 PCI - BIOS v1.8
|
||
* Matrox Mystique G200 AGP - BIOS v1.3
|
||
* Matrox Productiva G100 AGP - BIOS v1.4
|
||
* All Riva 128 based cards
|
||
* Diamond Viper V330 PCI 4MB
|
||
* Genoa Phantom 3D/S3 ViRGE/DX
|
||
* Hercules Stingray 128/3D with TV output
|
||
* Hercules Stingray 128/3D without TV output - needs BIOS upgrade
|
||
(free from support@hercules.com)
|
||
* SiS 6326 PCI/AGP 4MB
|
||
* STB Lightspeed 128 (Nvida Riva 128 based) PCI
|
||
* STB Velocity 128 (Nvida Riva 128 based) PCI
|
||
* Jaton Video-58P ET6000 PCI 2MB-4MB (max. 1600x1200 @ 8bit)
|
||
* Voodoo2 2000
|
||
|
||
This list below blacklists graphic cards that doesn't work with the
|
||
vesafb device:
|
||
|
||
* TBD
|
||
________________________________________________________________
|
||
|
||
4.8. Can I compile vesafb as a module?
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
4.9. How do I modify the cursor
|
||
|
||
With thanks to Martin Mares, taken from his VGA-softcursor.txt
|
||
document.
|
||
|
||
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 <ESC>[?1;2;3c 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<ESC>[?2c'
|
||
* To get blinking block, use: echo -e '\033<ESC>[?6c'
|
||
* To get red non-blinking block, use: echo -e
|
||
'\033i<ESC>[?17;0;64c'
|
||
________________________________________________________________
|
||
|
||
5. Using framebuffer devices on m68k platforms
|
||
|
||
5.1. Atari platforms
|
||
|
||
This section describe framebuffer options on Atari platforms
|
||
________________________________________________________________
|
||
|
||
5.1.1. What modes are available?
|
||
|
||
Table 2. Atari modes
|
||
Depth 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
|
||
|
||
ttlow, ttmid and ttmhigh are only used on the TT, whilst vga2, vga4,
|
||
vga16, vga256, falh3 and falh16 are only used on the Falcon.
|
||
|
||
When used with the kernel option 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:
|
||
|
||
* ttmid
|
||
* tthigh
|
||
* vga16
|
||
* sthigh
|
||
* stmid
|
||
|
||
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, video=vga16
|
||
gives you a 4 bit 640x480 display.
|
||
________________________________________________________________
|
||
|
||
5.1.2. Additional suboptions
|
||
|
||
There are a number of suboptions available with the video=xxx
|
||
parameter:
|
||
|
||
* 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.
|
||
* font - sets the font to use in text modes. Currently you can only
|
||
select VGA8x8, VGA8x16, PEARL8x8. The default is to use the
|
||
VGA8x8 only if the vertical size of the display is less than 400
|
||
pixels, otherwise it defaults to VGA8x16.
|
||
* internal - a very interesting option. See the next section for
|
||
information.
|
||
* external - as above.
|
||
* monitorcap - describes the capabilities for multisyncs. DON'T use
|
||
with a fixed sync monitor!
|
||
________________________________________________________________
|
||
|
||
5.1.2.1. Using the suboption
|
||
|
||
Syntax: internal:(xres);(yres)[;(xres_max);(yres_max);(offset)]
|
||
|
||
This option specifies the capabilities of some extended internal
|
||
video hardware, i.e OverScan modes. (xres) and (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 internal: suboption. (xres_max) is the
|
||
maximum line length that the hardware allows, (yres_max) is the
|
||
maximum number of lines, and (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 "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]
|
||
________________________________________________________________
|
||
|
||
5.1.2.2. Using the suboption
|
||
|
||
Syntax:
|
||
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 (org) parameter
|
||
|
||
* n - use normal planes, i.e one whole plane after another
|
||
* 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.
|
||
* 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.
|
||
* 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, and
|
||
provides 16.8 million colours.
|
||
|
||
However, for monochrome modes, the (org) parameter has a different
|
||
meaning:
|
||
|
||
* n - use normal colours, i.e. 0 = white, 1 = black
|
||
* i - use inverted colours, i.e. 0 = black, 1 = white
|
||
|
||
The next important item about the video hardware is the base address
|
||
of the video memory. That is given by the (scrmem) parameter as a
|
||
hexadecimal number with an 0x prefix. You will need to find this out
|
||
from the documentation that comes with your external video hardware.
|
||
|
||
The next paramter (scrlen) tells the kernel about the size of the
|
||
video memory. If it's missing, this is calculated from the (xres),
|
||
and (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 (vgabase) parameter, otherwise, just leave it.
|
||
|
||
The (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 clear, (vgabase) is the base address, i.e
|
||
a 4k aligned address. For reading/writing the colour registers, the
|
||
kernel uses the address range between (vgabase) + 0x3c7 and (vgabase)
|
||
+ 0x3c9. This parameter is given in hexadecimal and must have a 0x
|
||
prefix, just like (scrmem). (colw) is only meaningful, if the
|
||
(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.
|
||
|
||
(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.
|
||
________________________________________________________________
|
||
|
||
5.2. Amiga platforms
|
||
|
||
This section describes the options for Amigas, which are quite
|
||
similar to those of the Atari platform
|
||
________________________________________________________________
|
||
|
||
5.2.1. What modes are available?
|
||
|
||
This depends on the chipset used in the Amiga. There are three main
|
||
ones; OCS, ECS and AGA which all uses the colour frame buffers.
|
||
|
||
* NTSC modes
|
||
*
|
||
+ ntsc - 640x200
|
||
+ ntsc-lace - 640x400
|
||
* PAL modes
|
||
*
|
||
+ pal - 640x256
|
||
+ pal-lace - 640x512
|
||
* ECS modes - 2 bit colours on ECS chipsets, 8 bit colours on AGA
|
||
chipsets only
|
||
*
|
||
+ multiscan - 640x480
|
||
+ multiscan-lace - 640x960
|
||
+ euro36 - 640x200
|
||
+ euro36-lace - 640x400
|
||
+ euro72 - 640x480
|
||
+ euro72-lace - 640x800
|
||
+ super72 - 800x300
|
||
+ super72-lace - 800x400
|
||
+ dblntsc - 640x200
|
||
+ dblpal - 640x256
|
||
+ dblntsc-ff - 640x400
|
||
+ dblntsc-lace - 640x800
|
||
+ dblpal-ff - 640x512
|
||
+ dblpal-lace - 640x1024
|
||
* VGA modes - 2 bit colours on ECS chipsets, 8 bit colours on AGA
|
||
chipsets
|
||
*
|
||
+ vga - 640x480
|
||
+ vga70 - 640x400
|
||
________________________________________________________________
|
||
|
||
5.2.2. Additional suboptions
|
||
|
||
These are similar to the Atari suboptions. They are:
|
||
|
||
* depth - specifies the pixel bit depth
|
||
* inverse - does the same thing as the Atari suboption
|
||
* font - does the same thing as the Atari suboption, although the
|
||
PEARL8x8 font is used instead of the VGA8x8 font if the display
|
||
size is less than 400 pixels wide.
|
||
* monitorcap - specifies the capabilities of the multisync monitor.
|
||
Do not use with fixed sync monitors
|
||
________________________________________________________________
|
||
|
||
5.2.3. Supported Amiga graphic expansion boards
|
||
|
||
* Phase5 CyberVision 64 (S3 Trio64 chipset)
|
||
* Phase5 CyberVision 64 3D (S3 ViRGE chipset)
|
||
* MacroSystems Retina Z3 (NCR 77C32BLT chipset)
|
||
* Helfrich Piccolo, SD64, GVP ECS Spectrum, Village Tronic Picasso
|
||
II / II+ and IV (Cirrus Logic GD542x / 543x chipsets)
|
||
________________________________________________________________
|
||
|
||
5.2.4. Macintosh platforms
|
||
|
||
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.
|
||
|
||
Framebuffer suboptions are selected using the following syntax:
|
||
|
||
video=macfb:<font>:<inverse>
|
||
|
||
You can select fonts such as VGA8x8, VGA8x16 and 6x11 etc. The
|
||
inverse option allows you to use reverse video.
|
||
________________________________________________________________
|
||
|
||
6. Using framebuffer devices on PowerPC platforms
|
||
|
||
The author would love to receive information on the use of
|
||
framebuffer device drivers on this platform.
|
||
________________________________________________________________
|
||
|
||
7. Using framebuffer devices on Alpha platforms
|
||
|
||
7.1. What modes are available?
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
7.2. Which graphic cards can work on Alpha?
|
||
|
||
This lists all the graphic cards that are known to work:
|
||
|
||
* DEC TGA PCI (DEC21030) - 640x480 & 8 bits or 24 / 32 bits
|
||
versions
|
||
________________________________________________________________
|
||
|
||
8. Using framebuffer devices on SPARC platforms
|
||
|
||
8.1. Which graphic cards can work on the SPARC
|
||
|
||
This lists all the graphic cards available:
|
||
|
||
* MG1 / MG2 - SBus or integrated on Sun3 - max 1600 x 1200 & mono
|
||
(BWtwo)
|
||
* CGthree - Similar to MG1 / MG2 but supports colour
|
||
* GX - SBus - max. 1152 x 900 & 8 bit (CGsix)
|
||
* TurboGX - SBus - max. 1152 x 900 & 8 bit (CGsix)
|
||
* SX (SS10 / SS20 only) - max. 1280 x 1024 & 24 bit (CGfourteen)
|
||
* ZX (TZX) - SBus - accelerated 24 bit 3D card (Leo)
|
||
* TCX (Sparc 4 only) - max 1280 x 1024 & 8 bit
|
||
* TCX (Sparc 5 only) - max 1152 x 900 & 24 bit
|
||
* Creator - SBus - max 1280 x 1024 & 24 bit (FFB
|
||
* Creator3D - SBus - max 1920 x 1200 & 24 bit (FFB
|
||
* ATI Mach64 - PCI - accelerated 8 / 24 bit UltraSparc only
|
||
|
||
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
|
||
[http://c3-a.snvl1.sfba.home.com/Framebuffer.html]
|
||
http://c3-a.snvl1.sfba.home.com/Framebuffer.html
|
||
________________________________________________________________
|
||
|
||
8.2. Configuring the framebuffer devices
|
||
|
||
During make config, you need to choose whether to compile promcon and
|
||
/ or fbcon. You can select both, but if you do this, you will need to
|
||
set the kernel flags to select the device. fbcon always takes
|
||
precedence if not set. If promcon is not selected in, on boot up, it
|
||
defaults to dummycon. If promcon is selected, it will use this
|
||
device. Once the buses are booted, and fbcon is compiled in, the
|
||
kernel probes for the above framebuffers and will use fbcon. If there
|
||
is no framebuffer devices, it will default to promcon
|
||
|
||
Here are the kernel options
|
||
|
||
* video=sbus:options
|
||
*
|
||
+ where options is a comma separated list:
|
||
+
|
||
o nomargins - sets margins to 0, 0
|
||
o margins=12x24 - sets margins to 12, 24 (default is
|
||
computed from resolution)
|
||
o off - don't probe for any SBus / UPA framebuffers
|
||
o font=SUN12x22 - use a specific font
|
||
|
||
So for example, booting with video=sbus:nomargins,font=SUN12x22 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.
|
||
|
||
If you want to use the SUN12x22 font, you need to enable it during
|
||
make config (disable the fontwidth != 8 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.
|
||
|
||
It is recommended that you grab a recent consoletools packages.
|
||
________________________________________________________________
|
||
|
||
9. Using framebuffer devices on MIPS platforms
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
10. Using framebuffer devices on ARM platforms
|
||
|
||
10.1. Netwinders
|
||
|
||
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]
|
||
________________________________________________________________
|
||
|
||
10.2. Acorn Archimedes
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
10.3. Other ARM ports (SA7710s et. al.)
|
||
|
||
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!]
|
||
________________________________________________________________
|
||
|
||
11. Using multi-headed framebuffers
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.1. Introduction
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.2. Feedback
|
||
|
||
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>.
|
||
________________________________________________________________
|
||
|
||
11.3. Contributors
|
||
|
||
The following people have contributed to this mini-HOWTO.
|
||
|
||
* Petr Vandrovec
|
||
* Andreas Ehliar (x2x)
|
||
* Marco Bizzarri (multiple X servers)
|
||
________________________________________________________________
|
||
|
||
11.4. Standard Disclaimer
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.5. Copyright Information
|
||
|
||
This section of the document is copyrighted <20> 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>
|
||
________________________________________________________________
|
||
|
||
11.6. What hardware is supported?
|
||
|
||
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 adapters among
|
||
others. This for text only second head support.
|
||
|
||
Note: it's only the second adapter that has to be one of the above.
|
||
________________________________________________________________
|
||
|
||
11.7. Commercial support
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.8. Getting all the stuff
|
||
|
||
You'll need the following patches and programs:
|
||
|
||
* fbset program - try [http://www.cs.kuleuven.ac.be/~geert/bin/]
|
||
http://www.cs.kuleuven.ac.be/~geert/bin/ (note: RedHat 6.0
|
||
already has this program included)
|
||
* fbaddon Matrix dual head patches for Linux kernel - try
|
||
[ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/]
|
||
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
|
||
* con2fb program - try
|
||
[ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/]
|
||
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/
|
||
* The X11 frame buffer server XF86_FBDev. This is a standard part
|
||
of XFree86 3.3.1.
|
||
________________________________________________________________
|
||
|
||
11.9. Getting Started
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.9.1. Move a console over...
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.9.2. Use "" to adjust the settings on this second display
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.9.3. Set up X for framebuffer support.
|
||
|
||
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:
|
||
|
||
# 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
|
||
|
||
Use the "default" modes as I don't think any other ones will work
|
||
with the Matrox frame buffer.
|
||
________________________________________________________________
|
||
|
||
11.9.4. Try starting the X server on the second display
|
||
|
||
Set the environment 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.
|
||
________________________________________________________________
|
||
|
||
11.10. Summary
|
||
|
||
The steps involved in getting a X server running on a second display
|
||
can be summrized as follows:
|
||
|
||
* Get the kernel patch, fbset and con2fb
|
||
* Patch the kerenl, configure, rebuild and reboot
|
||
* Add XF86_FBDev section to XF86Config file and set X symbolic 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 csh alias to start up X on a
|
||
second fixed frequency monitor:
|
||
|
||
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. "
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.11. Other Notes and Problems
|
||
|
||
* Both "fbset" and "startx" 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.
|
||
* 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 driver is unaccelerated. However, there are
|
||
patches for accelerated Matrox support at
|
||
[http://www.in-berlin.de/User/kraxel/xfree86/]
|
||
http://www.in-berlin.de/User/kraxel/xfree86/
|
||
________________________________________________________________
|
||
|
||
11.11.1. Getting "" (i.e. / ) to work
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.11.2. Using the "" program
|
||
|
||
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: [http://ftp.digital.com/pub/DEC/SRC/x2x/]
|
||
http://ftp.digital.com/pub/DEC/SRC/x2x/ It's also an optional Debian
|
||
package. I haven't tried it yet but some users have reported success.
|
||
________________________________________________________________
|
||
|
||
11.11.3. Other useful commands
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
11.12. Appendix A. Octave "" script
|
||
|
||
(note the bpp settings)
|
||
|
||
#!/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");
|
||
________________________________________________________________
|
||
|
||
11.13. Appendix B. Bourne Shell "" script
|
||
|
||
(This calls the octave script "cvtmode")
|
||
|
||
#!/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
|
||
________________________________________________________________
|
||
|
||
12. Using / Changing Fonts
|
||
|
||
To get the capability to change fonts, you need kbd-0.99. You may
|
||
obtain this from [ftp://ftp.win.tue.nl/pub/linux/utils/kbd]
|
||
ftp://ftp.win.tue.nl/pub/linux/utils/kbd
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
13. Changing Console Modes
|
||
|
||
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
|
||
[http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz]
|
||
http://www.cs.kuleuven.ac.be/~geert/bin/fbset-19990118.tar.gz. This
|
||
comes with a full set of instructions on how to operate this.
|
||
________________________________________________________________
|
||
|
||
14. Setting up the X11 FBdev driver
|
||
|
||
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.
|
||
|
||
Go to [http://www.xfree86.org] http://www.xfree86.org, and download
|
||
the latest XServer sources archive, unpack, and configure the
|
||
drivers, following these steps:
|
||
|
||
* Edit xc/config/cf/xf86site.def, uncomment the #define for
|
||
XF68FBDevServer
|
||
* Comment out all references to FB_VISUAL_STATIC_DIRECTCOLOR, 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.
|
||
* Edit xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_io.c,
|
||
and change K_RAW to K_MEDIUMRAW
|
||
|
||
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.
|
||
|
||
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:
|
||
[http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.gz]
|
||
http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.gz. For glibc2,
|
||
download from these URLs
|
||
([http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.libc6.gz]
|
||
http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.libc6.gz or [
|
||
http://pobox.com/~brion/linux/fbxserver.html]
|
||
http://pobox.com/~brion/linux/fbxserver.html
|
||
|
||
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 Matrox G200
|
||
et. al.
|
||
|
||
To configure the XF86_FBdev driver with your X11 system, you'll need
|
||
to edit your XF86Config for the following:
|
||
|
||
Section "Screen" Driver "FBDev" Device "Primary Card" Monitor
|
||
"Primary Monitor" SubSection "Display" Modes "default" EndSubSection
|
||
EndSection
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
! 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
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
15. How do I convert XFree86 mode-lines into framebuffer device timings?
|
||
|
||
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.
|
||
|
||
The framebuffer device requires the following fields:
|
||
|
||
* pixclock - pixel clock in pico seconds
|
||
* left_margin - time between sync to display
|
||
* right_margin - time between display to sync
|
||
* upper_margin - time between sync to display
|
||
* lower_margin - time between display to sync
|
||
* hsync_len - horizontal sync length
|
||
* vsync_len - vertical sync length
|
||
|
||
An XFree86 mode line has the following fields:
|
||
|
||
* Modeline "1280x1024" DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
|
||
|
||
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:
|
||
|
||
* Modeline "1280x1024" 110.0 1280 1328 1512 1712 1024 1025 1028
|
||
1054
|
||
|
||
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
|
||
|
||
Now we need to calculate the horizontal timings:
|
||
|
||
* left_margin = HFL - SH2
|
||
* right_margin = SH1 - HR
|
||
* hsync_len = SH2 - SH1
|
||
|
||
In our example, this would be:
|
||
|
||
* left_margin = 1712 - 1512 = 200
|
||
* right_margin = 1328 - 1280 = 48
|
||
* hsync_len = 1512 - 1328 = 184
|
||
|
||
And now we need to calculate the vertical timings.
|
||
|
||
* upper_margin = VFL - SV2
|
||
* lower_margin = SV1 - VR
|
||
* vsync_len = SV2 - SV1
|
||
|
||
For our example, this would be:
|
||
|
||
* upper_margin = 1054 - 1028 = 26
|
||
* lower_margin = 1025 - 1024 = 1
|
||
* vsync_len = 1028 - 1025 = 3
|
||
|
||
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:
|
||
|
||
* video=matrox:xres:<>,yres:<>,depth:<>,left:<>,right:<>,hslen:<>,u
|
||
pper:<>,lower:<>,vslen:<>
|
||
|
||
I put into my /etc/lilo.conf the following line:
|
||
|
||
* append =
|
||
"video=matroxfb:xres:1280,yres:1024,depth:32,left:200,right:48,hs
|
||
len:184,upper:26,lower:0,vslen:3"
|
||
|
||
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.
|
||
________________________________________________________________
|
||
|
||
16. Changing the Linux Logo
|
||
|
||
It can be customised by changing the file linux_logo.h in
|
||
include/linux directory. It is a C header file, and pretty hard to
|
||
change by hand, however there is a plugin available for Gimp from
|
||
[http://registry.gimp.org/detailview.phtml?plugin=Linux+Logo]
|
||
http://registry.gimp.org/detailview.phtml?plugin=Linux+Logo 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
|
||
($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.
|
||
________________________________________________________________
|
||
|
||
17. Looking for further information
|
||
|
||
For those of you interested in working with the framebuffer drivers,
|
||
point your web browser at [http://www.linux-fbdev.org]
|
||
http://www.linux-fbdev.org for more information on programming.
|
||
|
||
Parlez-vous Francais? There is a translation at
|
||
[http://www.freenix.org/unix/linux/HOWTO/mini/Vesafb.html]
|
||
http://www.freenix.org/unix/linux/HOWTO/mini/Vesafb.html
|