Framebuffer HOWTO英文

Framebuffer HOWTO
Alex Buell, [email protected]
v1.2, 27 Feb 2000

This document describes how to use the framebuffer devices in Linux witha variety of platforms. This also includes how to set up multi-headed displays.

1. History

2. Contributors

3. What is a framebuffer device?

4. What advantages does framebuffer devices have?

5. Using framebuffer devices on Intel platforms

* 5.1 What is vesafb?
* 5.2 How do I activate the vesafb drivers?
* 5.3 What VESA modes are available to me?
* 5.4 Got a Matrox card?
* 5.5 Got a Permedia card?
* 5.6 Got a ATI card?
* 5.7 Which graphic cards are VESA 2.0 compliant?
* 5.8 Can I make vesafb as a module?
* 5.9 How do I modify the cursor?

6. Using framebuffer devices on Atari m68k platforms

* 6.1 What modes are available on Atari m68k platforms?
* 6.2 Additional suboptions on Atari m68k platforms
* 6.3 Using the internal suboption on Atari m68k platforms
* 6.4 Using the external suboption on Atari m68k platforms

7. Using framebuffer devices on Amiga m68k platforms

* 7.1 What modes are available for Amiga m68k platforms?
* 7.2 Additional suboptions on Amiga m68k platforms
* 7.3 Supported Amiga graphic expansion boards

8. Using framebuffer devices on Macintosh m68k platforms

9. Using framebuffer devices on PowerPC platforms

10. Using framebuffer devices on Alpha platforms

* 10.1 What modes are available to me?
* 10.2 Which graphic cards can work with the frambuffer device?

11. Using framebuffer devices on SPARC platforms

* 11.1 Which graphic cards can work with the framebuffer device?
* 11.2 Configuring the framebuffer devices

12. Using framebuffer devices on MIPS platforms

13. Using framebuffer devices on ARM platforms

* 13.1 Netwinders
* 13.2 Acorn Archimedes
* 13.3 Other ARM ports (SA 7110s et. al)

14. Using multi-headed framebuffers

* 14.1 Introduction
* 14.2 Feedback
* 14.3 Contributors
* 14.4 Standard Disclaimer
* 14.5 Copyright Information
* 14.6 What hardware is supported?
* 14.7 Commercial support
* 14.8 Getting all the stuff.
* 14.9 Getting Started
* 14.10 Summary
* 14.11 Other Notes and Problems

15. Using/Changing fonts

16. Changing console modes

17. Setting up the X11 FBdev driver

18. How do I convert XFree86 mode-lines into framebuffer device timings?

19. Changing the Linux logo

20. Looking for further information?
1. History

Revision history

19990607 - Release of 1.0

19990722 - Release of 1.1

20000222 - Release of 1.2
2. Contributors

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

* Jeff Noxon [email protected]
* Francis Devereux [email protected]
* Andreas Ehliar [email protected]
* Martin McCarthy [email protected]
* Simon Kenyon [email protected]
* David Ford [email protected]
* Chris Black [email protected]
* N Becker [email protected]
* Bob Tracy [email protected]
* Marius Hjelle [email protected]
* James Cassidy [email protected]
* Andreas U. Trottmann [email protected]
* Lech Szychowski [email protected]
* Aaron Tiensivu [email protected]
* Jan-Frode Myklebust for his info on permedia cards [email protected]
* Many others too numerous to add, but thanks!

Thanks go to Rick Niles [email protected] 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 theXF86_FBdev X11 framebuffer driver for X11 on Intel platforms:

* Brion Vibber [email protected]
* Gerd Knorr [email protected]

and of course the authors of the framebuffer devices:

* Martin Schaller - original author of the framebuffer concept
* Roman Hodek [email protected]
* Andreas Schwab [email protected]
* Guenther Kelleter
* Geert Uytterhoeven [email protected]
* Roman Zippel [email protected]
* Pavel Machek [email protected]
* Gerd Knorr [email protected]
* Miguel de Icaza [email protected]
* David Carter [email protected]
* William Rucklidge [email protected]
* Jes Sorensen [email protected]
* Sigurdur Asgeirsson
* Jeffrey Kuskin [email protected]
* Michal Rehacek [email protected]
* Peter Zaitcev [email protected]
* David S. Miller [email protected]
* Dave Redman [email protected]
* Jay Estabrook
* Martin Mares [email protected]
* Dan Jacobowitz [email protected]
* Emmanuel Marty [email protected]
* Eddie C. Dost [email protected]
* Jakub Jelinek [email protected]
* Phil Blundell [email protected]
* Anyone else, stand up and be counted. :o)

3. What is a framebuffer device?

A framebuffer device is an abstraction for the graphic hardware. Itrepresents the frame buffer of some video hardware, and allows applicationsoftware to access the graphic hardware through a well-defined interface,so that the software doesn't need to know anything about the low-levelinterface stuff [Taken from Geert Uytterhoeven's framebuffer.txt in thelinux kernel sources]

