The Frame Buffer Device¶

Last revised: May 10, 2001

0. Introduction¶

The frame buffer device provides an abstraction for the graphics hardware. It represents the frame buffer of some video hardware and allows application software to access the graphics hardware through a well-defined interface, so the software doesn’t need to know anything about the low-level (hardware register) stuff.

The device is accessed through special device nodes, usually located in the /dev directory, i.e. /dev/fb*.

1. User’s View of /dev/fb*¶

From the user’s point of view, the frame buffer device looks just like any other device in /dev. It’s a character device using major 29; the minor specifies the frame buffer number.

By convention, the following device nodes are used (numbers indicate the device minor numbers):

For backwards compatibility, you may want to create the following symbolic links:

The frame buffer devices are also normal memory devices, this means, you can read and write their contents. You can, for example, make a screen snapshot by:

There also can be more than one frame buffer at a time, e.g. if you have a graphics card in addition to the built-in hardware. The corresponding frame buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.

Application software that uses the frame buffer device (e.g. the X server) will use /dev/fb0 by default (older software uses /dev/fb0current). You can specify an alternative frame buffer device by setting the environment variable $FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash users):

or (for csh users):

After this the X server will use the second frame buffer.

2. Programmer’s View of /dev/fb*¶

As you already know, a frame buffer device is a memory device like /dev/mem and it has the same features. You can read it, write it, seek to some location in it and mmap() it (the main usage). The difference is just that the memory that appears in the special file is not the whole memory, but the frame buffer of some video hardware.

/dev/fb* also allows several ioctls on it, by which lots of information about the hardware can be queried and set. The color map handling works via ioctls, too. Look into
for more information on what ioctls exist and on which data structures they work. Here’s just a brief overview:

You can request unchangeable information about the hardware, like name, organization of the screen memory (planes, packed pixels, …) and address and length of the screen memory.

You can request and change variable information about the hardware, like visible and virtual geometry, depth, color map format, timing, and so on. If you try to change that information, the driver maybe will round up some values to meet the hardware’s capabilities (or return EINVAL if that isn’t possible).

You can get and set parts of the color map. Communication is done with 16 bits per color part (red, green, blue, transparency) to support all existing hardware. The driver does all the computations needed to apply it to the hardware (round it down to less bits, maybe throw away transparency).

All this hardware abstraction makes the implementation of application programs easier and more portable. E.g. the X server works completely on /dev/fb* and thus doesn’t need to know, for example, how the color registers of the concrete hardware are organized. XF68_FBDev is a general X server for bitmapped, unaccelerated video hardware. The only thing that has to be built into application programs is the screen organization (bitplanes or chunky pixels etc.), because it works on the frame buffer image data directly.

For the future it is planned that frame buffer drivers for graphics cards and the like can be implemented as kernel modules that are loaded at runtime. Such a driver just has to call register_framebuffer() and supply some functions. Writing and distributing such drivers independently from the kernel will save much trouble…

3. Frame Buffer Resolution Maintenance¶