4. What advantages does framebuffer devices have?

Penguin logo. :o) Seriously, the major advantage of the framebuffer drivesis that it presents a generic interface across all platforms. It was thecase until late in the 2.1.x kernel development process that the Intelplatform had console drivers completely different from the other consoledrivers for other platforms. With the introduction of 2.1.109 all thishas changed for the better, and introduced more uniform handling of theconsole under the Intel platforms and also introduced true bitmappedgraphical consoles bearing the Penguin logo on Intel for the first time,and allowed code to be shared across different platforms. Note that 2.0.xkernels do not support framebuffer devices, but it is possible somedaysomeone 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 m68kplatforms does have the framebuffer device support included.

With the release of the 2.2.x kernel, framebuffer device support is very solidand stable. You should use the framebuffer device if your graphic card supportsit, if you are using 2.2.x kernels. Older 2.0.x kernels does not support framebufferdevices, at least on the Intel platform.

* 0.9.x (m68k) - introduced m68k framebuffer devices. Note that m68k 0.9.xis functionally equivalent to Intel 1.0.9 (plus 1.2.x enhancements)
* 2.1.107 - introduced Intel framebuffer/new console devices andadded 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 cangive generic options to the kernel at bootup-time, including optionsspecific to a particular framebuffer device. These are:

* video=xxx:off - disable probing for a particular framebufferdevice
* video=map:octal-number - maps the virtual consoles (VCs) toframebuffer (FB) devices
o video=map:01 will map VC0 to FB0, VC1 to FB1, VC2 to FB0, VC3to FB1..
o video=map:0132 will map VC0 to FB0, VC1 to FB1, VC2 to FB3, VC4to FB2, VC5 to FB0..

Normally framebuffer devices are probed for in the order specified in thekernel, but by specifying the video=xxx option, you can add thespecific framebuffer device you want probed before the others specified inthe kernel.

5. Using framebuffer devices on Intel platforms
5.1 What is vesafb?

Vesafb is a framebuffer driver for Intel architecture that works withVESA 2.0 compliant graphic cards. It is closely related to the framebufferdevice drivers in the kernel.

vesafb is a display driver that enables the use of graphical modes on yourIntel 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 toaccess every bit of the display. Historically, older graphic adapterscould allow the CPU to access only 64K at a time, hence the limitations ofthe dreadful CGA/EGA graphic modes! It may be that someone will write avesafb12 device driver for these cards, but this will use up preciouskernel memory and involve a nasty hack.

There is however a potential workaround to add VESA 2.0 extensions foryour legacy VESA 1.2 card. You may be able to download a TSR type programthat will run from DOS, and used in cojunction with loadlin, can helpconfigure the card for the appropriate graphic console modes. Note thatthis will not always work, as an example some Cirrus Logic cards such asthe VLB 54xx series are mapped to a range of memory addresses (forexample, within the 15MB-16MB range) for frame buffering which preludesthese from being used successfully with systems that have more than 32MBof memory. There is a way to make this work, i.e. if you have a BIOSoption to leave a memory hole at 15MB-16MB range, it might work, Linuxdoesn't support the use of memory holes. However there are patches forthis option though [Who has these and where do one gets them from?]. Ifyou wish to experiment with this option, there are plenty of TSR styleprograms available, a prime example is UNIVBE, which can be found on theInternet.

Alternatively, you may be able to download kernel patches to allow yourVESA 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

5.2 How do I activate the vesafb drivers?

Assuming you are using menuconfig, you will need to do the followingsteps:

If your processor (on Intel platforms) supports MTRRs, enable this. It speeds up memory copies between the processor and the graphic card, butnot 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 andor 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 pixeldrivers

VGA Chipset Support (text only) - vgafb - used to be part of the listabove, but it has been removed as it is now deprecated and no longersupported. It will be removed shortly. Use VGA Text Console (fbcon)instead. VGA Character/Attributes is only used with VGA ChipsetSupport, 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 thisautomatically if Advanced Low Level Drivers was selected for the firsttime. This no longer happens with 2.1.113.

There is also the option to compile in fonts into memory, but this isn'treally 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 tobuild them as modules yet - please correct me on this]

You'll need to create the framebuffer device in /dev. You need one perframebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0for the first one. Subsequent ones would be in multiples of 32, so for exampleto create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so onup to the eighth framebuffer device (mknod /dev/fb7 c 29 224)

Then rebuild the kernel, modify /etc/lilo.conf to include the VGA=ASKparameter, and run lilo, this is required in order for you to be able toselect the modes you wish to use.

Here's a sample LILO configuration (taken from my machine)

# LILO configuration fileboot = /dev/hda3delay = 30 promptvga = ASK # Let user enter the desired modesimage = /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 VGAprompt (this will give you 640x480 @ 256), and you should be able to see acute 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'tnecessary if you're using LILO.

Once you can see that's working well, you can explore the various VESAmodes (see below) and decide on the one that you like the best, andhardwire that into the "VGA=x" parameter in lilo.conf. When you havechosen the one you like the best, look up the equivalent hexadecimal numberfrom 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. Youwill need to pass to the kernel the option to enable it. Usevideo=vesa:ypan or video=vesa:ywrap to activate it. Both does the samething, but in different ways. ywrap is a lot faster than ypan but may notwork on slightly broken VESA 2.0 graphic cards. ypan is slower than ywrapbut a lot more compatible. This option is only present in kernel 2.1.116and above. Earlier kernels did not have the ability to allow scrollbackbuffering in vesafb.

5.3 What VESA modes are available to me?

This really depends on the type of VESA 2.0 compliant graphic card thatyou have in your system, and the amount of video memory available. This isjust 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 promptor for use with the LILO program. (actually these numbers are plus 0x200to make it easier to refer to the table)

Colours 640x400 640x480 800x600 1024x768 1152x864 1280x1024 1600x1200--------+-------------------------------------------------------------- 4 bits | ? ? 0x302 ? ? ? ? 8 bits | 0x300 0x301 0x303 0x305 0x161 0x307 0x31C15 bits | ? 0x310 0x313 0x316 0x162 0x319 0x31D16 bits | ? 0x311 0x314 0x317 0x163 0x31A 0x31E24 bits | ? 0x312 0x315 0x318 ? 0x31B 0x31F32 bits | ? ? ? ? 0x164 ?

Key: 8 bits = 256 colours, 15 bits = 32,768 colours, 16 bits = 65,536colours, 24 bits = 16.8 million colours, 32 bits - same as 24 bits, butthe extra 8 bits can be used for other things, and fits perfectly with a32 bit PCI/VLB/EISA bus.

Additional modes are at the discretion of the manufacturer, as the VESA2.0 document only defines modes up to 0x31F. You may need to do somefiddling around to find these extra modes.