Frame buffer resolutions are maintained using the utility fbset . It can change the video mode properties of a frame buffer device. Its main usage is to change the current video mode, e.g. during boot up in one of your /etc/rc.* or /etc/init.d/* files.

Fbset uses a video mode database stored in a configuration file, so you can easily add your own modes and refer to them with a simple identifier.

4. The X Server¶

The X server (XF68_FBDev) is the most notable application program for the frame buffer device. Starting with XFree86 release 3.2, the X server is part of XFree86 and has 2 modes:

If the Display subsection for the fbdev driver in the /etc/XF86Config file contains a:

line, the X server will use the scheme discussed above, i.e. it will start up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You still have to specify the color depth (using the Depth keyword) and virtual resolution (using the Virtual keyword) though. This is the default for the configuration file supplied with XFree86. It’s the most simple configuration, but it has some limitations.

Therefore it’s also possible to specify resolutions in the /etc/XF86Config file. This allows for on-the-fly resolution switching while retaining the same virtual desktop size. The frame buffer device that’s used is still /dev/fb0current (or $FRAMEBUFFER), but the available resolutions are defined by /etc/XF86Config now. The disadvantage is that you have to specify the timings in a different format (but fbset -x may help).

To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn’t work 100% with XF68_FBDev: the reported clock values are always incorrect.

5. Video Mode Timings¶

A monitor draws an image on the screen by using an electron beam (3 electron beams for color models, 1 electron beam for monochrome monitors). The front of the screen is covered by a pattern of colored phosphors (pixels). If a phosphor is hit by an electron, it emits a photon and thus becomes visible.

The electron beam draws horizontal lines (scanlines) from left to right, and from the top to the bottom of the screen. By modifying the intensity of the electron beam, pixels with various colors and intensities can be shown.

After each scanline the electron beam has to move back to the left side of the screen and to the next line: this is called the horizontal retrace. After the whole screen (frame) was painted, the beam moves back to the upper left corner: this is called the vertical retrace. During both the horizontal and vertical retrace, the electron beam is turned off (blanked).

The speed at which the electron beam paints the pixels is determined by the dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions of cycles per second), each pixel is 35242 ps (picoseconds) long:

If the screen resolution is 640×480, it will take:

to paint the 640 (xres) pixels on one scanline. But the horizontal retrace also takes time (e.g. 272 pixels ), so a full scanline takes:

We’ll say that the horizontal scanrate is about 31 kHz:

A full screen counts 480 (yres) lines, but we have to consider the vertical retrace too (e.g. 49 lines ). So a full screen will take:

The vertical scanrate is about 59 Hz:

This means the screen data is refreshed about 59 times per second. To have a stable picture without visible flicker, VESA recommends a vertical scanrate of at least 72 Hz. But the perceived flicker is very human dependent: some people can use 50 Hz without any trouble, while I’ll notice if it’s less than 80 Hz.

Since the monitor doesn’t know when a new scanline starts, the graphics board will supply a synchronization pulse (horizontal sync or hsync) for each scanline. Similarly it supplies a synchronization pulse (vertical sync or vsync) for each new frame. The position of the image on the screen is influenced by the moments at which the synchronization pulses occur.

The following picture summarizes all timings. The horizontal retrace time is the sum of the left margin, the right margin and the hsync length, while the vertical retrace time is the sum of the upper margin, the lower margin and the vsync length:

The frame buffer device expects all horizontal timings in number of dotclocks (in picoseconds, 1E-12 s), and vertical timings in number of scanlines.

6. Converting XFree86 timing values info frame buffer device timings¶

An XFree86 mode line consists of the following fields:

The frame buffer device uses the following fields:

pixclock: pixel clock in ps (pico seconds)

left_margin: time from sync to picture

right_margin: time from picture to sync

upper_margin: time from sync to picture

lower_margin: time from picture to sync

hsync_len: length of horizontal sync

vsync_len: length of vertical sync

fb: in picoseconds (ps)

pixclock = 1000000 / DCF

left_margin = HFL — SH2

right_margin = SH1 — HR

hsync_len = SH2 — SH1

upper_margin = VFL — SV2

lower_margin = SV1 — VR

vsync_len = SV2 — SV1

Good examples for VESA timings can be found in the XFree86 source tree, under “xc/programs/Xserver/hw/xfree86/doc/modeDB.txt”.

7. References¶

For more specific information about the frame buffer device and its applications, please refer to the Linux-fbdev website:

and to the following documentation:

The manual pages for fbset: fbset(8), fb.modes(5)

The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)

Источник

Framebuffer (Linux)

Contents

Attention: this article used to describe a lot of information about display timings and resolution. The content has been moved to a generic article: Display Outputs, Resolution and Timings.

Warning: this article is not maintained anymore and is kept for reference only.

Introduction

The framebuffer (fbdev) is a character device providing access to graphics hardware. Beside the framebuffer, other interfaces exist to access graphics hardware such as the DRI (direct rendering interface) or proprietary interfaces (NVIDIA drivers). Typically, the framebuffer doesn’t support any 2D/3D hardware acceleration.

The i.MX 6 kernel comes with an open source fbdev driver called mxcfb. The X-Server driver is closed source and called vivante.

The i.MX 7 and i.MX 6ULL kernels come with an open source fbdev driver, mxsfb.

Our Tegra kernel comes with an open source fbdev driver called tegrafb. In contrast, the X-Server driver, just called tegra, is available as binary driver only.

The Vybrid kernel 4.1 and older come with a fbdev driver called dcu. Kernels 4.4 and newer come with a DRM driver which supports the fbdev interface via fbdev emulation.

Framebuffer Console

All modules use by default the kernel internal fbdev based console which displays the kernel and system log messages as well as the virtual terminals. Since the fbdev console is initialized by the kernel early during boot up, it can be used to show a splash screen (rather then a console). Refer to the Splash Screen (Linux) article for detailed instructions.

Disable Framebuffer Console

To disable console messages on the screen remove the «console=tty1» kernel command line parameter from the setup environment variable in U-Boot. The content of setup is module specific, use print to show the initial content:

Note: If you also remove the console= entry for the serial console Linux will fallback to the framebuffer console again. Use and invalid console (e.g. console=null ) or remove framebuffer console support from the kernel (see below) to work around this.

systemd still initialize a getty on tty1. This can be easily disabled using:

Remove Framebuffer Console

To get rid of console messages and any system output, the framebuffer console support can be removed from the kernel entirely by removing the kernel configuration «CONFIG_FRAMEBUFFER_CONSOLE».

Redirect Framebuffer Console

The environment variable fbcon can be used to specify the fbdev device used for the console. Use the following command to use fb1 as console:

To switch the console after boot one can use the con2fbmap tool which can easily be built using OpenEmbedded. Switching as follows:

More information about the fbdev console can be found in the kernel documentation:

Tegra Console Output

BSP v2.0 and higher provide by default a console via DVI-A/LVDS/RGB/VGA (LVDS-1 in X-Server terms) and optionally via DVI-D (HDMI-1 in X-Server terms). To activate the framebuffer console during boot on DVI-D instead of VGA one just has to set fbcon=map:1 in U-Boot as follows:

On Apalis T30 we are using the HDMI interface for the framebuffer console by default as unfortunately VGA is not supported on NVIDIA’s Tegra 3 SoC. To switch it back to parallel RGB (e.g. when using an LVDS or parallel RGB display) proceed as follows:

Console Configuration

The utility setterm (available in the util-linux package) allows to configure the framebuffer console.

Note: Some commands are only available on the framebuffer console itself (and not from a SSH session).

For particular interest might be the power saving configurations such as powersave and blank. Using the blank parameter, one can define the time until the console turns black (in minutes, 0 means never). Using the powersave command, one can define the time until the framebuffer driver disables the output completely (after being in blank state, in minutes, 0 means immediately after going to blank mode).

There is also a Kernel boot parameter to configure console blanking called consoleblank (blanking time in seconds, 0 means never). To disable the blinking cursor, one can use the vt.global_cursor_default kernel parameter. Use the U-Boot console to configure the boot parameter:

Cairo Example

Cairo is a library which provides primitives for two dimensional drawing. This can be used to draw text and images on a framebuffer device.

Below is the Makefile which can be used for building the above example code with make cairo assuming the SDK is setup as described in Linux SDKs article.

Note: All command lines must start with a tab instead of spaces in a Makefile

Please refer the Cairo documentation and samples.

Источник

Framebuffer HOWTO

Alex Buell, alex.buell@tahallah.clara.co.uk

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.

19990607 — Release of 1.0

19990722 — Release of 1.1

20000222 — Release of 1.2

Thanks go to these people listed below who helped improve the Framebuffer HOWTO.

• Jeff Noxon jeff@planetfall.com
• Francis Devereux f.devereux@cs.ucl.ac.uk
• Andreas Ehliar ehliar@futurniture.se
• Martin McCarthy marty@ehabitat.demon.co.uk
• Simon Kenyon simon@koala.ie
• David Ford david@kalifornia.com
• Chris Black cblack@cmpteam4.unil.ch
• N Becker nbecker@fred.net
• Bob Tracy rct@gherkin.sa.wlk.com
• Marius Hjelle marius.hjelle@roman.uib.no
• James Cassidy jcassidy@misc.dyn.ml.org
• Andreas U. Trottmann andreas.trottmann@werft22.com
• Lech Szychowski lech7@lech.pse.pl
• Aaron Tiensivu tiensivu@pilot.msu.edu
• Jan-Frode Myklebust for his info on permedia cards janfrode@ii.uib.no
• Many others too numerous to add, but thanks!

Thanks go to Rick Niles 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:

• Brion Vibber brion@pobox.com
• Gerd Knorr kraxel@cs.tu-berlin.de

and of course the authors of the framebuffer devices:

• Martin Schaller — original author of the framebuffer concept
• Roman Hodek Roman.Hodek@informatik.uni-erlangen.de
• Andreas Schwab schwab@issan.informatik.uni-dortmund.de
• Guenther Kelleter
• Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
• Roman Zippel roman@sodom.obdg.de
• Pavel Machek pavel@atrey.karlin.mff.cuni.cz
• Gerd Knorr kraxel@cs.tu-berlin.de
• Miguel de Icaza miguel@nuclecu.unam.mx
• David Carter carter@compsci.bristol.ac.uk
• William Rucklidge wjr@cs.cornell.edu
• Jes Sorensen jds@kom.auc.dk
• Sigurdur Asgeirsson
• Jeffrey Kuskin jsk@mojave.stanford.edu
• Michal Rehacek michal.rehacek@st.mff.cuni.edu
• Peter Zaitcev zaitcev@lab.ipmce.su
• David S. Miller davem@dm.cobaltmicro.com
• Dave Redman djhr@tadpole.co.uk
• Jay Estabrook
• Martin Mares mj@ucw.cz
• Dan Jacobowitz dan@debian.org
• Emmanuel Marty core@ggi-project.org
• Eddie C. Dost ecd@skynet.be
• Jakub Jelinek jj@ultra.linux.cz
• Phil Blundell philb@gnu.org
• Anyone else, stand up and be counted. :o)

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]

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.

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.

• 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)
• 2.1.107 — introduced Intel 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) and atyfb(ATI).

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.

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 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

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.

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)

Reboot the kernel, and as a simple test, try entering 0301 at the VGA prompt (this will give you 640×480 @ 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 1280×1024 @ 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.

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)

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.

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 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
• Select 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.

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!

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 12×22 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

The line «pm2fb:mode:1024×768-75,font:SUN12x22,ypan» indicates you are selecting a 1024×768 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:

where option is one of the following

• off to disable the driver.
• 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:
  • 640×480-(60,72,75,90,100)
  • 800×600-(56,60,70,72,75,90,100)
  • 1024×768-(60,70,72,75,90,100,illo) illo=80KHz 100Hz
  • 1152×864-(60,70,75,80)
  • 1280×1024-(60,70,74,75)
  • 1600×1200-(60,66,76)

• The default resolution is 640×480-60.
• font:font name to set the console font. Example: font:SUN12x22
• ypan sets the current virtual height as big as video memory size permits.
• oldmem this option is for CybervisionPPC users only. Specify this if your board has Fujitsu SGRAMs mounted on (all CVisionPPCs before 30-Dec-1998).
• virtual (temporary) specify this if the kernel remaps the PCI regions on your platform.

[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 12×22 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

The line «atyfb:mode:1024×768,font:SUN12x22» indicates you are selecting a 1024×768 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)

where option is one of the following

• font:STRING selects the built-in font (compiled into the kernel)
• noblink Turns off blinking
• noaccel Disables acceleration
• vram:ULONG Tells the atyfb driver how much memory you have
• pll:ULONG Unknown
• mclk:ULONG Unknown
• vmode:ULONG Unknown
• cmode:ULONG — sets depth — 0, 8, 15, 16, 24 and 32

This lists all the graphic cards that are known to work with the vesafb device:

• ATI PCI VideoExpression 2MB (max. 1280×1024 @ 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. 1600×1200 @ 8bit)
• Voodoo2 2000

This list is composed of on-board chipsets on systems’ motherboards:

This list below blacklists graphic cards that doesn’t work with the vesafb device:

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.

[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 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’

This section describes framebuffer options on Atari m68k platforms.

ttlow, ttmid and tthigh are only used by the TT, whilst vga2, vga4, vga15, vga256, falh3 and falh16 are only used by 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:

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 640×480 display.

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!

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]

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 — gives you 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) , (yres) 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.

(coltype) is used with the (vgabase) parameter, it tells the kernel about the colour register model of your graphic board. Currently the types supported are vga and mv300 . vga is the default.

(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.

This section describes the options for Amigas, which are quite similiar to that for the Atari m68k platforms.

This depends on the chipset used in the Amiga. There are three main ones; OCS, ECS and AGA which all uses the colour frame buffer device.

• NTSC modes
  • ntsc — 640×200
  • ntsc-lace — 640×400

• PAL modes
  • pal — 640×256
  • pal-lace — 640×512

• ECS modes — 2 bit colours on ECS, 8 bit colours on AGA chipsets only.
  • multiscan — 640×480
  • multiscan-lace — 640×960
  • euro36 — 640×200
  • euro36-lace — 640×400
  • euro72 — 640×400
  • euro72-lace — 640×800
  • super72 — 800×300
  • super72-lace — 800×600
  • dblntsc — 640×200
  • dblpal — 640×256
  • dblntsc-ff — 640×400
  • dblntsc-lace — 640×800
  • dblpal-ff — 640×512
  • dblpal-lace — 640×1024

• VGA modes — 2 bit colours on ECS, 8 bit colours on AGA chipsets only.
  • vga — 640×480
  • vga70 — 640×400

These are similar to the Atari m68k 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 VGA8x8 font, if the display size is less than 400 pixel wide.
• monitorcap — specifies the capabilities of the multisync monitor. Do not use with fixed sync monitors.

• Phase5 CyberVision 64 (S3 Trio64 chipset)
• Phase5 CyverVision 64-3D (S3 ViRGE chipset)
• MacroSystems RetinaZ3 (NCR 77C32BLT chipset)
• Helfrich Piccolo, SD64, GVP ECS Spectrum, Village Tronic Picasso II II+ and IV/ (Cirrus Logic GD542x/543x)

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

You can select fonts such as VGA8x8, VGA8x16 and 6×11 etc. The inverse option allows you to use reverse video.

The author would love to receive information on the use of framebuffers on this platform.

So far, there is only the TGA PCI card — which only does 80×30 with a resolution of 640×480 at either 8 bits or 24/32 bits.

This lists all the graphic cards that are known to work:

• DEC TGA PCI (DEC21030) — 640×480 @ 8 bit or 24/32 bit versions

This lists all the graphic cards available:

• MG1/MG2 — SBus or integrated on Sun3 — max. 1600×1280 @ mono (BWtwo)
• CGthree — Similar to MG1/MG2 but supports colour — max resolution ?
• GX — SBus — max. 1152×900 @ 8bit (CGsix)
• TurboGX — SBus — max. 1152×900 @ 8 bit (CGsix)
• SX — SS10/SS20 only — max. 1280×1024 @ 24 bit — (CGfourteen)
• ZX(TZX) — SBus — accelerated 24bit 3D card — max resolution ? (Leo)
• TCX — AFX — for Sparc 4 only — max. 1280×1024 @ 8bit
• TCX(S24) — AFX — for Sparc 5 only — max. 1152×900 @ 24bit
• Creator — SBus — max. 1280×1024 @ 24bit (FFB)
• Creator3D — SBus — max. 1920×1200 @ 24bit (FFB)
• ATI Mach64 — accelerated 8/24bit for Sparc64 PCI 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

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

So for example, booting with gives you a nice fast text console with a text resolution of 96×40, looks similar to a Solaris console but with colours and virtual terminals just like on the Intel 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 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.

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 160×64. However, moves are afoot to rewrite the console code for these Indys, so keep an eye on this section.

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]

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.

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!]

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.

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.

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.

The following people have contributed to this mini-HOWTO.

* Petr Vandrovec vandrove@vc.cvut.cz

* Andreas Ehliar ehliar@lysator.liu.se (x2x)

* Marco Bizzarri m.bizzarri@icube.it (multiple X servers)

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.

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

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.

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.

You’ll need the following patches and programs:

* «fbset» program try: (note: this program comes with RedHat 6.0)

* «fbaddon» Matrox dual head patches for Linux kernel try:

* «con2fb» program try:

* The X11 frame buffer server XF86_FBDev. This is a standard part of XFree86 3.3.1.

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.

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.

Use «fbset» to adjust the setting on this second monitor

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.

Set up X for Frame Buffer 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:

Use the «default» modes as I don’t think any other one will work with the Matrox frame buffer.

Try starting the X server on the second monitor.

Set the variable FRAMEBUFFER to the second frame buffer.

«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.

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 1280×1024»

* 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:

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.

* 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

Getting «init level five» (i.e. xdm/gdm) 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 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.

Using the x2x 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: It’s also an optional Debian package. I haven’t tried it yet but some users have reported success.

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.

Appendix A. Octave cvtmode.m script

(note the bpp setting)

Appendix B. Borne Shell script «cvtfile»

(This calls the octave script «cvtmode»)

To get the capability to change fonts, you need kbd-0.99. You may obtain this from

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!).

To get the capability to change modes (i.e 640×480, 800×800 etc), you need fbset (currently fbset-19990118.tar.gz) — you may ftp it from:

This comes with a full set of instructions on how to operate this.

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 , and download the latest XServers source 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 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.
• 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 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:

For glibc2, download from these URLs.

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:

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.

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.

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

• pixclock — pixel clock in pico seconds
• left_margin — time fron sync to picture
• right_margin — time from picture to sync
• upper_margin — time from sync to picture
• lower_margin — time from picture to sync
• hsync_len — length of horizontal sync
• vsync_len — length of vertical sync

An XFree86 mode line has the following fields

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.

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, it requires:

I put in my /etc/lilo.conf the following line:

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.

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 that will create one for you. all you need is a picture 80×80 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.

For those of you interested in working with the framebuffer drivers, point your browser at for information on programming.

Источник