5.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 capabilitiesof your card. Matroxfb will work with Matrox Mystique Millennium I & II, G100 and G200. It also supports multiheaded systems (that is, if you havetwo 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 BIOSupgrade from

http://www.matrox.com/mgaweb/drivers/ftp_bios.htm

Beware thatyou will need DOS to do this.

Go into the Code Maturity Level menu, and enable the prompt fordevelopment and/or incomplete drivers [note this may change for futurekernels - 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
o Millennium I/II support
o Mystique support
o 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 pixeldrivers

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 fileboot = /dev/hda3delay = 30 promptvga = 792 # You need to do this so it boots up in a sane state# Linux bootable partition config beginsimage = /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 perframebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0for the first one. Subsequent ones would be in multiples of 32, so for exampleto create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so onup to the eight framebuffer device (mknod /dev/fb7 c 29 224)

And that should be it! [NOTE: Is anyone using this multiheaded support, pleaseget in touch with me ASAP - I need to talk to you about it so I can document it!

5.5 Got a Permedia card?

Permedia cards cannot be used with the vesafb driver, but fortunately, thereis the Permedia framebuffer driver available to use. Assuming you are usingmenuconfig, do the following:

Go into the Code Maturity Level menu, and enable the prompt fordevelopment and/or incomplete drivers [note this may change for futurekernels - 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
o Select compiled-in fonts
o 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 fileboot = /dev/hda3delay = 30 promptvga = 792 # You need to do this so it boots up in a sane state# Linux bootable partition config beginsimage = /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 selectinga 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 perframebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0for the first one. Subsequent ones would be in multiples of 32, so for exampleto create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so onup 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

video=pm2fb:[option[,option[,option...]]]

where option is one of the following

* off to disable the driver.
* mode:resolution to set the console resolution. The modes have beentaken from the fb.modes.ATI file in Geert's fbset package. The depth forall the modes is 8bpp. This is the list of the available modes:
o 640x480-(60,72,75,90,100)
o 800x600-(56,60,70,72,75,90,100)
o 1024x768-(60,70,72,75,90,100,illo) illo=80KHz 100Hz
o 1152x864-(60,70,75,80)
o 1280x1024-(60,70,74,75)
o 1600x1200-(60,66,76)
* The default resolution is 640x480-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 ifyour board has Fujitsu SGRAMs mounted on (all CVisionPPCs before 30-Dec-1998).
* virtual (temporary) specify this if the kernel remaps the PCI regionson your platform.

5.6 Got a 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 fordevelopment and/or incomplete drivers [note this may change for futurekernels - 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
o Select compiled-in fonts
o Select Sparc console 12x22 font

Rebuild your kernel. Then you will need to modify your lilo.conf file toenable the atyfb device. The quickest and simplest way is re-use the following

# LILO configuration fileboot = /dev/hda3delay = 30promptvga = 792 # You need to do this so it boots up in a sane state# Linux bootable partition config beginsimage = /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 selectinga 1024x768 mode.

Lastly, you'll need to create the framebuffer device in /dev. You need one perframebuffer device, so all you need to do is to type in mknod /dev/fb0 c 29 0for the first one. Subsequent ones would be in multiples of 32, so for exampleto create /dev/fb1, you would need to type in mknod /dev/fb1 c 29 32, and so onup to the eight framebuffer device (mknod /dev/fb7 c 29 224)

video=atyfb:[option[,option[,option...]]]

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

5.7 Which graphic cards are VESA 2.0 compliant?

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

* 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 [email protected])
* 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 is composed of on-board chipsets on systems' motherboards:

* Trident Cyber9397
* SiS 5598

This list below blacklists graphic cards that doesn't work with the vesafbdevice:

* TBA

5.8 Can I make vesafb as a module?

As far as is known, vesafb can't be modularised, although at some pointin time, the developer of vesafb may decide to modify the sources formodularising. Note that even if modularising is possible, at boot timeyou will not be able to see any output on the display until vesafb ismodprobed. It's probably a lot wiser to leave it in the kernel, forthese cases when there are booting problems.

5.9 How do I modify the cursor?

[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 uglybugs in those miserable Trident cards--see #define TRIDENT_GLITCH indrivers/char/ vga.c). In case you enable "Software generated cursor" inthe system configuration, you can play a few new tricks: you can makeyour cursor look like a non-blinking red block, make it inversebackground of the character it's over or to highlight that character andstill choose whether the original hardware cursor should remain visibleor not. There may be other things I have never thought of.

The cursor appearance is controlled by a

<ESC>[?1;2;3c

escapesequence where 1, 2 and 3 are parameters described below. If you omit anyof 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 + 32if you want to always change the background colour + 64 if you dislikehaving the background the same as the foreground. Highlights are ignoredfor 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. Inboth groups, low three bits set colour (as in normal colour codes used bythe console) and the most significant one turns on highlight (or sometimesblinking--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 bitby including it in both the set mask and the toggle mask.

To get normal blinking underline, use: echo -e '33[?2c'To get blinking block, use: echo -e '33[?6c'To get red non-blinking block, use: echo -e '33[?17;0;64c'

6. Using framebuffer devices on Atari m68k platforms

This section describes framebuffer options on Atari m68k platforms.

6.1 What modes are available on Atari m68k platforms?

Colours 320x200 320x480 640x200 640x400 640x480 896x608 1280x960--------+--------------------------------------------------------- 1 bit | sthigh vga2 falh2 tthigh 2 bits | stmid vga4 4 bits | stlow ttmid/vga16 falh16 8 bits | ttlow vga256

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 isgiven, the kernel will probe for the modes in the following order untilit 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 toauto-probe for the modes you desire. For example, video=vga16 givesyou a 4 bit 640x480 display.

6.2 Additional suboptions on Atari m68k platforms

There are a number of suboptions available with the video=xxxparameter:

* inverse - inverts the display so that the background/foregroundcolours are reversed. Normally the background is black, but with thissuboption, it gets sets to white.
* font - sets the font to use in text modes. Currently you canonly select VGA8x8, VGA8x16, PEARL8x8. The default is touse the VGA8x8 only if the vertical size of the display is less than400 pixels, otherwise it defaults to VGA8x16.
* internal - a very interesting option. See the next section forinformation.
* external - as above.
* monitorcap - describes the capabilities for multisyncs. DON'Tuse with a fixed sync monitor!

6.3 Using the internal suboption on Atari m68k platforms

Syntax: internal:(xres);(yres)[;(xres_max);(yres_max);(offset)]

This option specifies the capabilities of some extended internal videohardware, i.e OverScan modes. (xres) and (yres) gives theextended dimensions of the screen.

If your OverScan mode needs a black border, you'll need to write the lastthree arguments of the internal: suboption. (xres_max) is themaximum line length that the hardware allows, (yres_max) is themaximum number of lines, and (offset) is the offset of the visiblepart of the screen memory to its physical start, in bytes.

Often extended internal video hardware has to be activated, for this youwill need the "switches=*" options. [Note: Author would like extrainformation on this, please. The m68k documentation in the kernel isn'tclear enough on this point, and he doesn't have an Atari! Examples wouldbe helpful too]

6.4 Using the external suboption on Atari m68k platforms

Syntax:external:(xres);(yres);(depth);(org);(scrmem)[;(scrlen)[;(vgabase)[;(colw)[;(coltype)[;(xres_virtual)]]]]]

This is quite complicated, so this document will attempt to explain asclearly as possible, but the Author would appreciate if someone would givethis a look over and see that he hasn't fscked something up! :o)

This suboption specifies that you have an external video hardware (mostlikely a graphic board), and how to use it with Linux. The kernel isbasically limited to what it knows of the internal video hardware, so youhave to supply the parameters it needs in order to be able to use externalvideo hardware. There are two limitations; you must switch to that modebefore booting, and once booted, you can't change modes.

The first three parameters are obvious; gives the dimensions of the screenas pixel height, width and depth. The depth supplied should be the numberof colours is 2^n that of the number of planes required. For example, ifyou desire to use a 256 colour display, then you need to give 8 as thedepth. This depends on the external graphic hardware, though so you willbe limited by what the hardware can do.

Following from this, you also need to tell the kernel how the video memoryis 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 videomodes uses this - and there are no graphic card that supports this mode.
* p - use packed pixels, i.e consecutive bits stands for allplanes for a pixel. This is the most common mode for 256 colour displayson graphic cards.
* t - use true colour, i.e this is actually packed pixels, butdoes not require a colour lookup table like what other packed pixel modesuses. These modes are normally 24 bit displays - gives you 16.8 millioncolours.

However, for monochrome modes, the (org) parameter has adifferent 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 ofthe video memory. That is given by the (scrmem) parameter as ahexadecimal number with an 0x prefix. You will need to find this outfrom the documentation that comes with your external video hardware.

The next paramter (scrlen) tells the kernel about the size of thevideo memory. If it's missing, this is calculated from the (xres),(yres) and (depth) parameters. It's not useful to write a valuehere these days anyway. To leave this empty, give two consecutivesemicolons if you need to give the (vgabase) parameter, otherwise,just leave it.

The (vgabase) parameter is optional. If it isn't given, the kernelcan't read/write any colour registers of the video hardware, and thus youhave to set up the appropriate colours before you boot Linux. But if yourcard is VGA compatible, you can give it the address where it can locatethe VGA register set so it can change the colour lookup tables. Thisinformation can be found in your external video hardware documentation. Tomake this clear, (vgabase) is the base address, i.e a 4kaligned address. For reading/writing the colour registers, the kernel usesthe address range between (vgabase) + 0x3c7 and (vgabase) +0x3c9. This parameter is given in hexadecimal and must have a 0xprefix, just like (scrmem).

(colw) is only meaningful, if the (vgabase) parameter isspecified. 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 isusually 6 bits, but it is also common to specify 8 bits.

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

(xres_virtual) is only required for the ProMST/ET4000 cards where thephysical linelength differs from the visible length. With ProMST, you needto supply 2048, whilst for ET4000, it depends on the initialisation of thevideo board.

7. Using framebuffer devices on Amiga m68k platforms

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

7.1 What modes are available for Amiga 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
o ntsc - 640x200
o ntsc-lace - 640x400
* PAL modes
o pal - 640x256
o pal-lace - 640x512
* ECS modes - 2 bit colours on ECS, 8 bit colours on AGA chipsetsonly.
o multiscan - 640x480
o multiscan-lace - 640x960
o euro36 - 640x200
o euro36-lace - 640x400
o euro72 - 640x400
o euro72-lace - 640x800
o super72 - 800x300
o super72-lace - 800x600
o dblntsc - 640x200
o dblpal - 640x256
o dblntsc-ff - 640x400
o dblntsc-lace - 640x800
o dblpal-ff - 640x512
o dblpal-lace - 640x1024
* VGA modes - 2 bit colours on ECS, 8 bit colours on AGA chipsetsonly.
o vga - 640x480
o vga70 - 640x400

7.2 Additional suboptions on Amiga m68k platforms

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 thePEARL8x8 font is used instead of VGA8x8 font, if the displaysize is less than 400 pixel wide.
* monitorcap - specifies the capabilities of the multisyncmonitor. Do not use with fixed sync monitors.

7.3 Supported Amiga graphic expansion boards

* 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 PicassoIIII+ and IV/ (Cirrus Logic GD542x/543x)

8. Using framebuffer devices on Macintosh m68k platforms

Currently, the framebuffer device implemented only supports the modeselected in MacOS before booting into Linux, also supports 1, 2, 4 and 8bit 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 inverseoption allows you to use reverse video.

9. Using framebuffer devices on PowerPC platforms

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

10. Using framebuffer devices on Alpha platforms
10.1 What modes are available to me?

So far, there is only the TGA PCI card - which only does 80x30 with aresolution of 640x480 at either 8 bits or 24/32 bits.

10.2 Which graphic cards can work with the frambuffer device?

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

* DEC TGA PCI (DEC21030) - 640x480 @ 8 bit or 24/32 bit versions

11. Using framebuffer devices on SPARC platforms
11.1 Which graphic cards can work with the framebuffer device?

This lists all the graphic cards available:

* MG1/MG2 - SBus or integrated on Sun3 - max. 1600x1280 @ mono (BWtwo)
* CGthree - Similar to MG1/MG2 but supports colour - max resolution ?
* GX - SBus - max. 1152x900 @ 8bit (CGsix)
* TurboGX - SBus - max. 1152x900 @ 8 bit (CGsix)
* SX - SS10/SS20 only - max. 1280x1024 @ 24 bit - (CGfourteen)
* ZX(TZX) - SBus - accelerated 24bit 3D card - max resolution ?(Leo)
* TCX - AFX - for Sparc 4 only - max. 1280x1024 @ 8bit
* TCX(S24) - AFX - for Sparc 5 only - max. 1152x900 @ 24bit
* Creator - SBus - max. 1280x1024 @ 24bit (FFB)
* Creator3D - SBus - max. 1920x1200 @ 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 orto a serial console.

Also, have a look at the Sparc Frame Buffer FAQ at

http://c3-a.snvl1.sfba.home.com/Framebuffer.html

11.2 Configuring the framebuffer devices

During make config, you need to choose whether to compile promconand/or fbcon. You can select both, but if you do this, you will needto set the kernel flags to select the device. fbcon always takesprecedence if not set. If promcon is not selected in, on boot up, itdefaults to dummycon. If promcon is selected, it will use thisdevice. Once the buses are booted, and fbcon is compiled in, thekernel probes for the above framebuffers and will use fbcon. If thereis no framebuffer devices, it will default to promcon.

Here are the kernel options

video=sbus:options where options is a comma separated list: nomargins sets margins to 0,0 margins=12x24 sets margins to 12,24 (default is computedfrom resolution) off don't probe for any SBus/UPA framebuffers 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 of96x40, looks similar to a Solaris console but with colours and virtualterminals just like on the Intel platform.

If you want to use the SUN12x22 font, you need to enable it duringmake config (disable the fontwidth != 8 option). The acceleratedframebuffers can support any font width between 1 to 16 pixels, whilstdumb frame buffers only supports 4, 8, 12 and 16 pixel font widths.

It is recommended that you grab a recent consoletools packages.

12. Using framebuffer devices on MIPS platforms

There is no need to change anything for this platform, this is all handledfor you automatically. Indys in particular are hardwired to use a consolesize of 160x64. However, moves are afoot to rewrite the console code forthese Indys, so keep an eye on this section.

13. Using framebuffer devices on ARM platforms

13.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 straightforwardto enable and use this driver on both kernels, however, the older version ishardcoded for depth and resolution (blech), but the good news is that the newerversion in the 2.2.x kernels is much more flexible, but currently in a stateof 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 kernelsources.

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]

13.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 andset depths and resolutions.

13.3 Other ARM ports (SA 7110s 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 donateme a Psion 5!]

14. 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 this section of the HOWTO.

14.1 Introduction

The main goal of this document is to get you started with running adual head configuration of Linux. While this process is prettystraight forward there are numerous things that one can do wrongalong the way.

The example I concentrate on is getting an X-server running on asecond monitor. I find this nice as you can usually find old large19" to 21" fixed frequency monitors around that people are givingaway because they can't use them. This way you can boot off a smallmultisync and then use X on a nice big monitor.

Please understand dual head support is currently developing so thisinformation changes rapidly. Anything in this document could be outof date or just plain incorrect by the time you are reading this.

** WARNING ** This document was written before any XFree86 4.0release. If you are reading this and XFree86 4.0 is alreadyreleased many things may have changed. Try getting a newer versionof this document if it's available.

14.2 Feedback

Feedback is most certainly welcome for this document. Without yoursubmissions and input, this document wouldn't exist. So, please postyour additions, comments and criticisms to:[email protected].

14.3 Contributors

The following people have contributed to this mini-HOWTO.

* Petr Vandrovec [email protected]

* Andreas Ehliar [email protected] (x2x)

* Marco Bizzarri [email protected] (multiple X servers)

14.4 Standard Disclaimer

No liability for the contents of this document can be accepted. Usethe concepts, examples and other content at your own risk. As thisis a new edition of this document, there may be errors andinaccuracies that could be damaging to your system. Proceed withcaution, and although this is highly unlikely, I don't take anyresponsibility for that.

14.5 Copyright Information

This section of the document is copyrighted (c)1999 Frederick Niles and distributedunder the following terms:

* Linux HOWTO documents may be reproduced and distributed in whole orin part, in any medium physical or electronic, as long as thiscopyright notice is retained on all copies. Commercialredistribution is allowed and encouraged; however, the author wouldlike to be notified of any such distributions.

* All translations, derivative works, or aggregate worksincorporating any Linux HOWTO documents must be covered under thiscopyright notice. That is, you may not produce a derivative workfrom a HOWTO and impose additional restrictions on itsdistribution. Exceptions to these rules may be granted undercertain conditions; please contact the Linux HOWTO coordinator atthe address given below.

* If you have questions, please contact, the Linux HOWTO coordinator,at [email protected]

14.6 What hardware is supported?

Most video cards assume they will be the only one in the system and arepermanently set with the addressing of the primary display adapter. Thereare a few exceptions.

* Matrox cards: This includes Matrox Millennium, Matrox Millennium II,Matrox Mystique, Matrox Mystique 220, Matrox Productiva G100, MatroxMystique G200, Matrox Millennium G200 and Matrox Marvel G200video 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.

14.7 Commercial support

This mini-HOWTO in primarily concerned with free software. However,there are commercial X servers with multi-head support. Theseinclude Metro Link's (www.metrolink.com) Metro-X and Xi Graphics'(www.xig.com) Accelerated-X.

14.8 Getting all the stuff.

You'll need the following patches and programs:

* "fbset" programtry:

http://www.cs.kuleuven.ac.be/~geert/bin/

(note: this program comes with RedHat 6.0)

* "fbaddon" Matrox dual head patches for Linux kerneltry:

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/

* "con2fb" programtry:

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/

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

14.9 Getting Started

The first thing you'll need to do is to patch a copy of the Linuxsource with the "fbaddon" patch. Then you need to configure thekernel and turn on frame buffer support. If you have Matrox cardsturn on Matrox unified accelerated driver support as well as theparticular type of card you have. Don't turn on VESA frame buffersupport. 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 allthe documentation on how to adjust the settings. Using a"/etc/fb.modes" file is highly recommended once you've decided onyour settings. The fbset program includes a Perl script to convertyour XF86Config file to fb.modes settings. I've included myoctave/Borne shell script to convert your XF86Config file inAppendix A & B.

You need to get comfortable with using the frame buffer device onone monitor, understanding any issues that can arise from your setup that have nothing to do with multi-head support. This can savea lot of head scratching later.

I'm going to concentrate my explanation on getting X running on thesecond monitor as doing most other configurations will just be aobvious subset of the procedure.

Move a console over...

Compile the "con2fb" program. If you run it without any argumentsyou'll get the following usage message:

"usage: con2fb fbdev console".

Thus, an example command would be "con2fb /dev/fb1 /dev/tty6" tomove virtual console number six over to the second monitor. UseCtrl-Alt-F6 to move over to that console and see that it does indeedshow 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 onthe second monitor. In particular, if you do nothing else you'llprobably want to at least set the virtual vertical resolution toyour actually vertical resolution.

e.g. "fbset -fb /dev/fb1 -vyres 600"

This will seriously slow down text mode, but X will be obnoxiouswithout 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 filefor the frame buffer device. Here's an example:

# The Frame Buffer serverSection "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 EndSubsectionEndSection

Use the "default" modes as I don't think any other one will work withthe Matrox frame buffer.

Try starting the X server on the second monitor.

Set the variable FRAMEBUFFER to the second frame buffer.

"export FRAMEBUFFER=/dev/fb1"

or

"setenv FRAMEBUFFER /dev/fb1"

You need to start the X server so that it both matches the selectedcolor depth and it appears on the same monitor you start the X serverfrom.

e.g. "startx -- :0 -bpp 16 vt06"

This example will start the "zeroth" X server on virtual console sixwith 16 bit color. Using ":1" when launching another X server forthe other frame buffer will allow you to have two X servers running.

14.10 Summary

The steps involved in getting an X server running on a second monitorcan be summarized as follows:

* Get the kernel patch, fbset, and con2fb.

* Patch the kernel, configure, rebuild, and reboot.

* Add XF86_FBDev section to XF86Config file and set X link.

Then each time you reboot:

* Move a console over. e.g. "con2fb /dev/fb1 /dev/tty6"

* Adjust the settings e.g. "fbset -fb /dev/fb1 1280x1024"

* Set the FRAMEBUFFER. e.g. "export FRAMEBUFFER=/dev/fb1"

* Start the X server. e.g. "startx -- -bpp 16 vt06"

You can automate this each time you reboot via a shell alias. It must be an alias and not a shell script since it needs to detect thecurrent console number. This is my C-shell alias to start up X ona 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.modesstartx -- :!* -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 withoutthe comments, but it's easier to read here with line breaks andcomments inserted. I just give the number of the frame buffer as anargument and it starts right up.

I'm not sure how to do this same alias in bash. I don't know how todetermine 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 usethe "tty" command to get the name of the current VT and just maketwo separate aliases for each X server.

14.11 Other Notes and Problems

* Both "fbset" and "startx" MUST be run from the same frame bufferas the one being affected. This places serious limits on how muchof these commands can be automated via scripts.

* XFree86 4.0 will have "proper" multi-head support, but 3.3.1 doesnot. You can run two servers with 3.3.1 and use x2x to switchbetween them however...(see the next bullet)

* The inactive frame buffer will just hold the last image of when itwas active, no updates with occur.

* The monitor that's not selected doesn't always preseve it's statewhen not active. (But it usually does.)

* Geert Uytterhoeven (the frame buffer maintainer) and LinusTorvalds don't agree with the current "frame buffer per VT"multi-head console support changes (i.e. fbaddon) so it may neverbe in the mainstream kernel tree. (This was heard third hand andmay be wildly untrue.)

* If you "break the rules" and start the X server (run "startx")from a different monitor, the machine can eventually crash badlywith the keyboard and mouse input all mixed together.

* The documentation framebuffer.txt in the kernel source explainsthat you can use the Modeline settings in your XF86Config filedirectly when running X. Using the Matrox frame buffer seems toforce the X server to drop all of those. So you can only have theone ("default") setting at at time (the same one you had in textmode).

* The XF86_FBDev is unaccelerated. However, there are patches foraccelerated Matrox support at

http://www.in-berlin.de/User/kraxel/xfree86/

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 adual monitor configuration (and actually have the server on eitherthe second montior or both). While it seems easy enough to add aline to the gdm/xdm Xservers file, the constrain that you must startthe X server from the same frame buffer prevents the obvioussolution from working. If anyone finds a way please e-mail me andI'll add it here.

Using the x2x program.

There's a nice little program called x2x that will switch X serversfor you when you get to the edge of the screen. Last known home forthis program was:

http://ftp.digital.com/pub/DEC/SRC/x2x/

It'salso an optional Debian package. I haven't tried it yet but someusers have reported success.

Other useful commands

These are existing linux commands that are worth remembering whendealing with a multi-head configuration (especially in writingscripts).

* "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)

#!/usr/bin/octave -qbpp = 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 Hzn", DCF, HSF, RR);printf(" geometry %d %d %d %d %dn", HR, VR, HR, VR, bpp);printf(" timings %d %d %d %d %d %d %dn", ... pixclock, left_margin, right_margin, ... upper_margin, lower_margin, ... hsync_len, vsync_len);printf("endmoden");

Appendix B. Borne Shell script "cvtfile"

(This calls the octave script "cvtmode")

#!/bin/sh# Shell script to convert XF86Config file to fb.modes file.# Uses octave script cvtmode.mif [ -z $1 ]; then FILE=/etc/X11/XF86Configelse FILE=$1fii=1LEN=`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

15. Using/Changing fonts

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

ftp://ftp.win.tue.nl/pub/linux/utils/kbd

One advantage of downloading and installing kbd-0.99 is that you will beable to load international fonts (i.e Euro symbol) into your consoledevice (It is tres chic to have three symbols on my keyboard, the dollar sign, the English pound sign and the Euro sign!).

16. Changing console modes

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

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.

17. Setting up the X11 FBdev driver

If you are not using XFree86 3.3.3.1 or later, you are urged to upgradeto 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 FBdevdriver for older XFree86 versions such as 3.3.2, 3.3.3 etc.

Go to

http://www.xfree86.org

, and download the latest XServers source archive, unpack, and configure the drivers, following these steps:

* Edit xc/config/cf/xf86site.def, uncomment the #define forXF68FBDevServer
* Comment out all references to FB_VISUAL_STATIC_DIRECTCOLOR, asthese 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, andchange K_RAW to K_MEDIUMRAW.

and then build the driver. Don't worry about the m68k references, itsupports Intel platforms. Then build the whole thing - it'll take a longtime though as it's a large source tree.

Alternatively, if you don't have the time to spare, you can obtain thebinaries 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

For glibc2, download from these URLs.

http://user.cs.tu-berlin.de/~kraxel/linux/XF68_FBDev.libc6.gzhttp://pobox.com/~brion/linux/fbxserver.html

There have been reports that X11 is non functional on certain graphiccards with this vesafb feature enabled, if this is happening, try the newXF86_FBdev driver for X11.

This driver, along with vesafb can also help run X11 in higher graphicresolutions with certain graphic chipsets which are not supported by anyof the current X11 drivers. Examples are MGA G-200 et. al.

To configure the XF86_FBdev driver with your X11 system, you'll need toedit your XF86Config for the following:

Section "Screen" Driver "FBDev" Device "Primary Card" Monitor "Primary Monitor" SubSection "Display" Modes "default" EndSubSectionEndSection

You'll also need to set XkbDisable in the keyboard section as well, orinvoke the XF86_FBDev server with the '-kb' option to set up your keyboardso it works properly. If you forget to set XkbDisable, you will have toput the following lines in your .Xmodmap to straighten out the keyboardmappings. 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 tothis 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 requiredkeycode 104 = KP_Enterkeycode 105 = Control_Rkeycode 106 = KP_Dividekeycode 108 = Alt_R Meta_Rkeycode