--- fbset-2.1.orig/debian/control
+++ fbset-2.1/debian/control
@@ -0,0 +1,32 @@
+Source: fbset
+Section: admin
+Priority: optional
+Maintainer: Guillem Jover <guillem@debian.org>
+Standards-Version: 3.7.2
+Homepage: http://users.telenet.be/geertu/Linux/fbdev/
+Vcs-Browser: http://svn.debian.org/wsvn/pkg-fbset/trunk/
+Vcs-Svn: svn://svn.debian.org/pkg-fbset/trunk/
+Build-Depends: debhelper (>= 5), quilt (>= 0.40), flex, bison
+
+Package: fbset
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends}, makedev (>= 2.3.1-24) | devfsd | udev
+Description: framebuffer device maintenance program
+ Program to modify settings for the framebuffer devices (/dev/fb[0-9]*
+ or /dev/fb/[0-9]*) on Linux, like depth, virtual resolution, timing
+ parameters etc.
+
+Package: fbset-udeb
+XC-Package-Type: udeb
+Section: debian-installer
+Priority: extra
+Architecture: any
+Depends: ${shlibs:Depends}
+Description: framebuffer device maintenance program
+ Program to modify settings for the framebuffer devices (/dev/fb[0-9]*
+ or /dev/fb/[0-9]*) on Linux, like depth, virtual resolution, timing
+ parameters etc.
+ .
+ This contains the udeb, which is used for the debian-installer
+ installation system. It won't work well on a normal debian system.
+
--- fbset-2.1.orig/debian/fbset.examples
+++ fbset-2.1/debian/fbset.examples
@@ -0,0 +1,2 @@
+etc/fb.modes.*
+debian/modes/*
--- fbset-2.1.orig/debian/changelog
+++ fbset-2.1/debian/changelog
@@ -0,0 +1,375 @@
+fbset (2.1-21) unstable; urgency=low
+
+  * Remove commented out debhelper command calls.
+  * Make creating the device files non-fatal. (Closes: #444458)
+
+ -- Guillem Jover <guillem@debian.org>  Tue, 20 Nov 2007 04:12:14 +0200
+
+fbset (2.1-20) unstable; urgency=low
+
+  * Switched to quilt:
+    - Add new debian/patches/series file.
+    - Add Build-Depends on 'quilt (>= 0.40)'.
+    - Include quilt.make from debian/rules.
+    - Remove now unused debian/patch.mk.
+    - Add a Status field in all patches, and refreshed them.
+  * Add a Homepage field.
+  * Add Vcs-Browser and Vcs-Svn fields.
+  * Update download URL in debian/copyright.
+  * Do not ignore errors from 'make clean' nor 'make install' in debian/rules.
+  * Remove con2fbmap on clean so that it does not FTBFS on a second row.
+    (Closes: #424250, #442561)
+  * Fix bashisms in Makefile when creating directories. (Closes: #417476)
+    - debian/patches/10_build.patch: Modified.
+  * Remove useless debconf note about device creation. (Closes: #390567)
+    - debian/fbset.templates: Remove.
+    - debian/fbset.config. Likewise.
+    - debian/po/: Likewise.
+    - debian/rules: Remove debconf support.
+    - debian/fbset.postinst: Likewise.
+  * Only try to create the device node on '<postinst> configure'.
+  * Updated to linux kernel 2.6.22.3:
+    - debian/doc/kernel-doc/: Sync.
+
+ -- Guillem Jover <guillem@debian.org>  Sun, 16 Sep 2007 19:53:31 +0300
+
+fbset (2.1-19) unstable; urgency=low
+
+  * Now using Standards-Version 3.7.2 (no changes needed).
+  * Fix Upstream URL in the debian/watch file.
+  * Change section from base to admin, to match ftp-master override.
+  * Run /dev/MAKEDEV in debian/fbset.postinst only if present. (Closes: #362794)
+  * Updated to linux kernel 2.6.17.4:
+    - debian/doc/kernel-doc/: Sync.
+    - debian/modes/fb.modes.CyBla: Likewise.
+  * Indent debian/copyright to 4 spaces.
+  * Clean up debian/patch.mk:
+    - Rename clean to unpatch.
+    - Switch patch and unpatch to single-colon targets.
+  * Clean up debian/rules:
+    - Switch clean to single-colon target, make it depend on unpatch.
+  * Templates:
+    - Catalan: Changed encoding to UTF-8.
+
+ -- Guillem Jover <guillem@debian.org>  Thu,  3 Aug 2006 05:33:32 +0300
+
+fbset (2.1-18) unstable; urgency=low
+
+  * Update watch file to version 3 (no changes needed).
+  * Now using Standards-Version 3.6.2 (no changes needed).
+  * Upgrade to debhelper compat level 5.
+  * Put framebuffer modes as full files:
+    - debian/patches/02_fb_modes.patch: Move full files to ...
+    - debian/modes/: ... here.
+  * Updated to linux kernel 2.6.15:
+    - debian/doc/kernel-doc/: Sync.
+    - debian/modes/fb.modes.CyBla: New file.
+    - debian/patches/01_kernel_fb.h.patch: Likewise.
+    - debian/patches/07_new_accels.patch: Add more accelerated cards.
+  * Move fbset, modeline2fb and con2fbmap to /bin. (Closes: #256972, #320574)
+  * Templates:
+    - Portuguese. (Closes: #338728)
+      Thanks to Miguel Figueiredo <elmig@debianpt.org>.
+    - Swedish. (Closes: #331471)
+      Thanks to Daniel Nylander <yeager@lidkoping.net>.
+  * Depend on udev as a Second Class Citizen alternative to makedev.
+
+ -- Guillem Jover <guillem@debian.org>  Wed, 18 Jan 2006 02:13:39 +0200
+
+fbset (2.1-17) unstable; urgency=low
+
+  * Templates:
+    - Update pot and po files.
+    - Czech. (Closes: #308054)
+    Thanks to Miroslav Kure <kurem@upcase.inf.upol.cz>.
+    - Vietnamese. (Closes: #313599)
+    Thanks to Clytie Siddall <clytie@riverland.net.au>.
+  * Merge fbset and fbset-udeb into binary-arch, and on install targets
+    clean only its own package directory.
+    - debian/rules.
+
+ -- Guillem Jover <guillem@debian.org>  Sat, 18 Jun 2005 05:03:36 +0300
+
+fbset (2.1-16) unstable; urgency=low
+
+  * Remove supported Linux kernel version list from package description.
+    (Closes: #286338)
+  * Fix typos in con2fbmap.8. (Closes: #287953)
+    Thanks to A Costa <agcosta@gis.net>.
+  * Honour noopt DEB_BUILD_OPTIONS for udebs.
+  * Fix Subversion repository address.
+  * Provide a patch target instead of pre-build.
+    - debian/patch.mk: Likewise.
+    - debian/rules: Fix accordingly.
+  * Updated to linux kernel 2.6.10:
+    - debian/doc/kernel-doc/: Sync.
+    - debian/patches/01_kernel_fb.h.patch: Likewise.
+    - debian/patches/07_new_accels.patch: Add more accelerated cards.
+
+ -- Guillem Jover <guillem@debian.org>  Tue,  1 Feb 2005 07:28:26 +0100
+
+fbset (2.1-15) unstable; urgency=low
+
+  * Fix typo in fbset(8) manpage s/-g/-t/.
+    Thanks to Benoit-Pierre Demaine <benoit@demaine.info>.
+  * Fix fb.modes(5) section in manpage header.
+  * debian/copyright:
+    - Added the location of the Subversion repo used for the packages.
+    - Use "License:" instead of "Copyright:".
+  * Updated to debhelper >= 4.2 and use its udeb support.
+  * Updated to linux kernel 2.6.9:
+    - debian/doc/kernel-doc/
+  * Templates:
+    - Italian (Closes: #279013)
+      Thanks to Stefano Melchior <stefano.melchior@openlabs.it>.
+
+ -- Guillem Jover <guillem@debian.org>  Tue, 14 Dec 2004 02:50:29 +0100
+
+fbset (2.1-14) unstable; urgency=low
+
+  * Templates:
+    - Danish (da.po): Initial translation by Claus Hindsgaul.
+  * Updated to linux kernel 2.6.4:
+    - debian/doc/kernel-doc/
+
+ -- Guillem Jover <guillem@debian.org>  Sun, 21 Mar 2004 20:40:15 +0100
+
+fbset (2.1-13) unstable; urgency=low
+
+  * debian/changelog: Converted encoding to UTF-8.
+  * debian/control: Lower case first letter from package descriptions.
+  * Updated to linux kernel 2.6.1:
+    - debian/doc/kernel-doc/
+  * Templates:
+    - Japanese (Closes: #227813)
+      Thanks to Hideki Yamane <henrich@samba.gr.jp>.
+
+ -- Guillem Jover <guillem@debian.org>  Thu, 15 Jan 2004 08:18:11 +0100
+
+fbset (2.1-12) unstable; urgency=low
+
+  * Split diff into patches.
+  * Use debian/patch.mk.
+  * Updated to linux kernel 2.6.0-test9:
+    - debian/doc/kernel-doc/
+    - debian/doc/FAQ: Added question about fbset working under 2.6.
+      Added a question about driver name change.
+    - 01_kernel_fb.h.patch
+    - 07_new_accels.patch
+  * Templates:
+    - Russian (Closes: #221440)
+      Thanks to Ilgiz Kalmetev <ilgiz@bashtelecom.ru>.
+    - German (Closes: #223126)
+      Thanks to Patrick Willam <patrick@patrick-willam.de>.
+    - Catalan: Fixed a typo.
+  * Now using Standards-Version 3.6.1.
+
+ -- Guillem Jover <guillem@debian.org>  Tue, 18 Nov 2003 13:06:42 +0100
+
+fbset (2.1-11) unstable; urgency=low
+
+  * Templates:
+    - Dutch (Closes: #204918)
+      Thanks to Bart Cornelis <cobaco@linux.be>.
+  * Changed udeb priority to extra.
+
+ -- Guillem Jover <guillem@debian.org>  Mon, 11 Aug 2003 20:21:07 +0200
+
+fbset (2.1-10) unstable; urgency=low
+
+  * Update templates.pot automatically.
+  * Reference the FAQ in the manpage, and added an entry to the FAQ
+    about switching modes with vesafb (Closes: #191266).
+  * Documentation update:
+    - Added an entry to the FAQ about setting up 80x25 text mode on
+      a Sun framebuffer.
+    - Added two mode file examples.
+    - Added a missing entry in the FAQ TOC.
+    (Closes: #193726).
+    Thanks to Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>.
+  * Standarized .TH format on manpages.
+  * Use stdout for --help command (Closes: #204399).
+  * Now using Standards-Version 3.6.0.
+
+ -- Guillem Jover <guillem@debian.org>  Thu,  7 Aug 2003 04:51:22 +0200
+
+fbset (2.1-9) unstable; urgency=low
+
+  * Created an udeb for debian-installer.
+  * Substituted '?' character from package long description.
+  * Moved DH_COMPAT to compat file.
+
+ -- Guillem Jover <guillem@debian.org>  Sun, 23 Mar 2003 21:22:03 +0100
+
+fbset (2.1-8) unstable; urgency=low
+
+  * Templates:
+    - Brazilian portuguese (Closes: #183313)
+      Thanks to André Luís Lopes <andrelop@ig.com.br>.
+    - French (Closes: #184432)
+      Thanks to Philippe Batailler <philippe.batailler@free.fr>.
+    - Spanish: Removed the fuzzy tag (forgot to do that on last version).
+    - Catalan: Likewise.
+  * Added changelog typo fix from last sponsored upload by
+    David Martinez <ender@debian.org>.
+  * Added a debian/watch file.
+  * Sync Section and Priority with override file.
+  * Move the shebang "-e" flag from maintainer scripts to an independent
+    set command, as suggested by linda.
+  * Now using Standards-Version 3.5.9.0.
+
+ -- Guillem Jover <guillem@debian.org>  Thu, 13 Mar 2003 07:33:21 +0100
+
+fbset (2.1-7) unstable; urgency=low
+
+  * New Maintainer (Closes: #176933).
+    - Acknowledge NMU fixed bugs (Closes: #55667, #87145, #105619, #106232).
+
+  * Updated to kernel 2.4.20:
+    - Updated kernel-doc directory.
+    - Updated kernel framebuffer header and corrected compile warnings.
+    - Added new accelerator descriptions.
+  * Fixed a typo in fb.modes.ATI (Closes: #142841, #151402).
+  * Added devfs devices support to:
+    - fbset (Closes: #132061)
+      Thanks to Bas Zoetekouw <bas@debian.org>.
+    - con2fbmap.
+  * Recognise framebuffer database rgba option properly (Closes: #42568).
+  * Manpages:
+    - Updated fbset manpage (Closes: #150724)
+      Thanks to Osamu Aoki <debian@aokiconsulting.com>.
+    - Added all missing options to fb.modes and fbset manpages.
+
+  * Removed emacs cruft from debian/changelog.
+  * debian/copyright:
+    - Updated upstream source location.
+    - Added what GPL version the source obey (Closes: #133496).
+  * Switched to debhelper compatibility level 4.
+  * Don't ask framebuffer device creation anymore per policy 11.6.
+  * Templates:
+    - Brazilian portuguese (Closes: #108541)
+      Thanks to André Luís Lopes <andrelop@ig.com.br>.
+    - Russian (Closes: #136921)
+      Thanks to Ilgiz Kalmetev <ilgiz@bashtelecom.ru>.
+    - Spanish (Closes: #107159)
+      Thanks to Carlos Valdivia Yagüe <valyag@teleline.es>.
+    - Catalan (Closes: #139742)
+      Thanks to Antoni Bella <bella5@teleline.es>.
+    - German (Closes: #106892)
+      Thanks to Sebastian Feltel <sebastian@feltel.de>.
+    - Switched to po-debconf.
+    - Update template file as per policy 11.6 change. Spanish and Catalan
+      translations synced, all others are outdated.
+  * debian/control:
+    - Removed trailing dot from short package description.
+    - Improved long description.
+    - Depend on devfsd (Closes: #152149).
+    - Depend on debhelper >= 4.1.16 as needed by po-debconf.
+    - Use substvar misc:Depends instead of explicit debconf.
+  * Updated DEB_BUILD_OPTIONS behaviour as per policy 11.1.
+  * Now using Standards-Version 3.5.8.0.
+  * Now Lintian/Linda clean.
+
+ -- Guillem Jover <guillem.jover@menta.net>  Wed, 22 Jan 2003 13:12:52 +0100
+
+fbset (2.1-6.1) unstable; urgency=medium
+
+  * NMU with permission of maintainer.
+  * Use debhelper v3.
+  * Ask user if we should create framebuffer devices. (Closes: #106232)
+    + Add dependency on debconf as a result of this question.
+    + Do not ask this question if devfs is used.
+  * Kevin Kreamer contributed a manpage for modeline2fb. (Closes: #87145)
+  * Use /sbin/MAKEDEV, not /dev/MAKEDEV, in postinst. (Closes: #55667)
+  * Depend on makedev >= 2.3.1-24 as recommended in #55667.
+  * Describe -a and -accel in the manpage for fbset. (Closes: #105619)
+  * Changed two places in fb.modes manpage to refer to section 5, not 8.
+  * Bumped Standards-Version to 3.5.5.0
+
+ -- André Dahlqvist <andre@debian.org>  Wed, 25 Jul 2001 14:35:29 +0200
+
+fbset (2.1-6) unstable; urgency=low
+
+  * added mode "768x576-75" to the /etc/fb.modes database file
+    reported by: Gabor Fleischer <flocsy@mtesz.hu>
+
+ -- Hartmut Koptein <koptein@debian.org>  Tue,  4 Jan 2000 20:48:20 +0100 
+
+fbset (2.1-5) unstable; urgency=low
+
+  * cleanup install of con2fbmap
+  * added Build-Depends
+  * install configfile in /etc/fb.modes
+
+ -- Hartmut Koptein <koptein@debian.org>  Fri, 17 Dec 1999 16:42:56 +0100
+
+fbset (2.1-4) unstable; urgency=low
+
+  * added #!/bin/sh to prerm   closes: #48471
+
+ -- Hartmut Koptein <koptein@debian.org>  Thu, 28 Oct 1999 16:10:05 +0200
+
+fbset (2.1-3) unstable; urgency=low
+
+  * fixed the usr/doc /usr/share sym-link
+
+ -- Hartmut Koptein <koptein@debian.org>  Thu, 21 Oct 1999 13:13:23 +0200
+
+fbset (2.1-2) unstable; urgency=low
+
+  * Updated Standards-Version to 3.0.1.1
+
+ -- Hartmut Koptein <koptein@debian.org>  Tue,  7 Sep 1999 02:01:52 +0200
+
+fbset (2.1-1) unstable; urgency=low
+
+  * new upstream version
+  * added kernel-doc directory with the docs from the kernel source
+  * make modeline2fb available in /usr/sbin
+  * added a very first incomplete FAQ
+
+ -- Hartmut Koptein <koptein@debian.org>  Wed, 23 Jun 1999 19:10:36 +0200
+
+fbset (2.0.1-1) unstable; urgency=low
+
+  * new upstream version
+
+ -- Hartmut Koptein <koptein@et-inf.fho-emden.de>  Tue,  9 Feb 1999 20:07:55 +0100
+
+fbset (2.0-2) frozen unstable; urgency=low
+
+  * added generation of /dev/fb? to postinst if this devices doesn't exist
+    fixes: #30810
+
+ -- Hartmut Koptein <koptein@et-inf.fho-emden.de>  Thu, 17 Dec 1998 20:44:53 +0000
+
+fbset (2.0-1) frozen unstable; urgency=low
+
+  * Changed the name from fbset2 to fbset
+  * This package replace the old fbset and fbset2 fixes: Bug#29276
+  * New maintainer
+  * New upstream version
+  * Lintian clean
+
+ -- Hartmut Koptein <koptein@et-inf.fho-emden.de>  Fri, 11 Dec 1998 13:09:17 +0000
+
+fbset2 (1998.07.13-1) unstable; urgency=low
+
+  * Sort of a new package, and sort of a new upstream release.
+
+ -- Hartmut Koptein <koptein@et-inf.fho-emden.de>  Fri, 23 Oct 1998 18:07:35 +0200
+
+fbset (1.0-2) unstable; urgency=low
+
+  * Adapted for libc6
+  * Changed a pretty stupid bug in postinst which noone discovered so far.
+    (it never actually created any fb0* nodes in /dev)
+
+ -- Frank Neumann <Frank.Neumann@Informatik.Uni-Oldenburg.DE>  Tue, 21 Oct 1997 19:38:56 +0200
+
+fbset (1.0-1) unstable; urgency=low
+
+  * Initial Release.
+
+ -- Frank Neumann <Frank.Neumann@Informatik.Uni-Oldenburg.DE>  Wed, 16 Apr 1997 18:47:56 +0200
+
--- fbset-2.1.orig/debian/copyright
+++ fbset-2.1/debian/copyright
@@ -0,0 +1,51 @@
+This package was debianized by Frank Neumann
+(Frank.Neumann@informatik.uni-oldenburg.de) on Wed, 16 Apr 1997.
+
+On Fri, 11 Dec 1998 Hartmut Koptein <koptein@debian.org> took over
+maintenance of fbset.
+
+Currently maintained by Guillem Jover <guillem@debian.org>.
+
+The upstream source was downloaded from:
+
+    <http://users.telenet.be/geertu/Linux/fbdev/>
+
+The debian packages are maintained through Subversion on:
+
+    <svn://svn.debian.org/pkg-fbset/>
+
+Upstream Author:
+
+    Copyright (C) 1995-1998 Geert Uytterhoeven <geert@linux-m68k.org>
+
+License:
+
+    This file is subject to the terms and conditions of the GNU General Public
+    License. See the file COPYING in the main directory of the Linux
+    distribution for more details.
+
+--------------- Clarification ----------------------------------------
+
+From Geert.Uytterhoeven@sonycom.com Tue Jan 21 19:59:02 2003
+Date: Tue, 21 Jan 2003 17:06:11 +0100 (MET)
+From: Geert Uytterhoeven <geert@linux-m68k.org>
+Sender: geert@sonycom.com
+To: Guillem Jover <guillem.jover@menta.net>
+Subject: Re: fbset: GPL version
+In-Reply-To: <20030120063657.GA6650@zulo.hadrons.org>
+Message-ID: <Pine.GSO.4.21.0301211703450.24563-100000@vervain.sonytel.be>
+
+	Hi Guillem,
+
+> I'm the new Debian maintainer for fbset. A Debian user has filed a bug
+> reporting that the sources doesn't specify the GPL version. So could
+> you be so kind to tell me what version they obey?
+
+The source files refer to `the file COPYING in the main directory of the Linux
+distribution', so that must be the GNU General Public License Version 2.
+
+--------------- Clarification ----------------------------------------
+
+On Debian GNU/Linux systems, the complete text of the GNU General
+Public License can be found in '/usr/share/common-licenses/GPL'.
+
--- fbset-2.1.orig/debian/watch
+++ fbset-2.1/debian/watch
@@ -0,0 +1,2 @@
+version=3
+http://users.telenet.be/geertu/Linux/fbdev/ fbset-(.*)\.tar\.gz debian uupdate
--- fbset-2.1.orig/debian/fbset.dirs
+++ fbset-2.1/debian/fbset.dirs
@@ -0,0 +1,4 @@
+etc
+bin
+usr/share/man/man1
+usr/share/man/man5
--- fbset-2.1.orig/debian/doc/FAQ
+++ fbset-2.1/debian/doc/FAQ
@@ -0,0 +1,508 @@
+         Frequently Asked Questions about the usage of fbset
+
+This document tries to answer questions a user might have when installing
+and using fbset.  Please make sure you read this before sending questions
+or bug reports to the maintainers.
+
+If you have any questions you think should be answered in this document,
+please let me know.
+
+                                          Hartmut Koptein <koptein@debian.org>
+
+==============================================================================
+
+1.1.	How to set my matrox graphicboard for the framebuffer and with lilo?
+1.2.	How to do this with other graphic cards?
+1.3.	How to switch modes with vesafb?
+1.4.	Is fbset usable with the linux kernel 2.6?
+1.5.	What are the driver names on the different linux kernel versions?
+
+2.1.	I have an valid XF86Config file, but no /etc/fb.modes file. Any hints?
+2.2.	The XF86Config-4 file doesn't have any ModeLine lines. What to do?
+2.3.	What is the difference between the old XF86Config and the one for FB?
+2.4.	Is a /etc/X11/XF86Config file for framebuffer available?
+
+
+==============================================================================
+
+
+1.1.	How to set my matrox graphicboard for the framebuffer and with lilo?
+
+  {HK} Put this line into the /etc/lilo.conf: (some examples)
+
+  append="video=matrox:xres:1152,yres:864,pixclock:10869,left:56,right:106,upper:20,lower:1,hslen:160,vslen:10,depth:8"
+  append="video=matrox:vesa:279,fv:85"
+  append="video=matrox:xres:1280,yres:1024,pixclock:7124,left:184,right:12,upper:30,lower:3,hslen:160,vslen:3,sync:3,depth:8"
+
+
+1.2.	How to do this with other graphic cards?
+
+  {HK} Look at /usr/share/doc/fbset/examples/fb.modes.ATI for say 1024x768
+  This gives:
+
+  mode "1024x768-75"
+  # D: 78.75 MHz, H: 60.023 kHz, V: 75.03 Hz
+     geometry 1024 768 1024 768 8
+     timings 12699 176 16 28 1 96 3
+     hsync high
+     vsync high
+  endmode
+
+  To compare this for the lilo append line we have
+
+  append="video=XXXXXX:xres:1024,yres:768,pixclock:12699,left:176,right:16,upper:28,lower:1,hslen:96,vslen:3,sync:3,depth:8"
+
+  The frame buffer device uses the following fields:
+
+    - screen resolution is                    xres:1024  yres:768
+    - pixclock: pixel clock in ps (pico seconds)     12699
+    - left_margin: time from sync to picture           176
+    - right_margin: time from picture to sync           16
+    - upper_margin: time from sync to picture           28
+    - lower_margin: time from picture to sync            1
+    - hsync_len: length of horizontal sync              96
+    - vsync_len: length of vertical sync                 3
+
+
+1.3.	How to switch modes with vesafb?
+
+  {GJ} You can only switch modes at boot time. More info at:
+
+  /usr/share/doc/fbset/kernel-doc/vesafb.txt.gz
+
+
+1.4.	Is fbset usable with the linux kernel 2.6?
+
+
+  {GJ} Yes, you will need the apropriate FB devices drivers for your
+  hardware as well as the fbcon support (CONFIG_FRAMEBUFFER_CONSOLE).
+
+
+1.5.	What are the driver names on the different linux kernel versions?
+
+
+  {GJ} Some framebuffer driver names used on the linux kernel argument
+  "video=" have changed. All new driver names on linux kernel 2.6 have
+  the string "fb" appended. Old ones that don't have that postfix on
+  linux kernel 2.4 are:
+
+    retz3, cyber, cyber2000, clgen, matrox, neo, virge, riva, radeon,
+    s3trio, trident, sst, vesa, tdfx, sgivw, acorn, hga, apollo, tga,
+    g364, sa1100, sun3, tx3912, pvr2, vga16
+
+  So when reading /usr/share/doc/fbset/FAQ, take this into account and
+  use the apropriate driver name depending on your running kernel.
+
+
+2.1.	I have an valid XF86Config file, but no /etc/fb.modes file. Any hints?
+
+  {HK} Sure. :-)
+  With an available and correct /etc/X11/XF86Config file (an old setup) you
+  can use the modeline2fb to convert the modelines into
+  /etc/fb.modes to to use it with fbset.
+
+  Or you put the fb.modes.ATI (/usr/share/doc/fbset/examples) into /etc/ as
+  fb.modes (perms root.root 644). The timings are very compatible with other
+  graphicboards then ATI.
+
+
+2.2.	The XF86Config-4 file doesn't have any ModeLine lines. What to do?
+
+
+  {ibr} Use xvidtune's "Show" function to obtain mode parameters, then
+  use modeline2fb as described above, or cvtmode.m script from
+  Framebuffer-HOWTO (in this case, don't forget about [hvc]sync lines).
+
+  Some examples:
+
+  echo ModeLine \"640x400\" 31.5 640 672 736 832 400 401 404 445 \
+	-hsync +vsync | modeline2fb
+
+  ./cvtmode.m 31.5 640 672 736 832 400 401 404 445
+
+
+2.3.	What is the difference between the old XF86Config and the one for FB?
+
+
+  {HK} There aren't many differences, all fonts, kbd, mice and monitor
+  settings are the same.
+  But you have choices. For fbdev you don't need a modeline, you can use the
+  same resolution as on the consoles, setable with fbset (Modes "default").
+
+
+  # **********************************************************************
+  # Server for the Linux Frame Buffer Device
+  # **********************************************************************
+
+  Section "Device"
+      Identifier "Linux Frame Buffer Device"
+  #   Option "no_accel"
+  EndSection
+
+  # **********************************************************************
+  # Screen/Display  section
+  # **********************************************************************
+
+  Section "Screen"
+      Driver  "fbdev"
+      Device  "Linux Frame Buffer Device"
+      Monitor "Panasonic PanaSync/Pro5"
+      DefaultColorDepth 16
+      SubSection  "Display"
+          Modes   "default"
+      EndSubsection
+  EndSection
+
+
+  With modelines, it is the same as without fbdev. But then you should
+  check your modeline with fbset --xfree86. This shows you the 'xf86'
+  modeline from the fbdev settings. Here some examples (don't use it
+  without checking your setup first):
+
+
+  ModeLine "640x480" 30.438 640 704 768 832 480 512 514 546 -HSync -VSync
+  ModeLine "800x600" 49.553 800 864 928 992 600 632 634 666 -HSync -VSync
+  ModeLine "832x624" 52.995 832 896 960 1024 624 656 658 690 -HSync -VSync
+  # ModeLine "1024x768" 76.064 1024 1088 1152 1216 768 800 802 834 -HSync -VSync
+  ModeLine "1024x768" 99.801 1024 1024 1120 1312 768 789 804 845 -HSync -VSync
+  ModeLine "1152x870" 94.358 1152 1216 1280 1344 870 902 904 936 -HSync -VSync
+  ModeLine "1152x900" 130.000 1152 1320 1360 1620 900 901 905 943 +HSync +VSync
+  ModeLine "1280x960"  125.645 1280 1312 1456 1680 960 961 964 1000 -HSync -VSync
+  ModeLine "1280x1024" 144.551 1280 1352 1496 1632 1024 1025 1028 1059 +HSync +VSync
+  ModeLine "1280x1024" 155.000 1280 1384 1528 1688 1024 1025 1028 1066 +HSync +VSync
+
+
+2.4.	Is a /etc/X11/XF86Config file for framebuffer available?
+
+
+  {HK} Use this as an example:
+
+
+  # $XFree86: xc/programs/Xserver/hw/xfree86/XF86Conf.cpp,v 3.21 1996/01/31 11:46:37 dawes Exp $
+  #
+  # Copyright (c) 1994 by The XFree86 Project, Inc.
+  #
+  # Permission is hereby granted, free of charge, to any person obtaining a
+  # copy of this software and associated documentation files (the "Software"),
+  # to deal in the Software without restriction, including without limitation
+  # the rights to use, copy, modify, merge, publish, distribute, sublicense,
+  # and/or sell copies of the Software, and to permit persons to whom the
+  # Software is furnished to do so, subject to the following conditions:
+  #
+  # The above copyright notice and this permission notice shall be included in
+  # all copies or substantial portions of the Software.
+  #
+  # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+  # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+  # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+  # THE XFREE86 PROJECT BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+  # WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+  # OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+  # SOFTWARE.
+  #
+  # Except as contained in this notice, the name of the XFree86 Project shall
+  # not be used in advertising or otherwise to promote the sale, use or other
+  # dealings in this Software without prior written authorization from the
+  # XFree86 Project.
+  #
+  # $XConsortium: XF86Conf.cpp /main/16 1996/01/31 10:03:57 kaleb $
+
+  # **********************************************************************
+  # Refer to the XF86Config(4/5) man page for details about the format of
+  # this file. This man page is installed as /usr/X11R6/man/man5/XF86Config.5x
+  # **********************************************************************
+
+  # **********************************************************************
+  # Files section.  This allows default font and rgb paths to be set
+  # **********************************************************************
+
+  Section "Files"
+  # The location of the RGB database.  Note, this is the name of the
+  # file minus the extension (like ".txt" or ".db").  There is normally
+  # no need to change the default.
+
+      RgbPath		"/usr/X11R6/lib/X11/rgb"
+
+  # Multiple FontPath entries are allowed (which are concatenated together),
+  # as well as specifying multiple comma-separated entries in one FontPath
+  # command (or a combination of both methods)
+
+      FontPath	"/usr/X11R6/lib/X11/fonts/misc/"
+  #   FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled"
+  #   FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled"
+      FontPath	"/usr/lib/ghostscript/fonts/"
+      FontPath	"/usr/X11R6/lib/X11/fonts/Type1/"
+      FontPath	"/usr/X11R6/lib/X11/fonts/Speedo/"
+      FontPath	"/usr/X11R6/lib/X11/fonts/75dpi/"
+      FontPath	"/usr/X11R6/lib/X11/fonts/100dpi/"
+
+      FontPath	"/usr/X11R6/lib/X11/fonts/sharefont/"
+  EndSection
+
+  # **********************************************************************
+  # Server flags section.
+  # **********************************************************************
+
+  Section "ServerFlags"
+  # Uncomment this to cause a core dump at the spot where a signal is
+  # received.  This may leave the console in an unusable state, but may
+  # provide a better stack trace in the core dump to aid in debugging
+
+  #   NoTrapSignals
+
+  # Uncomment this to disable the <Crtl><Alt><BS> server abort sequence
+  # This allows clients to receive this key event.
+
+  #   DontZap
+
+  # Uncomment this to disable the <Crtl><Alt><KP_+>/<KP_-> mode switching
+  # sequences.  This allows clients to receive these key events.
+
+  #   DontZoom
+
+  # Uncomment this to disable tuning with the xvidtune client. With
+  # it the client can still run and fetch card and monitor attributes,
+  # but it will not be allowed to change them. If it tries it will
+  # receive a protocol error.
+
+  #   DisableVidModeExtension
+
+  # Uncomment this to enable the use of a non-local xvidtune client.
+
+  #   AllowNonLocalXvidtune
+  EndSection
+
+  # **********************************************************************
+  # Input devices
+  # **********************************************************************
+
+  # **********************************************************************
+  # Keyboard section
+  # **********************************************************************
+
+  Section "Keyboard"
+      Protocol		"Standard"
+
+  # when using XQUEUE, comment out the above line, and uncomment the
+  # following line
+
+  #   Protocol		"Xqueue"
+
+      AutoRepeat	500 5
+
+  # Let the server do the NumLock processing.  This should only be required
+  # when using pre-R6 clients
+  #   ServerNumLock
+
+  # Specifiy which keyboard LEDs can be user-controlled (eg, with xset(1))
+  #   Xleds		1 2 3
+
+  # To set the LeftAlt to Meta, RightAlt key to ModeShift,
+  # RightCtl key to Compose, and ScrollLock key to ModeLock:
+
+  #   LeftAlt		Meta
+  #   RightAlt		ModeShift
+  #   RightCtl		Compose
+  #   ScrollLock	ModeLock
+
+  # To disable the XKEYBOARD extension, uncomment XkbDisable.
+
+      XkbDisable
+
+  # To use the default map in ProjectRoot keymap/xfree86, uncomment
+  # XkbKeymap. To use one of the alternate maps in keymap/xfree86
+  # uncomment and modify the XkbKeymap line, e.g.:
+  #   XkbKeymap		"keymap/xfree86(us_microsoft)"
+  # To tailor a combination not already in keymap/xfree86 modify
+  # keymap/xfree86 or uncomment and modify the other lines as
+  # desired. One way to get a german layout on a 101 key keyboard
+  # is to modify the XkbSymbols line, e.g.:
+  #   XkbSymbols	"symbols/us(pc101)+de"
+
+      XkbKeymap		"keymap/xfree86"
+      Xkbkeycodes	"keycodes/xfree86"
+      XkbTypes		"types/default"
+      XkbCompat		"compat/default"
+      XkbSymbols	"symbols/de(pc102)"
+      XkbGeometry	"geometry/pc"
+  EndSection
+
+
+  # **********************************************************************
+  # Pointer section
+  # **********************************************************************
+
+  Section "Pointer"
+      Protocol		"PS/2"
+      Device		"/dev/mouse"
+
+  # When using XQUEUE, comment out the above two lines, and uncomment
+  # the following line.
+
+  #   Protocol		"Xqueue"
+
+  # Baudrate and SampleRate are only for some Logitech mice
+
+  #   BaudRate		9600
+  #   SampleRate	150
+
+  # Emulate3Buttons is an option for 2-button Microsoft mice
+  # Emulate3Timeout is the timeout in milliseconds (default is 50ms)
+
+  #   Emulate3Buttons
+  #   Emulate3Timeout	50
+
+  # ChordMiddle is an option for some 3-button Logitech mice
+
+  #   ChordMiddle
+  EndSection
+
+
+  # **********************************************************************
+  # Xinput section -- this is optional and is required only if you
+  # are using extended input devices.  This is for example only.  Refer
+  # to the XF86Config man page for a description of the options.
+  # **********************************************************************
+  #
+  # Section "Xinput"
+  #    SubSection "WacomStylus"
+  #        Port "/dev/ttyS1"
+  #        DeviceName "Wacom"
+  #    EndSubSection
+  #    SubSection "WacomCursor"
+  #    EndSubSection
+  #    SubSection "WacomEraser"
+  #    EndSubSection
+  #
+  #    SubSection "Elographics"
+  #        Port "/dev/ttyS1"
+  #        DeviceName "Elo"
+  #        MinimumXPosition 300
+  #        MaximumXPosition 3500
+  #        MinimumYPosition 300
+  #        MaximumYPosition 3500
+  #        Screen 0
+  #        UntouchDelay 10
+  #        ReportDelay 10
+  #    EndSubSection
+  #
+  #    SubSection "Joystick"
+  #        Port "/dev/joy0"
+  #        DeviceName "Joystick"
+  #        TimeOut 10
+  #        MinimumXPosition 100
+  #        MaximumXPosition 1300
+  #        MinimumYPosition 100
+  #        MaximumYPosition 1100
+  #        # CenterX 700
+  #        # CenterY 600
+  #        Delta 20
+  #    EndSubSection
+  # EndSection
+
+
+  # **********************************************************************
+  # Monitor section
+  # **********************************************************************
+
+  # Any number of monitor sections may be present
+
+  Section "Monitor"
+      Identifier	"Panasonic PanaSync/Pro5"
+      VendorName	"Panasonic"
+      ModelName		"PanaSync/Pro5"
+
+  # HorizSync is in kHz unless units are specified.
+  # HorizSync may be a comma separated list of discrete values, or a
+  # comma separated list of ranges of values.
+  # NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
+  # USER MANUAL FOR THE CORRECT NUMBERS.
+
+  #   HorizSync		31.5  # typical for a single frequency fixed-sync monitor
+
+  #   HorizSync		15-40         # multisync
+  #   HorizSync		30-64         # multisync
+  #   HorizSync		31.5, 35.2    # multiple fixed sync frequencies
+  #   HorizSync		15-25, 30-50  # multiple ranges of sync frequencies
+
+      HorizSync		31-84
+
+  # VertRefresh is in Hz unless units are specified.
+  # VertRefresh may be a comma separated list of discrete values, or a
+  # comma separated list of ranges of values.
+  # NOTE: THE VALUES HERE ARE EXAMPLES ONLY.  REFER TO YOUR MONITOR'S
+  # USER MANUAL FOR THE CORRECT NUMBERS.
+
+  #   VertRefresh	60  # typical for a single frequency fixed-sync monitor
+
+  #   VertRefresh	50-100        # multisync
+  #   VertRefresh	60, 65        # multiple fixed sync frequencies
+  #   VertRefresh	40-50, 80-100 # multiple ranges of sync frequencies
+
+      VertRefresh	50-90
+
+  # Modes can be specified in two formats. A compact one-line format, or
+  # a multi-line format.
+
+      ModeLine "640x480" 30.438 640 704 768 832 480 512 514 546 -HSync -VSync
+      ModeLine "800x600" 49.553 800 864 928 992 600 632 634 666 -HSync -VSync
+      ModeLine "832x624" 52.995 832 896 960 1024 624 656 658 690 -HSync -VSync
+  #   ModeLine "1024x768" 76.064 1024 1088 1152 1216 768 800 802 834 -HSync -VSync
+      ModeLine "1024x768" 99.801 1024 1024 1120 1312 768 789 804 845 -HSync -VSync
+      ModeLine "1152x870" 94.358 1152 1216 1280 1344 870 902 904 936 -HSync -VSync
+      ModeLine "1152x900" 130.000 1152 1320 1360 1620 900 901 905 943 +HSync +VSync
+      ModeLine "1280x960"  125.645 1280 1312 1456 1680 960 961 964 1000 -HSync -VSync
+      ModeLine "1280x1024" 144.551 1280 1352 1496 1632 1024 1025 1028 1059 +HSync +VSync
+      ModeLine "1280x1024" 155.000 1280 1384 1528 1688 1024 1025 1028 1066 +HSync +VSync
+  EndSection
+
+  # **********************************************************************
+  # Server for the Linux Frame Buffer Device
+  # **********************************************************************
+
+  Section "Device"
+      Identifier	"Linux Frame Buffer Device"
+  #   Option		"no_accel"
+  EndSection
+
+  Section "Screen"
+      Driver		"fbdev"
+      Device		"Linux Frame Buffer Device"
+      Monitor		"Panasonic PanaSync/Pro5"
+      DefaultColorDepth	16
+      SubSection "Display"
+          Modes		"1280x960" "1152x900" "1024x768" "800x600" "640x480"
+          Depth		8
+          Virtual	1280 960
+      EndSubSection
+      SubSection "Display"
+          Depth		15
+          Modes		"1280x960" "1152x900" "1024x768" "800x600" "640x480"
+          Virtual	1280 960
+      EndSubSection
+      SubSection "Display"
+          Depth		16
+          Modes		"1280x960" "1152x900" "1024x768" "800x600" "640x480"
+          Virtual	1280 960
+      EndSubSection
+      SubSection "Display"
+          Depth		24
+          Modes		"1280x960" "1152x900" "1024x768" "800x600" "640x480"
+          Virtual	1280 960
+      EndSubSection
+      SubSection "Display"
+          Depth		32
+          Modes		"1152x900" "1024x768" "800x600" "640x480"
+          Virtual	1152 900
+      EndSubSection
+  EndSection
+
+
+
+==============================================================================
+
+Answers were given by:
+{HK} Hartmut Koptein, <koptein@debian.org>
+{ibr} Baurjan Ismagulov, <ibr@ata.cs.hun.edu.tr>
+{GJ} Guillem Jover, <guillem@debian.org>
+
--- fbset-2.1.orig/debian/doc/kernel-doc/sstfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/sstfb.txt
@@ -0,0 +1,174 @@
+
+Introduction
+
+	  This is a frame buffer device driver for 3dfx' Voodoo Graphics 
+	(aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based 
+	video boards. It's highly experimental code, but is guaranteed to work
+	on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
+	and with me "between chair and keyboard". Some people tested other
+	combinations and it seems that it works.
+	  The main page is located at <http://sstfb.sourceforge.net>, and if
+	you want the latest version, check out the CVS, as the driver is a work
+	in progress, I feel uncomfortable with releasing tarballs of something
+	not completely working...Don't worry, it's still more than useable
+	(I eat my own dog food)
+
+	  Please read the Bug section, and report any success or failure to me
+	(Ghozlane Toumi <gtoumi@laposte.net>).
+	  BTW, If you have only one monitor , and you don't feel like playing
+	with the vga passthrou cable, I can only suggest borrowing a screen
+	somewhere... 
+
+
+Installation 
+
+	  This driver (should) work on ix86, with "late" 2.2.x kernel (tested
+	with x = 19) and "recent" 2.4.x kernel, as a module or compiled in.
+	  It has been included in mainstream kernel since the infamous 2.4.10.
+	  You can apply the patches found in sstfb/kernel/*-2.{2|4}.x.patch,
+	and copy sstfb.c to linux/drivers/video/, or apply a single patch, 
+	sstfb/patch-2.{2|4}.x-sstfb-yymmdd to your linux source tree.
+
+	  Then configure your kernel as usual: choose "m" or "y" to 3Dfx Voodoo
+	Graphics in section "console". Compile, install, have fun... and please
+	drop me a report :)
+
+
+Module Usage
+	
+	Warnings.
+	# You should read completely this section before issuing any command.
+	# If you have only one monitor to play with, once you insmod the
+	  module, the 3dfx takes control of the output, so you'll have to
+	  plug the monitor to the "normal" video board in order to issue
+	  the commands, or you can blindly use sst_dbg_vgapass
+          in the tools directory (See Tools). The latest solution is pass the
+	  parameter vgapass=1 when insmodding the driver. (See Kernel/Modules
+	  Options)
+
+	Module insertion:
+	# insmod sstfb.o
+	  you should see some strange output from the board: 
+	  a big blue square, a green and a red small squares and a vertical
+	  white rectangle. why? the function's name is self-explanatory:
+	  "sstfb_test()"...
+	  (if you don't have a second monitor, you'll have to plug your monitor
+	  directly to the 2D videocard to see what you're typing)
+	# con2fb /dev/fbx /dev/ttyx
+	  bind a tty to the new frame buffer. if you already have a frame
+	  buffer driver, the voodoo fb will likely be /dev/fb1. if not, 
+	  the device will be /dev/fb0. You can check this by doing a 
+	  cat /proc/fb. You can find a copy of con2fb in tools/ directory.
+	  if you don't have another fb device, this step is superfluous,
+	  as the console subsystem automagicaly binds ttys to the fb.
+	# switch to the virtual console you just mapped. "tadaaa" ...
+
+	Module removal:
+	# con2fb /dev/fbx /dev/ttyx
+	  bind the tty to the old frame buffer so the module can be removed.
+	  (how does it work with vgacon ? short answer : it doesn't work)
+	# rmmod sstfb
+
+
+Kernel/Modules Options
+
+	You can pass some options to the sstfb module, and via the kernel 
+	command line when the driver is compiled in:
+	for module : insmod sstfb.o option1=value1 option2=value2 ...
+	in kernel :  video=sstfb:option1,option2:value2,option3 ...
+	
+	sstfb supports the following options :
+
+Module		Kernel		Description
+
+vgapass=0	vganopass	Enable or disable VGA passthrou cable.
+vgapass=1	vgapass		When enabled, the monitor will get the signal
+				from the VGA board and not from the voodoo.
+				Default: nopass
+
+mem=x		mem:x		Force frame buffer memory in MiB
+				allowed values: 0, 1, 2, 4.
+				Default: 0 (= autodetect)
+
+inverse=1	inverse		Supposed to enable inverse console.
+				doesn't work yet...
+
+clipping=1	clipping	Enable or disable clipping.
+clipping=0	noclipping	With clipping enabled, all offscreen
+				reads and writes are discarded.
+				Default: enable clipping.
+
+gfxclk=x	gfxclk:x	Force graphic clock frequency (in MHz).
+				Be careful with this option, it may be
+				DANGEROUS.
+				Default: auto 
+					50Mhz for Voodoo 1,
+					75MHz for Voodoo 2. 
+
+slowpci=1	fastpci		Enable or disable fast PCI read/writes.
+slowpci=1	slowpci		Default : fastpci
+
+dev=x		dev:x		Attach the driver to device number x.
+				0 is the first compatible board (in 
+				lspci order)
+
+Tools
+
+	These tools are mostly for debugging purposes, but you can 
+	find some of these interesting :
+	 - con2fb , maps a tty to a fbramebuffer .
+		con2fb /dev/fb1 /dev/tty5
+	 - sst_dbg_vgapass , changes vga passthrou. You have to recompile the
+	driver with SST_DEBUG and SST_DEBUG_IOCTL set to 1
+		sst_dbg_vgapass /dev/fb1 1 (enables vga cable)
+		sst_dbg_vgapass /dev/fb1 0 (disables vga cable)
+	 - glide_reset , resets the voodoo using glide
+		use this after rmmoding sstfb, if the module refuses to
+		reinsert .
+
+Bugs
+
+	- DO NOT use glide while the sstfb module is in, you'll most likely
+	hang your computer.
+	- If you see some artefacts (pixels not cleaning and stuff like that), 
+	try turning off clipping (clipping=0), and/or using slowpci
+	- the driver don't detect the 4Mb frame buffer voodoos, it seems that
+	the 2 last Mbs wrap around. looking into that .
+	- The driver is 16 bpp only, 24/32 won't work.
+	- The driver is not your_favorite_toy-safe. this includes SMP...
+          [Actually from inspection it seems to be safe - Alan]
+	- When using XFree86 FBdev (X over fbdev) you may see strange color
+	patterns at the border of your windows (the pixels lose the lowest
+	byte -> basically the blue component and some of the green). I'm unable
+	to reproduce this with XFree86-3.3, but one of the testers has this
+	problem with XFree86-4. Apparently recent Xfree86-4.x solve this
+	problem.
+	- I didn't really test changing the palette, so you may find some weird
+	things when playing with that.
+	- Sometimes the driver will not recognise the DAC, and the
+        initialisation will fail. This is specifically true for
+	voodoo 2 boards, but it should be solved in recent versions. Please
+	contact me.
+	- The 24/32 is not likely to work anytime soon, knowing that the
+	hardware does ... unusual things in 24/32 bpp.
+	- When used with another video board, current limitations of the linux
+	console subsystem can cause some troubles, specifically, you should
+	disable software scrollback, as it can oops badly ...
+
+Todo
+
+	- Get rid of the previous paragraph.
+	- Buy more coffee.
+	- test/port to other arch.
+	- try to add panning using tweeks with front and back buffer .
+	- try to implement accel on voodoo2, this board can actually do a 
+	  lot in 2D even if it was sold as a 3D only board ...
+
+ghoz.
+
+-- 
+Ghozlane Toumi <gtoumi@laposte.net>
+
+
+$Date: 2002/05/09 20:11:45 $
+http://sstfb.sourceforge.net/README
--- fbset-2.1.orig/debian/doc/kernel-doc/sa1100fb.txt
+++ fbset-2.1/debian/doc/kernel-doc/sa1100fb.txt
@@ -0,0 +1,39 @@
+[This file is cloned from VesaFB/matroxfb]
+
+What is sa1100fb?
+=================
+
+This is a driver for a graphic framebuffer for the SA-1100 LCD
+controller.
+
+Configuration
+==============
+
+For most common passive displays, giving the option
+
+video=sa1100fb:bpp:<value>,lccr0:<value>,lccr1:<value>,lccr2:<value>,lccr3:<value>
+
+on the kernel command line should be enough to configure the
+controller. The bits per pixel (bpp) value should be 4, 8, 12, or
+16. LCCR values are display-specific and should be computed as
+documented in the SA-1100 Developer's Manual, Section 11.7. Dual-panel
+displays are supported as long as the SDS bit is set in LCCR0; GPIO<9:2>
+are used for the lower panel.
+
+For active displays or displays requiring additional configuration
+(controlling backlights, powering on the LCD, etc.), the command line
+options may not be enough to configure the display. Adding sections to
+sa1100fb_init_fbinfo(), sa1100fb_activate_var(),
+sa1100fb_disable_lcd_controller(), and sa1100fb_enable_lcd_controller()
+will probably be necessary.
+
+Accepted options:
+
+bpp:<value>	Configure for <value> bits per pixel
+lccr0:<value>	Configure LCD control register 0 (11.7.3)
+lccr1:<value>	Configure LCD control register 1 (11.7.4)
+lccr2:<value>	Configure LCD control register 2 (11.7.5)
+lccr3:<value>	Configure LCD control register 3 (11.7.6)
+
+--
+Mark Huang <mhuang@livetoy.com>
--- fbset-2.1.orig/debian/doc/kernel-doc/fbcon.txt
+++ fbset-2.1/debian/doc/kernel-doc/fbcon.txt
@@ -0,0 +1,324 @@
+The Framebuffer Console
+=======================
+
+	The framebuffer console (fbcon), as its name implies, is a text
+console running on top of the framebuffer device. It has the functionality of
+any standard text console driver, such as the VGA console, with the added
+features that can be attributed to the graphical nature of the framebuffer.
+
+	 In the x86 architecture, the framebuffer console is optional, and
+some even treat it as a toy. For other architectures, it is the only available
+display device, text or graphical.
+
+	 What are the features of fbcon?  The framebuffer console supports
+high resolutions, varying font types, display rotation, primitive multihead,
+etc. Theoretically, multi-colored fonts, blending, aliasing, and any feature
+made available by the underlying graphics card are also possible.
+
+A. Configuration
+
+	The framebuffer console can be enabled by using your favorite kernel
+configuration tool.  It is under Device Drivers->Graphics Support->Support for
+framebuffer devices->Framebuffer Console Support. Select 'y' to compile
+support statically, or 'm' for module support.  The module will be fbcon.
+
+	In order for fbcon to activate, at least one framebuffer driver is
+required, so choose from any of the numerous drivers available. For x86
+systems, they almost universally have VGA cards, so vga16fb and vesafb will
+always be available. However, using a chipset-specific driver will give you
+more speed and features, such as the ability to change the video mode
+dynamically.
+
+	To display the penguin logo, choose any logo available in Logo
+Configuration->Boot up logo.
+
+	Also, you will need to select at least one compiled-in fonts, but if
+you don't do anything, the kernel configuration tool will select one for you,
+usually an 8x16 font.
+
+GOTCHA: A common bug report is enabling the framebuffer without enabling the
+framebuffer console.  Depending on the driver, you may get a blanked or
+garbled display, but the system still boots to completion.  If you are
+fortunate to have a driver that does not alter the graphics chip, then you
+will still get a VGA console.
+
+B. Loading
+
+Possible scenarios:
+
+1. Driver and fbcon are compiled statically
+
+	 Usually, fbcon will automatically take over your console. The notable
+	 exception is vesafb.  It needs to be explicitly activated with the
+	 vga= boot option parameter.
+
+2. Driver is compiled statically, fbcon is compiled as a module
+
+	 Depending on the driver, you either get a standard console, or a
+	 garbled display, as mentioned above.  To get a framebuffer console,
+	 do a 'modprobe fbcon'.
+
+3. Driver is compiled as a module, fbcon is compiled statically
+
+	 You get your standard console.  Once the driver is loaded with
+	 'modprobe xxxfb', fbcon automatically takes over the console with
+	 the possible exception of using the fbcon=map:n option. See below.
+
+4. Driver and fbcon are compiled as a module.
+
+	 You can load them in any order. Once both are loaded, fbcon will take
+	 over the console.
+
+C. Boot options
+
+         The framebuffer console has several, largely unknown, boot options
+         that can change its behavior.
+
+1. fbcon=font:<name>
+
+        Select the initial font to use. The value 'name' can be any of the
+        compiled-in fonts: VGA8x16, 7x14, 10x18, VGA8x8, MINI4x6, RomanLarge,
+        SUN8x16, SUN12x22, ProFont6x11, Acorn8x8, PEARL8x8.
+
+	Note, not all drivers can handle font with widths not divisible by 8,
+        such as vga16fb.
+
+2. fbcon=scrollback:<value>[k]
+
+        The scrollback buffer is memory that is used to preserve display
+        contents that has already scrolled past your view.  This is accessed
+        by using the Shift-PageUp key combination.  The value 'value' is any
+        integer. It defaults to 32KB.  The 'k' suffix is optional, and will
+        multiply the 'value' by 1024.
+
+3. fbcon=map:<0123>
+
+        This is an interesting option. It tells which driver gets mapped to
+        which console. The value '0123' is a sequence that gets repeated until
+        the total length is 64 which is the number of consoles available. In
+        the above example, it is expanded to 012301230123... and the mapping
+        will be:
+
+		tty | 1 2 3 4 5 6 7 8 9 ...
+		fb  | 0 1 2 3 0 1 2 3 0 ...
+
+		('cat /proc/fb' should tell you what the fb numbers are)
+
+	One side effect that may be useful is using a map value that exceeds
+	the number of loaded fb drivers. For example, if only one driver is
+	available, fb0, adding fbcon=map:1 tells fbcon not to take over the
+	console.
+
+	Later on, when you want to map the console the to the framebuffer
+	device, you can use the con2fbmap utility.
+
+4. fbcon=vc:<n1>-<n2>
+
+	This option tells fbcon to take over only a range of consoles as
+	specified by the values 'n1' and 'n2'. The rest of the consoles
+	outside the given range will still be controlled by the standard
+	console driver.
+
+	NOTE: For x86 machines, the standard console is the VGA console which
+	is typically located on the same video card.  Thus, the consoles that
+	are controlled by the VGA console will be garbled.
+
+4. fbcon=rotate:<n>
+
+        This option changes the orientation angle of the console display. The
+        value 'n' accepts the following:
+
+	      0 - normal orientation (0 degree)
+	      1 - clockwise orientation (90 degrees)
+	      2 - upside down orientation (180 degrees)
+	      3 - counterclockwise orientation (270 degrees)
+
+	The angle can be changed anytime afterwards by 'echoing' the same
+	numbers to any one of the 2 attributes found in
+	 /sys/class/graphics/fbcon
+
+		rotate     - rotate the display of the active console
+		rotate_all - rotate the display of all consoles
+
+	Console rotation will only become available if Console Rotation
+	Support is compiled in your kernel.
+
+	NOTE: This is purely console rotation.  Any other applications that
+	use the framebuffer will remain at their 'normal'orientation.
+	Actually, the underlying fb driver is totally ignorant of console
+	rotation.
+
+C. Attaching, Detaching and Unloading
+
+Before going on on how to attach, detach and unload the framebuffer console, an
+illustration of the dependencies may help.
+
+The console layer, as with most subsystems, needs a driver that interfaces with
+the hardware. Thus, in a VGA console:
+
+console ---> VGA driver ---> hardware.
+
+Assuming the VGA driver can be unloaded, one must first unbind the VGA driver
+from the console layer before unloading the driver.  The VGA driver cannot be
+unloaded if it is still bound to the console layer. (See
+Documentation/console/console.txt for more information).
+
+This is more complicated in the case of the framebuffer console (fbcon),
+because fbcon is an intermediate layer between the console and the drivers:
+
+console ---> fbcon ---> fbdev drivers ---> hardware
+
+The fbdev drivers cannot be unloaded if it's bound to fbcon, and fbcon cannot
+be unloaded if it's bound to the console layer.
+
+So to unload the fbdev drivers, one must first unbind fbcon from the console,
+then unbind the fbdev drivers from fbcon.  Fortunately, unbinding fbcon from
+the console layer will automatically unbind framebuffer drivers from
+fbcon. Thus, there is no need to explicitly unbind the fbdev drivers from
+fbcon.
+
+So, how do we unbind fbcon from the console? Part of the answer is in
+Documentation/console/console.txt. To summarize:
+
+Echo a value to the bind file that represents the framebuffer console
+driver. So assuming vtcon1 represents fbcon, then:
+
+echo 1 > sys/class/vtconsole/vtcon1/bind - attach framebuffer console to
+                                           console layer
+echo 0 > sys/class/vtconsole/vtcon1/bind - detach framebuffer console from
+                                           console layer
+
+If fbcon is detached from the console layer, your boot console driver (which is
+usually VGA text mode) will take over.  A few drivers (rivafb and i810fb) will
+restore VGA text mode for you.  With the rest, before detaching fbcon, you
+must take a few additional steps to make sure that your VGA text mode is
+restored properly. The following is one of the several methods that you can do:
+
+1. Download or install vbetool.  This utility is included with most
+   distributions nowadays, and is usually part of the suspend/resume tool.
+
+2. In your kernel configuration, ensure that CONFIG_FRAMEBUFFER_CONSOLE is set
+   to 'y' or 'm'. Enable one or more of your favorite framebuffer drivers.
+
+3. Boot into text mode and as root run:
+
+	vbetool vbestate save > <vga state file>
+
+	The above command saves the register contents of your graphics
+	hardware to <vga state file>.  You need to do this step only once as
+	the state file can be reused.
+
+4. If fbcon is compiled as a module, load fbcon by doing:
+
+       modprobe fbcon
+
+5. Now to detach fbcon:
+
+       vbetool vbestate restore < <vga state file> && \
+       echo 0 > /sys/class/vtconsole/vtcon1/bind
+
+6. That's it, you're back to VGA mode. And if you compiled fbcon as a module,
+   you can unload it by 'rmmod fbcon'
+
+7. To reattach fbcon:
+
+       echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+8. Once fbcon is unbound, all drivers registered to the system will also
+become unbound.  This means that fbcon and individual framebuffer drivers
+can be unloaded or reloaded at will. Reloading the drivers or fbcon will
+automatically bind the console, fbcon and the drivers together. Unloading
+all the drivers without unloading fbcon will make it impossible for the
+console to bind fbcon.
+
+Notes for vesafb users:
+=======================
+
+Unfortunately, if your bootline includes a vga=xxx parameter that sets the
+hardware in graphics mode, such as when loading vesafb, vgacon will not load.
+Instead, vgacon will replace the default boot console with dummycon, and you
+won't get any display after detaching fbcon. Your machine is still alive, so
+you can reattach vesafb. However, to reattach vesafb, you need to do one of
+the following:
+
+Variation 1:
+
+    a. Before detaching fbcon, do
+
+       vbetool vbemode save > <vesa state file> # do once for each vesafb mode,
+						# the file can be reused
+
+    b. Detach fbcon as in step 5.
+
+    c. Attach fbcon
+
+        vbetool vbestate restore < <vesa state file> && \
+	echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+Variation 2:
+
+    a. Before detaching fbcon, do:
+	echo <ID> > /sys/class/tty/console/bind
+
+
+       vbetool vbemode get
+
+    b. Take note of the mode number
+
+    b. Detach fbcon as in step 5.
+
+    c. Attach fbcon:
+
+       vbetool vbemode set <mode number> && \
+       echo 1 > /sys/class/vtconsole/vtcon1/bind
+
+Samples:
+========
+
+Here are 2 sample bash scripts that you can use to bind or unbind the
+framebuffer console driver if you are in an X86 box:
+
+---------------------------------------------------------------------------
+#!/bin/bash
+# Unbind fbcon
+
+# Change this to where your actual vgastate file is located
+# Or Use VGASTATE=$1 to indicate the state file at runtime
+VGASTATE=/tmp/vgastate
+
+# path to vbetool
+VBETOOL=/usr/local/bin
+
+
+for (( i = 0; i < 16; i++))
+do
+  if test -x /sys/class/vtconsole/vtcon$i; then
+      if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
+           = 1 ]; then
+	    if test -x $VBETOOL/vbetool; then
+	       echo Unbinding vtcon$i
+	       $VBETOOL/vbetool vbestate restore < $VGASTATE
+	       echo 0 > /sys/class/vtconsole/vtcon$i/bind
+	    fi
+      fi
+  fi
+done
+
+---------------------------------------------------------------------------
+#!/bin/bash
+# Bind fbcon
+
+for (( i = 0; i < 16; i++))
+do
+  if test -x /sys/class/vtconsole/vtcon$i; then
+      if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
+           = 1 ]; then
+	  echo Unbinding vtcon$i
+	  echo 1 > /sys/class/vtconsole/vtcon$i/bind
+      fi
+  fi
+done
+---------------------------------------------------------------------------
+
+--
+Antonino Daplas <adaplas@pol.net>
--- fbset-2.1.orig/debian/doc/kernel-doc/deferred_io.txt
+++ fbset-2.1/debian/doc/kernel-doc/deferred_io.txt
@@ -0,0 +1,75 @@
+Deferred IO
+-----------
+
+Deferred IO is a way to delay and repurpose IO. It uses host memory as a
+buffer and the MMU pagefault as a pretrigger for when to perform the device
+IO. The following example may be a useful explaination of how one such setup
+works:
+
+- userspace app like Xfbdev mmaps framebuffer
+- deferred IO and driver sets up nopage and page_mkwrite handlers
+- userspace app tries to write to mmaped vaddress
+- we get pagefault and reach nopage handler
+- nopage handler finds and returns physical page
+- we get page_mkwrite where we add this page to a list
+- schedule a workqueue task to be run after a delay
+- app continues writing to that page with no additional cost. this is
+  the key benefit.
+- the workqueue task comes in and mkcleans the pages on the list, then
+ completes the work associated with updating the framebuffer. this is
+  the real work talking to the device.
+- app tries to write to the address (that has now been mkcleaned)
+- get pagefault and the above sequence occurs again
+
+As can be seen from above, one benefit is roughly to allow bursty framebuffer
+writes to occur at minimum cost. Then after some time when hopefully things
+have gone quiet, we go and really update the framebuffer which would be
+a relatively more expensive operation.
+
+For some types of nonvolatile high latency displays, the desired image is
+the final image rather than the intermediate stages which is why it's okay
+to not update for each write that is occuring.
+
+It may be the case that this is useful in other scenarios as well. Paul Mundt
+has mentioned a case where it is beneficial to use the page count to decide
+whether to coalesce and issue SG DMA or to do memory bursts.
+
+Another one may be if one has a device framebuffer that is in an usual format,
+say diagonally shifting RGB, this may then be a mechanism for you to allow
+apps to pretend to have a normal framebuffer but reswizzle for the device
+framebuffer at vsync time based on the touched pagelist.
+
+How to use it: (for applications)
+---------------------------------
+No changes needed. mmap the framebuffer like normal and just use it.
+
+How to use it: (for fbdev drivers)
+----------------------------------
+The following example may be helpful.
+
+1. Setup your structure. Eg:
+
+static struct fb_deferred_io hecubafb_defio = {
+	.delay		= HZ,
+	.deferred_io	= hecubafb_dpy_deferred_io,
+};
+
+The delay is the minimum delay between when the page_mkwrite trigger occurs
+and when the deferred_io callback is called. The deferred_io callback is
+explained below.
+
+2. Setup your deferred IO callback. Eg:
+static void hecubafb_dpy_deferred_io(struct fb_info *info,
+				struct list_head *pagelist)
+
+The deferred_io callback is where you would perform all your IO to the display
+device. You receive the pagelist which is the list of pages that were written
+to during the delay. You must not modify this list. This callback is called
+from a workqueue.
+
+3. Call init
+	info->fbdefio = &hecubafb_defio;
+	fb_deferred_io_init(info);
+
+4. Call cleanup
+	fb_deferred_io_cleanup(info);
--- fbset-2.1.orig/debian/doc/kernel-doc/intel810.txt
+++ fbset-2.1/debian/doc/kernel-doc/intel810.txt
@@ -0,0 +1,278 @@
+Intel 810/815 Framebuffer driver
+ 	Tony Daplas <adaplas@pol.net>
+	http://i810fb.sourceforge.net
+
+	March 17, 2002
+
+	First Released: July 2001
+	Last Update:    September 12, 2005
+================================================================
+
+A. Introduction
+
+	This is a framebuffer driver for various Intel 810/815 compatible
+	graphics devices.  These include:
+
+	Intel 810
+	Intel 810E
+	Intel 810-DC100
+	Intel 815 Internal graphics only, 100Mhz FSB
+	Intel 815 Internal graphics only
+	Intel 815 Internal graphics and AGP
+
+B.  Features
+
+	- Choice of using Discrete Video Timings, VESA Generalized Timing
+	  Formula, or a framebuffer specific database to set the video mode
+
+	- Supports a variable range of horizontal and vertical resolution and
+	  vertical refresh rates if the VESA Generalized Timing Formula is
+	  enabled.
+
+	- Supports color depths of 8, 16, 24 and 32 bits per pixel
+
+	- Supports pseudocolor, directcolor, or truecolor visuals
+
+	- Full and optimized hardware acceleration at 8, 16 and 24 bpp
+
+	- Robust video state save and restore
+
+	- MTRR support
+
+	- Utilizes user-entered monitor specifications to automatically
+	  calculate required video mode parameters.
+
+	- Can concurrently run with xfree86 running with native i810 drivers
+
+	- Hardware Cursor Support
+ 
+	- Supports EDID probing either by DDC/I2C or through the BIOS
+
+C.  List of available options
+
+   a. "video=i810fb"
+	enables the i810 driver
+
+	Recommendation: required
+
+   b. "xres:<value>"
+	select horizontal resolution in pixels. (This parameter will be
+	ignored if 'mode_option' is specified.  See 'o' below).
+
+	Recommendation: user preference
+	(default = 640)
+
+   c. "yres:<value>"
+	select vertical resolution in scanlines. If Discrete Video Timings
+	is enabled, this will be ignored and computed as 3*xres/4.  (This
+	parameter will be ignored if 'mode_option' is specified.  See 'o'
+	below)
+
+	Recommendation: user preference
+	(default = 480)
+
+   d. "vyres:<value>"
+	select virtual vertical resolution in scanlines. If (0) or none
+	is specified, this will be computed against maximum available memory.
+
+	Recommendation: do not set
+	(default = 480)
+
+   e. "vram:<value>"
+	select amount of system RAM in MB to allocate for the video memory
+
+	Recommendation: 1 - 4 MB.
+	(default = 4)
+
+   f. "bpp:<value>"
+	select desired pixel depth
+
+	Recommendation: 8
+	(default = 8)
+
+   g. "hsync1/hsync2:<value>"
+	select the minimum and maximum Horizontal Sync Frequency of the
+	monitor in kHz.  If using a fixed frequency monitor, hsync1 must
+	be equal to hsync2. If EDID probing is successful, these will be
+	ignored and values will be taken from the EDID block.
+
+	Recommendation: check monitor manual for correct values
+	(default = 29/30)
+
+   h. "vsync1/vsync2:<value>"
+	select the minimum and maximum Vertical Sync Frequency of the monitor
+	in Hz. You can also use this option to lock your monitor's refresh
+	rate. If EDID probing is successful, these will be ignored and values
+	will be taken from the EDID block.
+
+	Recommendation: check monitor manual for correct values
+	(default = 60/60)
+
+	IMPORTANT:  If you need to clamp your timings, try to give some
+	leeway for computational errors (over/underflows).  Example: if
+	using vsync1/vsync2 = 60/60, make sure hsync1/hsync2 has at least
+	a 1 unit difference, and vice versa.
+
+   i. "voffset:<value>"
+	select at what offset in MB of the logical memory to allocate the
+	framebuffer memory.  The intent is to avoid the memory blocks
+	used by standard graphics applications (XFree86).  The default
+	offset (16 MB for a 64 MB aperture, 8 MB for a 32 MB aperture) will
+	avoid XFree86's usage and allows up to 7 MB/15 MB of framebuffer
+	memory.  Depending on your usage, adjust the value up or down
+	(0 for maximum usage, 31/63 MB for the least amount).  Note, an
+	arbitrary setting may conflict with XFree86.
+
+	Recommendation: do not set
+	(default = 8 or 16 MB)
+
+   j. "accel"
+	enable text acceleration.  This can be enabled/reenabled anytime
+	by using 'fbset -accel true/false'.
+
+	Recommendation: enable
+	(default = not set)
+
+   k. "mtrr"
+	enable MTRR.  This allows data transfers to the framebuffer memory
+	to occur in bursts which can significantly increase performance.
+	Not very helpful with the i810/i815 because of 'shared memory'.
+
+	Recommendation: do not set
+	(default = not set)
+
+   l. "extvga"
+	if specified, secondary/external VGA output will always be enabled.
+	Useful if the BIOS turns off the VGA port when no monitor is attached.
+	The external VGA monitor can then be attached without rebooting.
+
+	Recommendation: do not set
+	(default = not set)
+
+   m. "sync"
+	Forces the hardware engine to do a "sync" or wait for the hardware
+	to finish before starting another instruction. This will produce a
+	more stable setup, but will be slower.
+
+	Recommendation: do not set
+	(default = not set)
+
+   n. "dcolor"
+        Use directcolor visual instead of truecolor for pixel depths greater
+	than 8 bpp.  Useful for color tuning, such as gamma control.
+
+	Recommendation: do not set
+	(default = not set)
+
+   o. <xres>x<yres>[-<bpp>][@<refresh>]
+	The driver will now accept specification of boot mode option.  If this
+	is specified, the options 'xres' and 'yres' will be ignored. See
+	Documentation/fb/modedb.txt for usage.
+
+D. Kernel booting
+
+Separate each option/option-pair by commas (,) and the option from its value
+with a colon (:) as in the following:
+
+video=i810fb:option1,option2:value2
+
+Sample Usage
+------------
+
+In /etc/lilo.conf, add the line:
+
+append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
+        vsync1:50,vsync2:85,accel,mtrr"
+
+This will initialize the framebuffer to 1024x768 at 8bpp.  The framebuffer
+will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
+will be computed based on the hsync1/hsync2 and vsync1/vsync2 values.
+
+IMPORTANT:
+You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
+better than 640x480 at 60Hz. HOWEVER, if your chipset/display combination
+supports I2C and has an EDID block, you can safely exclude hsync1, hsync2,
+vsync1 and vsync2 parameters.  These parameters will be taken from the EDID
+block.
+
+E.  Module options
+
+The module parameters are essentially similar to the kernel
+parameters. The main difference is that you need to include a Boolean value
+(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
+
+Example, to enable MTRR, include "mtrr=1".
+
+Sample Usage
+------------
+
+Using the same setup as described above, load the module like this:
+
+	modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
+	         vsync2=85 accel=1 mtrr=1
+
+Or just add the following to /etc/modprobe.conf
+
+	options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
+	vsync2=85 accel=1 mtrr=1
+
+and just do a
+
+	modprobe i810fb
+
+
+F.  Setup
+
+	a. Do your usual method of configuring the kernel.
+
+	make menuconfig/xconfig/config
+
+	b. Under "Code maturity level options" enable "Prompt for development
+	   and/or incomplete code/drivers".
+
+ 	c. Enable agpgart support for the Intel 810/815 on-board graphics.
+	   This is required.  The option is under "Character Devices".
+
+	d. Under "Graphics Support", select "Intel 810/815" either statically
+	   or as a module.  Choose "use VESA Generalized Timing Formula" if
+	   you need to maximize the capability of your display.  To be on the
+	   safe side, you can leave this unselected.
+
+	e. If you want support for DDC/I2C probing (Plug and Play Displays),
+	   set 'Enable DDC Support' to 'y'. To make this option appear, set
+	   'use VESA Generalized Timing Formula' to 'y'.
+
+        f. If you want a framebuffer console, enable it under "Console
+	   Drivers".
+
+	g. Compile your kernel.
+
+	h. Load the driver as described in sections D and E.
+
+	i.  Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver
+	    patch to see the chipset in action (or inaction :-).
+
+G.  Acknowledgment:
+
+	1.  Geert Uytterhoeven - his excellent howto and the virtual
+	    framebuffer driver code made this possible.
+
+	2.  Jeff Hartmann for his agpgart code.
+
+	3.  The X developers.  Insights were provided just by reading the
+	    XFree86 source code.
+
+	4.  Intel(c).  For this value-oriented chipset driver and for
+	    providing documentation.
+
+	5. Matt Sottek.  His inputs and ideas  helped in making some
+	   optimizations possible.
+
+H.  Home Page:
+
+	A more complete, and probably updated information is provided at
+	http://i810fb.sourceforge.net.
+
+###########################
+Tony
+
--- fbset-2.1.orig/debian/doc/kernel-doc/aty128fb.txt
+++ fbset-2.1/debian/doc/kernel-doc/aty128fb.txt
@@ -0,0 +1,72 @@
+[This file is cloned from VesaFB/matroxfb]
+
+What is aty128fb?
+=================
+
+This is a driver for a graphic framebuffer for ATI Rage128 based devices
+on Intel and PPC boxes.
+
+Advantages:
+
+ * It provides a nice large console (128 cols + 48 lines with 1024x768)
+   without using tiny, unreadable fonts.
+ * You can run XF68_FBDev on top of /dev/fb0
+ * Most important: boot logo :-)
+
+Disadvantages:
+
+ * graphic mode is slower than text mode... but you should not notice
+   if you use same resolution as you used in textmode.
+ * still experimental.
+
+
+How to use it?
+==============
+
+Switching modes is done using the  video=aty128fb:<resolution>... modedb
+boot parameter or using `fbset' program.
+
+See Documentation/fb/modedb.txt for more information on modedb
+resolutions.
+
+You should compile in both vgacon (to boot if you remove your Rage128 from
+box) and aty128fb (for graphics mode). You should not compile-in vesafb
+unless you have primary display on non-Rage128 VBE2.0 device (see 
+Documentation/fb/vesafb.txt for details).
+
+
+X11
+===
+
+XF68_FBDev should generally work fine, but it is non-accelerated. As of
+this document, 8 and 32bpp works fine.  There have been palette issues
+when switching from X to console and back to X.  You will have to restart
+X to fix this.
+
+
+Configuration
+=============
+
+You can pass kernel command line options to vesafb with
+`video=aty128fb:option1,option2:value2,option3' (multiple options should
+be separated by comma, values are separated from options by `:'). 
+Accepted options:
+
+noaccel  - do not use acceleration engine. It is default.
+accel    - use acceleration engine. Not finished.
+vmode:x  - chooses PowerMacintosh video mode <x>. Deprecated.
+cmode:x  - chooses PowerMacintosh colour mode <x>. Deprecated.
+<XxX@X>  - selects startup videomode. See modedb.txt for detailed
+	   explanation. Default is 640x480x8bpp.
+
+
+Limitations
+===========
+
+There are known and unknown bugs, features and misfeatures.
+Currently there are following known bugs:
+ + This driver is still experimental and is not finished.  Too many
+   bugs/errata to list here.
+
+--
+Brad Douglas <brad@neruo.com>
--- fbset-2.1.orig/debian/doc/kernel-doc/pxafb.txt
+++ fbset-2.1/debian/doc/kernel-doc/pxafb.txt
@@ -0,0 +1,54 @@
+Driver for PXA25x LCD controller
+================================
+
+The driver supports the following options, either via
+options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
+
+For example:
+	modprobe pxafb options=mode:640x480-8,passive
+or on the kernel command line
+	video=pxafb:mode:640x480-8,passive
+
+mode:XRESxYRES[-BPP]
+	XRES == LCCR1_PPL + 1
+	YRES == LLCR2_LPP + 1
+		The resolution of the display in pixels
+	BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
+
+pixclock:PIXCLOCK
+	Pixel clock in picoseconds
+
+left:LEFT == LCCR1_BLW + 1
+right:RIGHT == LCCR1_ELW + 1
+hsynclen:HSYNC == LCCR1_HSW + 1
+upper:UPPER == LCCR2_BFW
+lower:LOWER == LCCR2_EFR
+vsynclen:VSYNC == LCCR2_VSW + 1
+	Display margins and sync times
+
+color | mono => LCCR0_CMS
+	umm...
+
+active | passive => LCCR0_PAS
+	Active (TFT) or Passive (STN) display
+
+single | dual => LCCR0_SDS
+	Single or dual panel passive display
+
+4pix | 8pix => LCCR0_DPD
+	4 or 8 pixel monochrome single panel data
+
+hsync:HSYNC
+vsync:VSYNC
+	Horizontal and vertical sync. 0 => active low, 1 => active
+	high.
+
+dpc:DPC
+	Double pixel clock. 1=>true, 0=>false
+
+outputen:POLARITY
+	Output Enable Polarity. 0 => active low, 1 => active high
+
+pixclockpol:POLARITY
+	pixel clock polarity
+	0 => falling edge, 1 => rising edge
--- fbset-2.1.orig/debian/doc/kernel-doc/tgafb.txt
+++ fbset-2.1/debian/doc/kernel-doc/tgafb.txt
@@ -0,0 +1,69 @@
+$Id: tgafb.txt,v 1.1.2.2 2000/04/04 06:50:18 mato Exp $
+
+What is tgafb?
+===============
+
+This is a driver for DECChip 21030 based graphics framebuffers, a.k.a. TGA
+cards, which are usually found in older Digital Alpha systems. The
+following models are supported:
+
+ZLxP-E1 (8bpp, 2 MB VRAM)
+ZLxP-E2 (32bpp, 8 MB VRAM)
+ZLxP-E3 (32bpp, 16 MB VRAM, Zbuffer)
+
+This version is an almost complete rewrite of the code written by Geert
+Uytterhoeven, which was based on the original TGA console code written by
+Jay Estabrook.
+
+Major new features since Linux 2.0.x:
+
+ * Support for multiple resolutions
+ * Support for fixed-frequency and other oddball monitors 
+   (by allowing the video mode to be set at boot time)
+
+User-visible changes since Linux 2.2.x:
+
+ * Sync-on-green is now handled properly
+ * More useful information is printed on bootup
+   (this helps if people run into problems)
+
+This driver does not (yet) support the TGA2 family of framebuffers, so the
+PowerStorm 3D30/4D20 (also known as PBXGB) cards are not supported. These
+can however be used with the standard VGA Text Console driver.
+
+
+Configuration
+=============
+
+You can pass kernel command line options to tgafb with
+`video=tgafb:option1,option2:value2,option3' (multiple options should be
+separated by comma, values are separated from options by `:').
+Accepted options:
+
+font:X    - default font to use. All fonts are supported, including the
+            SUN12x22 font which is very nice at high resolutions.
+
+mode:X    - default video mode. The following video modes are supported:
+            640x480-60, 800x600-56, 640x480-72, 800x600-60, 800x600-72, 
+	    1024x768-60, 1152x864-60, 1024x768-70, 1024x768-76,
+	    1152x864-70, 1280x1024-61, 1024x768-85, 1280x1024-70,
+	    1152x864-84, 1280x1024-76, 1280x1024-85
+ 
+
+Known Issues
+============
+
+The XFree86 FBDev server has been reported not to work, since tgafb doesn't do
+mmap(). Running the standard XF86_TGA server from XFree86 3.3.x works fine for
+me, however this server does not do acceleration, which make certain operations
+quite slow. Support for acceleration is being progressively integrated in
+XFree86 4.x.
+
+When running tgafb in resolutions higher than 640x480, on switching VCs from
+tgafb to XF86_TGA 3.3.x, the entire screen is not re-drawn and must be manually
+refreshed. This is an X server problem, not a tgafb problem, and is fixed in
+XFree86 4.0.
+
+Enjoy!
+
+Martin Lucina <mato@kotelna.sk>
--- fbset-2.1.orig/debian/doc/kernel-doc/framebuffer.txt
+++ fbset-2.1/debian/doc/kernel-doc/framebuffer.txt
@@ -0,0 +1,345 @@
+			The Frame Buffer Device
+			-----------------------
+
+Maintained by Geert Uytterhoeven <geert@linux-m68k.org>
+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):
+
+      0 = /dev/fb0	First frame buffer
+      1 = /dev/fb1	Second frame buffer
+	  ...
+     31 = /dev/fb31	32nd frame buffer
+
+For backwards compatibility, you may want to create the following symbolic
+links:
+
+    /dev/fb0current -> fb0
+    /dev/fb1current -> fb1
+
+and so on...
+
+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
+
+  cp /dev/fb0 myfile
+
+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):
+
+    export FRAMEBUFFER=/dev/fb1
+
+or (for csh users):
+
+    setenv FRAMEBUFFER /dev/fb1
+
+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 <linux/fb.h> 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
+
+	Modes "default"
+
+    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:
+
+    1/(28.37516E6 Hz) = 35.242E-9 s
+
+If the screen resolution is 640x480, it will take
+
+    640*35.242E-9 s = 22.555E-6 s
+
+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
+
+    (640+272)*35.242E-9 s = 32.141E-6 s
+
+We'll say that the horizontal scanrate is about 31 kHz:
+
+    1/(32.141E-6 s) = 31.113E3 Hz
+
+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
+
+    (480+49)*32.141E-6 s = 17.002E-3 s
+
+The vertical scanrate is about 59 Hz:
+
+    1/(17.002E-3 s) = 58.815 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.
+
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ↑                            |          |       |
+  |          |                |upper_margin                |          |       |
+  |          |                ↓                            |          |       |
+  +----------###############################################----------+-------+
+  |          #                ↑                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |   left   #                |                            #  right   | hsync |
+  |  margin  #                |       xres                 #  margin  |  len  |
+  |<-------->#<---------------+--------------------------->#<-------->|<----->|
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |yres                        #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                |                            #          |       |
+  |          #                ↓                            #          |       |
+  +----------###############################################----------+-------+
+  |          |                ↑                            |          |       |
+  |          |                |lower_margin                |          |       |
+  |          |                ↓                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+  |          |                ↑                            |          |       |
+  |          |                |vsync_len                   |          |       |
+  |          |                ↓                            |          |       |
+  +----------+---------------------------------------------+----------+-------+
+
+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:
+ "800x600"     50      800  856  976 1040    600  637  643  666
+ < name >     DCF       HR  SH1  SH2  HFL     VR  SV1  SV2  VFL
+
+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
+
+1) Pixelclock:
+   xfree: in MHz
+   fb: in picoseconds (ps)
+
+   pixclock = 1000000 / DCF
+
+2) horizontal timings:
+   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
+
+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:
+
+    http://linux-fbdev.sourceforge.net/
+
+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)
+  - The mighty kernel sources:
+      o linux/drivers/video/
+      o linux/include/linux/fb.h
+      o linux/include/video/
+
+
+
+8. Mailing list
+---------------
+
+There are several frame buffer device related mailing lists at SourceForge:
+  - linux-fbdev-announce@lists.sourceforge.net, for announcements,
+  - linux-fbdev-user@lists.sourceforge.net, for generic user support,
+  - linux-fbdev-devel@lists.sourceforge.net, for project developers.
+
+Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
+subscription information and archive browsing.
+
+
+9. Downloading
+--------------
+
+All necessary files can be found at
+
+    ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
+
+and on its mirrors.
+
+The latest version of fbset can be found at
+
+    http://home.tvd.be/cr26864/Linux/fbdev/
+
+  
+10. Credits                                                       
+----------                                                       
+                
+This readme was written by Geert Uytterhoeven, partly based on the original
+`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
+provided by Frank Neumann.
+
+The frame buffer device abstraction was designed by Martin Schaller.
--- fbset-2.1.orig/debian/doc/kernel-doc/pvr2fb.txt
+++ fbset-2.1/debian/doc/kernel-doc/pvr2fb.txt
@@ -0,0 +1,61 @@
+$Id: pvr2fb.txt,v 1.1 2001/05/24 05:09:16 mrbrown Exp $
+
+What is pvr2fb?
+===============
+
+This is a driver for PowerVR 2 based graphics frame buffers, such as the
+one found in the Dreamcast.
+
+Advantages:
+
+ * It provides a nice large console (128 cols + 48 lines with 1024x768)
+   without using tiny, unreadable fonts.
+ * You can run XF86_FBDev on top of /dev/fb0
+ * Most important: boot logo :-)
+
+Disadvantages:
+
+ * Driver is currently limited to the Dreamcast PowerVR 2 implementation
+   at the time of this writing.
+
+Configuration
+=============
+
+You can pass kernel command line options to pvr2fb with
+`video=pvr2fb:option1,option2:value2,option3' (multiple options should be
+separated by comma, values are separated from options by `:').
+Accepted options:
+
+font:X    - default font to use. All fonts are supported, including the
+            SUN12x22 font which is very nice at high resolutions.
+
+mode:X    - default video mode. The following video modes are supported:
+            640x240-60, 640x480-60.
+	    
+            Note: the 640x240 mode is currently broken, and should not be
+            used for any reason. It is only mentioned as a reference.
+
+inverse   - invert colors on screen (for LCD displays)
+
+nomtrr    - disables write combining on frame buffer. This slows down driver
+            but there is reported minor incompatibility between GUS DMA and
+            XFree under high loads if write combining is enabled (sound
+            dropouts). MTRR is enabled by default on systems that have it
+            configured and that support it.
+
+cable:X   - cable type. This can be any of the following: vga, rgb, and
+            composite. If none is specified, we guess.
+
+output:X  - output type. This can be any of the following: pal, ntsc, and
+            vga. If none is specified, we guess.
+
+X11
+===
+
+XF86_FBDev should work, in theory. At the time of this writing it is
+totally untested and may or may not even portray the beginnings of
+working. If you end up testing this, please let me know!
+
+--
+Paul Mundt <lethal@linuxdc.org>
+
--- fbset-2.1.orig/debian/doc/kernel-doc/imacfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/imacfb.txt
@@ -0,0 +1,31 @@
+
+What is imacfb?
+===============
+
+This is a generic EFI platform driver for Intel based Apple computers.
+Imacfb is only for EFI booted Intel Macs.
+
+Supported Hardware
+==================
+
+iMac 17"/20"
+Macbook
+Macbook Pro 15"/17"
+MacMini
+
+How to use it?
+==============
+
+Imacfb does not have any kind of autodetection of your machine.
+You have to add the following kernel parameters in your elilo.conf:
+	Macbook :
+		video=imacfb:macbook
+	MacMini :
+		video=imacfb:mini
+	Macbook Pro 15", iMac 17" :
+		video=imacfb:i17
+	Macbook Pro 17", iMac 20" :
+		video=imacfb:i20
+
+--
+Edgar Hucek <gimli@dark-green.com>
--- fbset-2.1.orig/debian/doc/kernel-doc/arkfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/arkfb.txt
@@ -0,0 +1,68 @@
+
+	arkfb - fbdev driver for ARK Logic chips
+	========================================
+
+
+Supported Hardware
+==================
+
+	ARK 2000PV chip
+	ICS 5342 ramdac
+
+	- only BIOS initialized VGA devices supported
+	- probably not working on big endian
+
+
+Supported Features
+==================
+
+	*  4 bpp pseudocolor modes (with 18bit palette, two variants)
+	*  8 bpp pseudocolor mode (with 18bit palette)
+	* 16 bpp truecolor modes (RGB 555 and RGB 565)
+	* 24 bpp truecolor mode (RGB 888)
+	* 32 bpp truecolor mode (RGB 888)
+	* text mode (activated by bpp = 0)
+	* doublescan mode variant (not available in text mode)
+	* panning in both directions
+	* suspend/resume support
+
+Text mode is supported even in higher resolutions, but there is limitation to
+lower pixclocks (i got maximum about 70 MHz, it is dependent on specific
+hardware). This limitation is not enforced by driver. Text mode supports 8bit
+wide fonts only (hardware limitation) and 16bit tall fonts (driver
+limitation). Unfortunately character attributes (like color) in text mode are
+broken for unknown reason, so its usefulness is limited.
+
+There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
+packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
+with interleaved planes (1 byte interleave), MSB first. Both modes support
+8bit wide fonts only (driver limitation).
+
+Suspend/resume works on systems that initialize video card during resume and
+if device is active (for example used by fbcon).
+
+
+Missing Features
+================
+(alias TODO list)
+
+	* secondary (not initialized by BIOS) device support
+   	* big endian support
+	* DPMS support
+	* MMIO support
+	* interlaced mode variant
+	* support for fontwidths != 8 in 4 bpp modes
+	* support for fontheight != 16 in text mode
+	* hardware cursor
+	* vsync synchronization
+	* feature connector support
+	* acceleration support (8514-like 2D)
+
+
+Known bugs
+==========
+
+	* character attributes (and cursor) in text mode are broken
+
+--
+Ondrej Zajicek <santiago@crfreenet.org>
--- fbset-2.1.orig/debian/doc/kernel-doc/s3fb.txt
+++ fbset-2.1/debian/doc/kernel-doc/s3fb.txt
@@ -0,0 +1,82 @@
+
+	s3fb - fbdev driver for S3 Trio/Virge chips
+	===========================================
+
+
+Supported Hardware
+==================
+
+	S3 Trio32
+	S3 Trio64 (and variants V+, UV+, V2/DX, V2/GX)
+	S3 Virge  (and variants VX, DX, GX and GX2+)
+	S3 Plato/PX		(completely untested)
+	S3 Aurora64V+		(completely untested)
+
+	- only PCI bus supported
+	- only BIOS initialized VGA devices supported
+	- probably not working on big endian
+
+I tested s3fb on Trio64 (plain, V+ and V2/DX) and Virge (plain, VX, DX),
+all on i386.
+
+
+Supported Features
+==================
+
+	*  4 bpp pseudocolor modes (with 18bit palette, two variants)
+	*  8 bpp pseudocolor mode (with 18bit palette)
+	* 16 bpp truecolor modes (RGB 555 and RGB 565)
+	* 24 bpp truecolor mode (RGB 888) on (only on Virge VX)
+	* 32 bpp truecolor mode (RGB 888) on (not on Virge VX)
+	* text mode (activated by bpp = 0)
+	* interlaced mode variant (not available in text mode)
+	* doublescan mode variant (not available in text mode)
+	* panning in both directions
+	* suspend/resume support
+	* DPMS support
+
+Text mode is supported even in higher resolutions, but there is limitation to
+lower pixclocks (maximum usually between 50-60 MHz, depending on specific
+hardware, i get best results from plain S3 Trio32 card - about 75 MHz). This
+limitation is not enforced by driver. Text mode supports 8bit wide fonts only
+(hardware limitation) and 16bit tall fonts (driver limitation). Text mode
+support is broken on S3 Trio64 V2/DX.
+
+There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
+packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
+with interleaved planes (1 byte interleave), MSB first. Both modes support
+8bit wide fonts only (driver limitation).
+
+Suspend/resume works on systems that initialize video card during resume and
+if device is active (for example used by fbcon).
+
+
+Missing Features
+================
+(alias TODO list)
+
+	* secondary (not initialized by BIOS) device support
+   	* big endian support
+	* Zorro bus support
+	* MMIO support
+	* 24 bpp mode support on more cards
+	* support for fontwidths != 8 in 4 bpp modes
+	* support for fontheight != 16 in text mode
+	* composite and external sync (is anyone able to test this?)
+	* hardware cursor
+	* video overlay support
+	* vsync synchronization
+	* feature connector support
+	* acceleration support (8514-like 2D, Virge 3D, busmaster transfers)
+	* better values for some magic registers (performance issues)
+
+
+Known bugs
+==========
+
+	* cursor disable in text mode doesn't work
+	* text mode broken on S3 Trio64 V2/DX
+
+
+--
+Ondrej Zajicek <santiago@crfreenet.org>
--- fbset-2.1.orig/debian/doc/kernel-doc/sisfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/sisfb.txt
@@ -0,0 +1,158 @@
+
+What is sisfb?
+==============
+
+sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
+graphics chips. Supported are:
+
+- SiS 300 series: SiS 300/305, 540, 630(S), 730(S)
+- SiS 315 series: SiS 315/H/PRO, 55x, (M)65x, 740, (M)661(F/M)X, (M)741(GX)
+- SiS 330 series: SiS 330 ("Xabre"), (M)760
+
+
+Why do I need a framebuffer driver?
+===================================
+
+sisfb is eg. useful if you want a high-resolution text console. Besides that,
+sisfb is required to run DirectFB (which comes with an additional, dedicated
+driver for the 315 series).
+
+On the 300 series, sisfb on kernels older than 2.6.3 furthermore plays an
+important role in connection with DRM/DRI: Sisfb manages the memory heap
+used by DRM/DRI for 3D texture and other data. This memory management is
+required for using DRI/DRM.
+
+Kernels >= around 2.6.3 do not need sisfb any longer for DRI/DRM memory
+management. The SiS DRM driver has been updated and features a memory manager
+of its own (which will be used if sisfb is not compiled). So unless you want
+a graphical console, you don't need sisfb on kernels >=2.6.3.
+
+Sidenote: Since this seems to be a commonly made mistake: sisfb and vesafb
+cannot be active at the same time! Do only select one of them in your kernel
+configuration.
+
+
+How are parameters passed to sisfb?
+===================================
+
+Well, it depends: If compiled statically into the kernel, use lilo's append
+statement to add the parameters to the kernel command line. Please see lilo's
+(or GRUB's) documentation for more information. If sisfb is a kernel module,
+parameters are given with the modprobe (or insmod) command.
+
+Example for sisfb as part of the static kernel: Add the following line to your
+lilo.conf:
+
+     append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
+
+Example for sisfb as a module: Start sisfb by typing
+
+     modprobe sisfb mode=1024x768x16 rate=75 mem=12288
+
+A common mistake is that folks use a wrong parameter format when using the
+driver compiled into the kernel. Please note: If compiled into the kernel,
+the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16
+(or whatever mode you want to use, alternatively using any other format
+described above or the vesa keyword instead of mode). If compiled as a module,
+the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you
+want to use). Using a "=" for a ":" (and vice versa) is a huge difference!
+Additionally: If you give more than one argument to the in-kernel sisfb, the
+arguments are separated with ",". For example:
+
+   video=sisfb:mode:1024x768x16,rate:75,mem:12288
+
+
+How do I use it?
+================
+
+Preface statement: This file only covers very little of the driver's
+capabilities and features. Please refer to the author's and maintainer's
+website at http://www.winischhofer.net/linuxsisvga.shtml for more
+information. Additionally, "modinfo sisfb" gives an overview over all
+supported options including some explanation.
+
+The desired display mode can be specified using the keyword "mode" with
+a parameter in one of the following formats:
+  - XxYxDepth or
+  - XxY-Depth or
+  - XxY-Depth@Rate or
+  - XxY
+  - or simply use the VESA mode number in hexadecimal or decimal.
+
+For example: 1024x768x16, 1024x768-16@75, 1280x1024-16. If no depth is
+specified, it defaults to 8. If no rate is given, it defaults to 60Hz. Depth 32
+means 24bit color depth (but 32 bit framebuffer depth, which is not relevant
+to the user).
+
+Additionally, sisfb understands the keyword "vesa" followed by a VESA mode
+number in decimal or hexadecimal. For example: vesa=791 or vesa=0x117. Please
+use either "mode" or "vesa" but not both.
+
+Linux 2.4 only: If no mode is given, sisfb defaults to "no mode" (mode=none) if
+compiled as a module; if sisfb is statically compiled into the kernel, it
+defaults to 800x600x8 unless CRT2 type is LCD, in which case the LCD's native
+resolution is used. If you want to switch to a different mode, use the fbset
+shell command.
+
+Linux 2.6 only: If no mode is given, sisfb defaults to 800x600x8 unless CRT2
+type is LCD, in which case it defaults to the LCD's native resolution. If
+you want to switch to another mode, use the stty shell command.
+
+You should compile in both vgacon (to boot if you remove you SiS card from
+your system) and sisfb (for graphics mode). Under Linux 2.6, also "Framebuffer
+console support" (fbcon) is needed for a graphical console.
+
+You should *not* compile-in vesafb. And please do not use the "vga=" keyword
+in lilo's or grub's configuration file; mode selection is done using the
+"mode" or "vesa" keywords as a parameter. See above and below.
+
+
+X11
+===
+
+If using XFree86 or X.org, it is recommended that you don't use the "fbdev"
+driver but the dedicated "sis" X driver. The "sis" X driver and sisfb are
+developed by the same person (Thomas Winischhofer) and cooperate well with
+each other.
+
+
+SVGALib
+=======
+
+SVGALib, if directly accessing the hardware, never restores the screen
+correctly, especially on laptops or if the output devices are LCD or TV.
+Therefore, use the chipset "FBDEV" in SVGALib configuration. This will make
+SVGALib use the framebuffer device for mode switches and restoration.
+
+
+Configuration
+=============
+
+(Some) accepted options:
+
+off      - Disable sisfb. This option is only understood if sisfb is
+           in-kernel, not a module.
+mem:X    - size of memory for the console, rest will be used for DRI/DRM. X
+           is in kilobytes. On 300 series, the default is 4096, 8192 or
+	   16384 (each in kilobyte) depending on how much video ram the card
+           has. On 315/330 series, the default is the maximum available ram
+	   (since DRI/DRM is not supported for these chipsets).
+noaccel  - do not use 2D acceleration engine. (Default: use acceleration)
+noypan   - disable y-panning and scroll by redrawing the entire screen.
+           This is much slower than y-panning. (Default: use y-panning)
+vesa:X   - selects startup videomode. X is number from 0 to 0x1FF and
+           represents the VESA mode number (can be given in decimal or
+	   hexadecimal form, the latter prefixed with "0x").
+mode:X   - selects startup videomode. Please see above for the format of
+           "X".
+
+Boolean options such as "noaccel" or "noypan" are to be given without a
+parameter if sisfb is in-kernel (for example "video=sisfb:noypan). If
+sisfb is a module, these are to be set to 1 (for example "modprobe sisfb
+noypan=1").
+
+--
+Thomas Winischhofer <thomas@winischhofer.net>
+May 27, 2004
+
+
--- fbset-2.1.orig/debian/doc/kernel-doc/cirrusfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/cirrusfb.txt
@@ -0,0 +1,97 @@
+
+		Framebuffer driver for Cirrus Logic chipsets
+		Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
+
+
+
+{ just a little something to get people going; contributors welcome! }
+
+
+
+Chip families supported:
+	SD64
+	Piccolo
+	Picasso
+	Spectrum
+	Alpine (GD-543x/4x)
+	Picasso4 (GD-5446)
+	GD-5480
+	Laguna (GD-546x)
+
+Bus's supported:
+	PCI
+	Zorro
+
+Architectures supported:
+	i386
+	Alpha
+	PPC (Motorola Powerstack)
+	m68k (Amiga)
+
+
+
+Default video modes
+-------------------
+At the moment, there are two kernel command line arguments supported:
+
+mode:640x480
+mode:800x600
+	or
+mode:1024x768
+
+Full support for startup video modes (modedb) will be integrated soon.
+
+Version 1.9.9.1
+---------------
+* Fix memory detection for 512kB case
+* 800x600 mode
+* Fixed timings
+* Hint for AXP: Use -accel false -vyres -1 when changing resolution
+
+
+Version 1.9.4.4
+---------------
+* Preliminary Laguna support
+* Overhaul color register routines.
+* Associated with the above, console colors are now obtained from a LUT
+  called 'palette' instead of from the VGA registers.  This code was
+  modeled after that in atyfb and matroxfb.
+* Code cleanup, add comments.
+* Overhaul SR07 handling.
+* Bug fixes.
+
+
+Version 1.9.4.3
+---------------
+* Correctly set default startup video mode.
+* Do not override ram size setting.  Define
+  CLGEN_USE_HARDCODED_RAM_SETTINGS if you _do_ want to override the RAM
+  setting.
+* Compile fixes related to new 2.3.x IORESOURCE_IO[PORT] symbol changes.
+* Use new 2.3.x resource allocation.
+* Some code cleanup.
+
+
+Version 1.9.4.2
+---------------
+* Casting fixes.
+* Assertions no longer cause an oops on purpose.
+* Bug fixes.
+
+
+Version 1.9.4.1
+---------------
+* Add compatibility support.  Now requires a 2.1.x, 2.2.x or 2.3.x kernel.
+
+
+Version 1.9.4
+-------------
+* Several enhancements, smaller memory footprint, a few bugfixes.
+* Requires kernel 2.3.14-pre1 or later.
+
+
+Version 1.9.3
+-------------
+* Bundled with kernel 2.3.14-pre1 or later.
+
+
--- fbset-2.1.orig/debian/doc/kernel-doc/vt8623fb.txt
+++ fbset-2.1/debian/doc/kernel-doc/vt8623fb.txt
@@ -0,0 +1,64 @@
+
+	vt8623fb - fbdev driver for graphics core in VIA VT8623 chipset
+	===============================================================
+
+
+Supported Hardware
+==================
+
+	VIA VT8623 [CLE266] chipset and	its graphics core
+		(known as CastleRock or Unichrome)
+
+I tested vt8623fb on VIA EPIA ML-6000
+
+
+Supported Features
+==================
+
+	*  4 bpp pseudocolor modes (with 18bit palette, two variants)
+	*  8 bpp pseudocolor mode (with 18bit palette)
+	* 16 bpp truecolor mode (RGB 565)
+	* 32 bpp truecolor mode (RGB 888)
+	* text mode (activated by bpp = 0)
+	* doublescan mode variant (not available in text mode)
+	* panning in both directions
+	* suspend/resume support
+	* DPMS support
+
+Text mode is supported even in higher resolutions, but there is limitation to
+lower pixclocks (maximum about 100 MHz). This limitation is not enforced by
+driver. Text mode supports 8bit wide fonts only (hardware limitation) and
+16bit tall fonts (driver limitation).
+
+There are two 4 bpp modes. First mode (selected if nonstd == 0) is mode with
+packed pixels, high nibble first. Second mode (selected if nonstd == 1) is mode
+with interleaved planes (1 byte interleave), MSB first. Both modes support
+8bit wide fonts only (driver limitation).
+
+Suspend/resume works on systems that initialize video card during resume and
+if device is active (for example used by fbcon).
+
+
+Missing Features
+================
+(alias TODO list)
+
+	* secondary (not initialized by BIOS) device support
+	* MMIO support
+	* interlaced mode variant
+	* support for fontwidths != 8 in 4 bpp modes
+	* support for fontheight != 16 in text mode
+	* hardware cursor
+	* video overlay support
+	* vsync synchronization
+	* acceleration support (8514-like 2D, busmaster transfers)
+
+
+Known bugs
+==========
+
+	* cursor disable in text mode doesn't work
+
+
+--
+Ondrej Zajicek <santiago@crfreenet.org>
--- fbset-2.1.orig/debian/doc/kernel-doc/tridentfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/tridentfb.txt
@@ -0,0 +1,54 @@
+Tridentfb is a framebuffer driver for some Trident chip based cards.
+
+The following list of chips is thought to be supported although not all are
+tested:
+
+those from the Image series with Cyber in their names - accelerated
+those with Blade in their names (Blade3D,CyberBlade...) - accelerated
+the newer CyberBladeXP family  - nonaccelerated
+
+Only PCI/AGP based cards are supported, none of the older Tridents.
+
+How to use it?
+==============
+
+When booting you can pass the video parameter.
+video=tridentfb
+
+The parameters for tridentfb are concatenated with a ':' as in this example.
+
+video=tridentfb:800x600,bpp=16,noaccel
+
+The second level parameters that tridentfb understands are:
+
+noaccel - turns off acceleration (when it doesn't work for your card)
+accel - force text acceleration (for boards which by default are noacceled)
+
+fp	- use flat panel related stuff
+crt 	- assume monitor is present instead of fp
+
+center 	- for flat panels and resolutions smaller than native size center the
+	  image, otherwise use
+stretch
+
+memsize - integer value in Kb, use if your card's memory size is misdetected.
+	  look at the driver output to see what it says when initializing.
+memdiff - integer value in Kb,should be nonzero if your card reports
+	  more memory than it actually has.For instance mine is 192K less than
+	  detection says in all three BIOS selectable situations 2M, 4M, 8M.
+	  Only use if your video memory is taken from main memory hence of
+	  configurable size.Otherwise use memsize.
+	  If in some modes which barely fit the memory you see garbage at the bottom
+	  this might help by not letting change to that mode anymore.
+
+nativex - the width in pixels of the flat panel.If you know it (usually 1024
+	  800 or 1280) and it is not what the driver seems to detect use it.
+
+bpp  - bits per pixel (8,16 or 32)
+mode - a mode name like 800x600 (as described in Documentation/fb/modedb.txt)
+
+Using insane values for the above parameters will probably result in driver
+misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
+nativex=93)
+
+Contact: jani@astechnix.ro
--- fbset-2.1.orig/debian/doc/kernel-doc/intelfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/intelfb.txt
@@ -0,0 +1,146 @@
+Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver
+================================================================
+
+A. Introduction
+	This is a framebuffer driver for various Intel 8xx/9xx compatible
+graphics devices.  These would include:
+
+	Intel 830M
+	Intel 845G
+	Intel 852GM
+	Intel 855GM
+	Intel 865G
+	Intel 915G
+	Intel 915GM
+	Intel 945G
+	Intel 945GM
+
+B.  List of available options
+
+   a. "video=intelfb"
+	enables the intelfb driver
+
+	Recommendation: required
+
+   b. "mode=<xres>x<yres>[-<bpp>][@<refresh>]"
+	select mode
+
+	Recommendation: user preference
+	(default = 1024x768-32@70)
+
+   c. "vram=<value>"
+	select amount of system RAM in MB to allocate for the video memory
+	if not enough RAM was already allocated by the BIOS.
+
+	Recommendation: 1 - 4 MB.
+	(default = 4 MB)
+
+   d. "voffset=<value>"
+        select at what offset in MB of the logical memory to allocate the
+	framebuffer memory.  The intent is to avoid the memory blocks
+	used by standard graphics applications (XFree86). Depending on your
+        usage, adjust the value up or down, (0 for maximum usage, 63/127 MB
+        for the least amount).  Note, an arbitrary setting may conflict
+        with XFree86.
+
+	Recommendation: do not set
+	(default = 48 MB)
+
+   e. "accel"
+	enable text acceleration.  This can be enabled/reenabled anytime
+	by using 'fbset -accel true/false'.
+
+	Recommendation: enable
+	(default = set)
+
+   f. "hwcursor"
+	enable cursor acceleration.
+
+	Recommendation: enable
+	(default = set)
+
+   g. "mtrr"
+	enable MTRR.  This allows data transfers to the framebuffer memory
+	to occur in bursts which can significantly increase performance.
+	Not very helpful with the intel chips because of 'shared memory'.
+
+	Recommendation: set
+	(default = set)
+
+   h. "fixed"
+	disable mode switching.
+
+	Recommendation: do not set
+	(default = not set)
+
+   The binary parameters can be unset with a "no" prefix, example "noaccel".
+   The default parameter (not named) is the mode.
+
+C. Kernel booting
+
+Separate each option/option-pair by commas (,) and the option from its value
+with an equals sign (=) as in the following:
+
+video=intelfb:option1,option2=value2
+
+Sample Usage
+------------
+
+In /etc/lilo.conf, add the line:
+
+append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8"
+
+This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The
+framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor
+will be enabled.
+
+Remarks
+-------
+
+If setting this parameter doesn't work (you stay in a 80x25 text-mode),
+you might need to set the "vga=<mode>" parameter too - see vesafb.txt
+in this directory.
+
+
+D.  Module options
+
+	The module parameters are essentially similar to the kernel
+parameters. The main difference is that you need to include a Boolean value
+(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
+
+Example, to enable MTRR, include "mtrr=1".
+
+Sample Usage
+------------
+
+Using the same setup as described above, load the module like this:
+
+	modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
+
+Or just add the following to /etc/modprobe.conf
+
+	options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1
+
+and just do a
+
+	modprobe intelfb
+
+
+E.  Acknowledgment:
+
+	1.  Geert Uytterhoeven - his excellent howto and the virtual
+                                 framebuffer driver code made this possible.
+
+	2.  Jeff Hartmann for his agpgart code.
+
+	3.  David Dawes for his original kernel 2.4 code.
+
+	4.  The X developers.  Insights were provided just by reading the
+	    XFree86 source code.
+
+	5.  Antonino A. Daplas for his inspiring i810fb driver.
+
+	6.  Andrew Morton for his kernel patches maintenance.
+
+###########################
+Sylvain
--- fbset-2.1.orig/debian/doc/kernel-doc/matroxfb.txt
+++ fbset-2.1/debian/doc/kernel-doc/matroxfb.txt
@@ -0,0 +1,415 @@
+[This file is cloned from VesaFB. Thanks go to Gerd Knorr]
+
+What is matroxfb?
+=================
+
+This is a driver for a graphic framebuffer for Matrox devices on
+Alpha, Intel and PPC boxes.
+
+Advantages:
+
+ * It provides a nice large console (128 cols + 48 lines with 1024x768)
+   without using tiny, unreadable fonts.
+ * You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
+ * Most important: boot logo :-)
+
+Disadvantages:
+
+ * graphic mode is slower than text mode... but you should not notice
+   if you use same resolution as you used in textmode.
+
+
+How to use it?
+==============
+
+Switching modes is done using the video=matroxfb:vesa:... boot parameter
+or using `fbset' program.
+
+If you want, for example, enable a resolution of 1280x1024x24bpp you should
+pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
+
+You should compile in both vgacon (to boot if you remove you Matrox from
+box) and matroxfb (for graphics mode). You should not compile-in vesafb
+unless you have primary display on non-Matrox VBE2.0 device (see 
+Documentation/fb/vesafb.txt for details).
+
+Currently supported video modes are (through vesa:... interface, PowerMac
+has [as addon] compatibility code):
+
+
+[Graphic modes]
+
+bpp | 640x400  640x480  768x576  800x600  960x720
+----+--------------------------------------------
+  4 |            0x12             0x102            
+  8 |  0x100    0x101    0x180    0x103    0x188   
+ 15 |           0x110    0x181    0x113    0x189   
+ 16 |           0x111    0x182    0x114    0x18A   
+ 24 |           0x1B2    0x184    0x1B5    0x18C   
+ 32 |           0x112    0x183    0x115    0x18B   
+
+
+[Graphic modes (continued)]
+
+bpp | 1024x768 1152x864 1280x1024 1408x1056 1600x1200
+----+------------------------------------------------
+  4 |   0x104             0x106
+  8 |   0x105    0x190    0x107     0x198     0x11C
+ 15 |   0x116    0x191    0x119     0x199     0x11D
+ 16 |   0x117    0x192    0x11A     0x19A     0x11E
+ 24 |   0x1B8    0x194    0x1BB     0x19C     0x1BF
+ 32 |   0x118    0x193    0x11B     0x19B
+
+
+[Text modes]
+
+text | 640x400  640x480  1056x344  1056x400  1056x480
+-----+------------------------------------------------
+ 8x8 |  0x1C0    0x108     0x10A     0x10B     0x10C
+8x16 | 2, 3, 7                       0x109
+
+You can enter these number either hexadecimal (leading `0x') or decimal
+(0x100 = 256). You can also use value + 512 to achieve compatibility
+with your old number passed to vesafb.
+
+Non-listed number can be achieved by more complicated command-line, for
+example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32'.
+
+
+X11
+===
+
+XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
+architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
+works fine.
+
+Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
+XFree servers have big troubles in multihead configurations (even on first
+head, not even talking about second). Running XFree86 4.x accelerated mga 
+driver is possible, but you must not enable DRI - if you do, resolution and
+color depth of your X desktop must match resolution and color depths of your
+virtual consoles, otherwise X will corrupt accelerator settings.
+
+
+SVGALib
+=======
+
+Driver contains SVGALib compatibility code. It is turned on by choosing textual
+mode for console. You can do it at boot time by using videomode
+2,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0' does this work.
+Unfortunately, after SVGALib application exits, screen contents is corrupted.
+Switching to another console and back fixes it. I hope that it is SVGALib's
+problem and not mine, but I'm not sure.
+
+
+Configuration
+=============
+
+You can pass kernel command line options to matroxfb with
+`video=matroxfb:option1,option2:value2,option3' (multiple options should be 
+separated by comma, values are separated from options by `:'). 
+Accepted options:
+
+mem:X    - size of memory (X can be in megabytes, kilobytes or bytes)
+           You can only decrease value determined by driver because of
+	   it always probe for memory. Default is to use whole detected
+	   memory usable for on-screen display (i.e. max. 8 MB).
+disabled - do not load driver; you can use also `off', but `disabled'
+           is here too.
+enabled  - load driver, if you have `video=matroxfb:disabled' in LILO
+           configuration, you can override it by this (you cannot override
+	   `off'). It is default.
+noaccel  - do not use acceleration engine. It does not work on Alphas.
+accel    - use acceleration engine. It is default.
+nopan    - create initial consoles with vyres = yres, thus disabling virtual
+           scrolling.
+pan      - create initial consoles as tall as possible (vyres = memory/vxres).
+           It is default.
+nopciretry - disable PCI retries. It is needed for some broken chipsets,
+           it is autodetected for intel's 82437. In this case device does
+	   not comply to PCI 2.1 specs (it will not guarantee that every
+	   transaction terminate with success or retry in 32 PCLK).
+pciretry - enable PCI retries. It is default, except for intel's 82437.
+novga    - disables VGA I/O ports. It is default if BIOS did not enable device.
+           You should not use this option, some boards then do not restart
+	   without power off.
+vga      - preserve state of VGA I/O ports. It is default. Driver does not
+           enable VGA I/O if BIOS did not it (it is not safe to enable it in
+	   most cases).
+nobios   - disables BIOS ROM. It is default if BIOS did not enable BIOS itself.
+           You should not use this option, some boards then do not restart
+	   without power off.
+bios     - preserve state of BIOS ROM. It is default. Driver does not enable
+           BIOS if BIOS was not enabled before.
+noinit   - tells driver, that devices were already initialized. You should use
+           it if you have G100 and/or if driver cannot detect memory, you see
+	   strange pattern on screen and so on. Devices not enabled by BIOS
+	   are still initialized. It is default.
+init     - driver initializes every device it knows about.
+memtype  - specifies memory type, implies 'init'. This is valid only for G200 
+           and G400 and has following meaning:
+             G200: 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
+                   1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
+                   2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
+                   3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
+                   4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
+                   5 -> same as above
+                   6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
+                   7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
+             G400: 0 -> 2x512Kx16 SDRAM, 16/32MB
+                        2x512Kx32 SGRAM, 16/32MB
+                   1 -> 2x256Kx32 SGRAM, 8/16MB
+                   2 -> 4x128Kx32 SGRAM, 8/16MB
+                   3 -> 4x512Kx32 SDRAM, 32MB
+                   4 -> 4x256Kx32 SGRAM, 16/32MB
+                   5 -> 2x1Mx32 SDRAM, 32MB
+                   6 -> reserved
+                   7 -> reserved
+           You should use sdram or sgram parameter in addition to memtype 
+           parameter.
+nomtrr   - disables write combining on frame buffer. This slows down driver but
+           there is reported minor incompatibility between GUS DMA and XFree
+	   under high loads if write combining is enabled (sound dropouts).
+mtrr     - enables write combining on frame buffer. It speeds up video accesses
+           much. It is default. You must have MTRR support enabled in kernel
+	   and your CPU must have MTRR (f.e. Pentium II have them).
+sgram    - tells to driver that you have Gxx0 with SGRAM memory. It has no
+           effect without `init'.
+sdram    - tells to driver that you have Gxx0 with SDRAM memory.
+           It is a default.
+inv24    - change timings parameters for 24bpp modes on Millenium and
+           Millenium II. Specify this if you see strange color shadows around
+	   characters.
+noinv24  - use standard timings. It is the default.
+inverse  - invert colors on screen (for LCD displays)
+noinverse - show true colors on screen. It is default.
+dev:X    - bind driver to device X. Driver numbers device from 0 up to N,
+           where device 0 is first `known' device found, 1 second and so on.
+	   lspci lists devices in this order.
+	   Default is `every' known device for driver with multihead support
+	   and first working device (usually dev:0) for driver without
+	   multihead support.
+nohwcursor - disables hardware cursor (use software cursor instead).
+hwcursor - enables hardware cursor. It is default. If you are using
+           non-accelerated mode (`noaccel' or `fbset -accel false'), software
+	   cursor is used (except for text mode).
+noblink  - disables cursor blinking. Cursor in text mode always blinks (hw
+           limitation).
+blink    - enables cursor blinking. It is default.
+nofastfont - disables fastfont feature. It is default.
+fastfont:X - enables fastfont feature. X specifies size of memory reserved for
+             font data, it must be >= (fontwidth*fontheight*chars_in_font)/8.
+	     It is faster on Gx00 series, but slower on older cards.
+grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
+            4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
+	    displayed through putc/putcs. Direct accesses to framebuffer
+	    can paint colors.
+nograyscale - disable grayscale summing. It is default.
+cross4MB - enables that pixel line can cross 4MB boundary. It is default for
+           non-Millenium.
+nocross4MB - pixel line must not cross 4MB boundary. It is default for
+             Millenium I or II, because of these devices have hardware
+	     limitations which do not allow this. But this option is
+	     incompatible with some (if not all yet released) versions of
+	     XF86_FBDev.
+dfp      - enables digital flat panel interface. This option is incompatible with
+           secondary (TV) output - if DFP is active, TV output must be
+	   inactive and vice versa. DFP always uses same timing as primary
+	   (monitor) output.
+dfp:X    - use settings X for digital flat panel interface. X is number from
+           0 to 0xFF, and meaning of each individual bit is described in
+	   G400 manual, in description of DAC register 0x1F. For normal operation
+	   you should set all bits to zero, except lowest bit. This lowest bit
+	   selects who is source of display clocks, whether G400, or panel.
+	   Default value is now read back from hardware - so you should specify
+	   this value only if you are also using `init' parameter.
+outputs:XYZ - set mapping between CRTC and outputs. Each letter can have value
+           of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter corresponds
+	   to primary analog output, second letter to the secondary analog output
+	   and third letter to the DVI output. Default setting is 100 for
+	   cards below G400 or G400 without DFP, 101 for G400 with DFP, and
+	   111 for G450 and G550. You can set mapping only on first card,
+	   use matroxset for setting up other devices.
+vesa:X   - selects startup videomode. X is number from 0 to 0x1FF, see table
+           above for detailed explanation. Default is 640x480x8bpp if driver
+	   has 8bpp support. Otherwise first available of 640x350x4bpp,
+	   640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
+	   (80x25 text is always available).
+
+If you are not satisfied with videomode selected by `vesa' option, you
+can modify it with these options:
+
+xres:X   - horizontal resolution, in pixels. Default is derived from `vesa'
+           option.
+yres:X   - vertical resolution, in pixel lines. Default is derived from `vesa'
+           option.
+upper:X  - top boundary: lines between end of VSYNC pulse and start of first
+           pixel line of picture. Default is derived from `vesa' option.
+lower:X  - bottom boundary: lines between end of picture and start of VSYNC
+           pulse. Default is derived from `vesa' option.
+vslen:X  - length of VSYNC pulse, in lines. Default is derived from `vesa'
+           option.
+left:X   - left boundary: pixels between end of HSYNC pulse and first pixel.
+           Default is derived from `vesa' option.
+right:X  - right boundary: pixels between end of picture and start of HSYNC
+           pulse. Default is derived from `vesa' option.
+hslen:X  - length of HSYNC pulse, in pixels. Default is derived from `vesa'
+           option.
+pixclock:X - dotclocks, in ps (picoseconds). Default is derived from `vesa'
+             option and from `fh' and `fv' options.
+sync:X   - sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
+           If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
+	   generated. If bit 5 (value 0x20) is set, sync on green is turned on.
+	   Do not forget that if you want sync on green, you also probably
+	   want composite sync.
+	   Default depends on `vesa'.
+depth:X  - Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
+           `vesa'.
+
+If you know capabilities of your monitor, you can specify some (or all) of
+`maxclk', `fh' and `fv'. In this case, `pixclock' is computed so that
+pixclock <= maxclk, real_fh <= fh and real_fv <= fv.
+
+maxclk:X - maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
+           `don't care'.
+fh:X     - maximum horizontal synchronization frequency. X can be specified
+           in kHz or Hz. Default is `don't care'.
+fv:X     - maximum vertical frequency. X must be specified in Hz. Default is
+           70 for modes derived from `vesa' with yres <= 400, 60Hz for
+	   yres > 400.
+
+
+Limitations
+===========
+
+There are known and unknown bugs, features and misfeatures.
+Currently there are following known bugs:
+ + SVGALib does not restore screen on exit
+ + generic fbcon-cfbX procedures do not work on Alphas. Due to this,
+   `noaccel' (and cfb4 accel) driver does not work on Alpha. So everyone
+   with access to /dev/fb* on Alpha can hang machine (you should restrict
+   access to /dev/fb* - everyone with access to this device can destroy
+   your monitor, believe me...).
+ + 24bpp does not support correctly XF-FBDev on big-endian architectures.
+ + interlaced text mode is not supported; it looks like hardware limitation,
+   but I'm not sure.
+ + Gxx0 SGRAM/SDRAM is not autodetected.
+ + If you are using more than one framebuffer device, you must boot kernel
+   with 'video=scrollback:0'.
+ + maybe more...
+And following misfeatures:
+ + SVGALib does not restore screen on exit.
+ + pixclock for text modes is limited by hardware to
+    83 MHz on G200
+    66 MHz on Millennium I
+    60 MHz on Millennium II
+   Because I have no access to other devices, I do not know specific
+   frequencies for them. So driver does not check this and allows you to
+   set frequency higher that this. It causes sparks, black holes and other
+   pretty effects on screen. Device was not destroyed during tests. :-)
+ + my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
+   (and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
+   But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
+   them (maybe that chip overheats, but it has a very big cooler (G100 has
+   none), so it should work).
+ + special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
+   G16V16 are not supported
+ + color keying is not supported
+ + feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
+   by BIOS)
+ + DDC (monitor detection) is supported through dualhead driver
+ + some check for input values are not so strict how it should be (you can
+   specify vslen=4000 and so on).
+ + maybe more...
+And following features:
+ + 4bpp is available only on Millennium I and Millennium II. It is hardware
+   limitation.
+ + selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba 
+   option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
+   else selects 5:6:5 mode.
+ + text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
+   instead of one of 16M colors). It is due to hardware limitation of 
+   Millennium I/II and SVGALib compatibility.
+
+
+Benchmarks
+==========
+It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
+time for draw 6144000 characters on screen through /dev/vcsa
+(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in 
+16 seconds, i.e. 187 MBps).
+Times were obtained from one older version of driver, now they are about 3%
+faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
+PCI slot, G200 in AGP 2x slot. I did not test vgacon.
+
+NOACCEL
+        8x16                 12x22
+        Millennium I  G200   Millennium I  G200
+8bpp    16.42         9.54   12.33         9.13
+16bpp   21.00        15.70   19.11        15.02
+24bpp   36.66        36.66   35.00        35.00
+32bpp   35.00        30.00   33.85        28.66
+
+ACCEL, nofastfont
+        8x16                 12x22                6x11
+	Millennium I  G200   Millennium I  G200   Millennium I  G200
+8bpp     7.79         7.24   13.55         7.78   30.00        21.01
+16bpp    9.13         7.78   16.16         7.78   30.00        21.01
+24bpp   14.17        10.72   18.69        10.24   34.99        21.01
+32bpp   16.15	     16.16   18.73        13.09   34.99        21.01
+
+ACCEL, fastfont
+        8x16                 12x22                6x11
+	Millennium I  G200   Millennium I  G200   Millennium I  G200
+8bpp     8.41         6.01    6.54         4.37   16.00        10.51
+16bpp    9.54         9.12    8.76         6.17   17.52        14.01
+24bpp   15.00        12.36   11.67        10.00   22.01        18.32
+32bpp   16.18        18.29*  12.71        12.74   24.44        21.00
+
+TEXT
+        8x16
+	Millennium I  G200
+TEXT     3.29         1.50
+
+* Yes, it is slower than Millennium I.
+
+
+Dualhead G400
+=============
+Driver supports dualhead G400 with some limitations:
+ + secondary head shares videomemory with primary head. It is not problem
+   if you have 32MB of videoram, but if you have only 16MB, you may have
+   to think twice before choosing videomode (for example twice 1880x1440x32bpp
+   is not possible).
+ + due to hardware limitation, secondary head can use only 16 and 32bpp
+   videomodes.
+ + secondary head is not accelerated. There were bad problems with accelerated
+   XFree when secondary head used to use acceleration.
+ + secondary head always powerups in 640x480@60-32 videomode. You have to use
+   fbset to change this mode.
+ + secondary head always powerups in monitor mode. You have to use fbmatroxset
+   to change it to TV mode. Also, you must select at least 525 lines for
+   NTSC output and 625 lines for PAL output.
+ + kernel is not fully multihead ready. So some things are impossible to do.
+ + if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
+   and matroxfb_crtc2 into kernel.
+
+
+Dualhead G450
+=============
+Driver supports dualhead G450 with some limitations:
+ + secondary head shares videomemory with primary head. It is not problem
+   if you have 32MB of videoram, but if you have only 16MB, you may have
+   to think twice before choosing videomode.
+ + due to hardware limitation, secondary head can use only 16 and 32bpp
+   videomodes.
+ + secondary head is not accelerated.
+ + secondary head always powerups in 640x480@60-32 videomode. You have to use
+   fbset to change this mode.
+ + TV output is not supported
+ + kernel is not fully multihead ready, so some things are impossible to do.
+ + if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
+   into kernel.
+	
+--
+Petr Vandrovec <vandrove@vc.cvut.cz>
--- fbset-2.1.orig/debian/doc/kernel-doc/modedb.txt
+++ fbset-2.1/debian/doc/kernel-doc/modedb.txt
@@ -0,0 +1,132 @@
+
+
+			modedb default video mode support
+
+
+Currently all frame buffer device drivers have their own video mode databases,
+which is a mess and a waste of resources. The main idea of modedb is to have
+
+  - one routine to probe for video modes, which can be used by all frame buffer
+    devices
+  - one generic video mode database with a fair amount of standard videomodes
+    (taken from XFree86)
+  - the possibility to supply your own mode database for graphics hardware that
+    needs non-standard modes, like amifb and Mac frame buffer drivers (which
+    use macmodes.c)
+
+When a frame buffer device receives a video= option it doesn't know, it should
+consider that to be a video mode option. If no frame buffer device is specified
+in a video= option, fbmem considers that to be a global video mode option.
+
+Valid mode specifiers (mode_option argument):
+
+    <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m]
+    <name>[-<bpp>][@<refresh>]
+
+with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
+Things between square brackets are optional.
+
+If 'M' is specified in the mode_option argument (after <yres> and before
+<bpp> and <refresh>, if specified) the timings will be calculated using
+VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
+If 'R' is specified, do a 'reduced blanking' calculation for digital displays.
+If 'i' is specified, calculate for an interlaced mode.  And if 'm' is
+specified, add margins to the calculation (1.8% of xres rounded down to 8
+pixels and 1.8% of yres).
+
+       Sample usage: 1024x768M@60m - CVT timing with margins
+
+***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
+
+What is the VESA(TM) Coordinated Video Timings (CVT)?
+
+From the VESA(TM) Website:
+
+     "The purpose of CVT is to provide a method for generating a consistent
+      and coordinated set of standard formats, display refresh rates, and
+      timing specifications for computer display products, both those
+      employing CRTs, and those using other display technologies. The
+      intention of CVT is to give both source and display manufacturers a
+      common set of tools to enable new timings to be developed in a
+      consistent manner that ensures greater compatibility."
+
+This is the third standard approved by VESA(TM) concerning video timings.  The
+first was the Discrete Video Timings (DVT) which is  a collection of
+pre-defined modes approved by VESA(TM).  The second is the Generalized Timing
+Formula (GTF) which is an algorithm to calculate the timings, given the
+pixelclock, the horizontal sync frequency, or the vertical refresh rate.
+
+The GTF is limited by the fact that it is designed mainly for CRT displays.
+It artificially increases the pixelclock because of its high blanking
+requirement. This is inappropriate for digital display interface with its high
+data rate which requires that it conserves the pixelclock as much as possible.
+Also, GTF does not take into account the aspect ratio of the display.
+
+The CVT addresses these limitations.  If used with CRT's, the formula used
+is a derivation of GTF with a few modifications.  If used with digital
+displays, the "reduced blanking" calculation can be used.
+
+From the framebuffer subsystem perspective, new formats need not be added
+to the global mode database whenever a new mode is released by display
+manufacturers. Specifying for CVT will work for most, if not all, relatively
+new CRT displays and probably with most flatpanels, if 'reduced blanking'
+calculation is specified.  (The CVT compatibility of the display can be
+determined from its EDID. The version 1.3 of the EDID has extra 128-byte
+blocks where additional timing information is placed.  As of this time, there
+is no support yet in the layer to parse this additional blocks.)
+
+CVT also introduced a new naming convention (should be seen from dmesg output):
+
+    <pix>M<a>[-R]
+
+    where: pix = total amount of pixels in MB (xres x yres)
+           M   = always present
+           a   = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10)
+          -R   = reduced blanking
+
+	  example:  .48M3-R - 800x600 with reduced blanking
+
+Note: VESA(TM) has restrictions on what is a standard CVT timing:
+
+      - aspect ratio can only be one of the above values
+      - acceptable refresh rates are 50, 60, 70 or 85 Hz only
+      - if reduced blanking, the refresh rate must be at 60Hz
+
+If one of the above are not satisfied, the kernel will print a warning but the
+timings will still be calculated.
+
+***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
+
+To find a suitable video mode, you just call
+
+int __init fb_find_mode(struct fb_var_screeninfo *var,
+                        struct fb_info *info, const char *mode_option,
+                        const struct fb_videomode *db, unsigned int dbsize,
+                        const struct fb_videomode *default_mode,
+                        unsigned int default_bpp)
+
+with db/dbsize your non-standard video mode database, or NULL to use the
+standard video mode database.
+
+fb_find_mode() first tries the specified video mode (or any mode that matches,
+e.g. there can be multiple 640x480 modes, each of them is tried). If that
+fails, the default mode is tried. If that fails, it walks over all modes.
+
+To specify a video mode at bootup, use the following boot options:
+    video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
+
+where <driver> is a name from the table below.  Valid default modes can be
+found in linux/drivers/video/modedb.c.  Check your driver's documentation.
+There may be more modes.
+
+    Drivers that support modedb boot options
+    Boot Name	  Cards Supported
+
+    amifb	- Amiga chipset frame buffer
+    aty128fb	- ATI Rage128 / Pro frame buffer
+    atyfb	- ATI Mach64 frame buffer
+    tdfxfb	- 3D Fx frame buffer
+    tridentfb	- Trident (Cyber)blade chipset frame buffer
+
+BTW, only a few drivers use this at the moment. Others are to follow
+(feel free to send patches).
--- fbset-2.1.orig/debian/doc/kernel-doc/vesafb.txt
+++ fbset-2.1/debian/doc/kernel-doc/vesafb.txt
@@ -0,0 +1,181 @@
+
+What is vesafb?
+===============
+
+This is a generic driver for a graphic framebuffer on intel boxes.
+
+The idea is simple:  Turn on graphics mode at boot time with the help
+of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
+(and other) ports do.
+
+This means we decide at boot time whenever we want to run in text or
+graphics mode.  Switching mode later on (in protected mode) is
+impossible; BIOS calls work in real mode only.  VESA BIOS Extensions
+Version 2.0 are required, because we need a linear frame buffer.
+
+Advantages:
+
+ * It provides a nice large console (128 cols + 48 lines with 1024x768)
+   without using tiny, unreadable fonts.
+ * You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11
+   support for every VBE 2.0 compliant graphics board).
+ * Most important: boot logo :-)
+
+Disadvantages:
+
+ * graphic mode is slower than text mode...
+
+
+How to use it?
+==============
+
+Switching modes is done using the vga=... boot parameter.  Read
+Documentation/svga.txt for details.
+
+You should compile in both vgacon (for text mode) and vesafb (for
+graphics mode). Which of them takes over the console depends on
+whenever the specified mode is text or graphics.
+
+The graphic modes are NOT in the list which you get if you boot with
+vga=ask and hit return. The mode you wish to use is derived from the
+VESA mode number. Here are those VESA mode numbers:
+
+    | 640x480  800x600  1024x768 1280x1024
+----+-------------------------------------
+256 |  0x101    0x103    0x105    0x107   
+32k |  0x110    0x113    0x116    0x119   
+64k |  0x111    0x114    0x117    0x11A   
+16M |  0x112    0x115    0x118    0x11B   
+
+The video mode number of the Linux kernel is the VESA mode number plus
+0x200.
+ 
+ Linux_kernel_mode_number = VESA_mode_number + 0x200
+
+So the table for the Kernel mode numbers are:
+
+    | 640x480  800x600  1024x768 1280x1024
+----+-------------------------------------
+256 |  0x301    0x303    0x305    0x307   
+32k |  0x310    0x313    0x316    0x319   
+64k |  0x311    0x314    0x317    0x31A   
+16M |  0x312    0x315    0x318    0x31B   
+
+To enable one of those modes you have to specify "vga=ask" in the
+lilo.conf file and rerun LILO. Then you can type in the desired
+mode at the "vga=ask" prompt. For example if you like to use 
+1024x768x256 colors you have to say "305" at this prompt.
+
+If this does not work, this might be because your BIOS does not support
+linear framebuffers or because it does not support this mode at all.
+Even if your board does, it might be the BIOS which does not.  VESA BIOS
+Extensions v2.0 are required, 1.2 is NOT sufficient.  You will get a
+"bad mode number" message if something goes wrong.
+
+1. Note: LILO cannot handle hex, for booting directly with 
+         "vga=mode-number" you have to transform the numbers to decimal.
+2. Note: Some newer versions of LILO appear to work with those hex values,
+         if you set the 0x in front of the numbers.
+
+X11
+===
+
+XF68_FBDev should work just fine, but it is non-accelerated.  Running
+another (accelerated) X-Server like XF86_SVGA might or might not work.
+It depends on X-Server and graphics board.
+
+The X-Server must restore the video mode correctly, else you end up
+with a broken console (and vesafb cannot do anything about this).
+
+
+Refresh rates
+=============
+
+There is no way to change the vesafb video mode and/or timings after
+booting linux.  If you are not happy with the 60 Hz refresh rate, you
+have these options:
+
+ * configure and load the DOS-Tools for your the graphics board (if
+   available) and boot linux with loadlin.
+ * use a native driver (matroxfb/atyfb) instead if vesafb.  If none
+   is available, write a new one!
+ * VBE 3.0 might work too.  I have neither a gfx board with VBE 3.0
+   support nor the specs, so I have not checked this yet.
+
+
+Configuration
+=============
+
+The VESA BIOS provides protected mode interface for changing
+some parameters.  vesafb can use it for palette changes and
+to pan the display.  It is turned off by default because it
+seems not to work with some BIOS versions, but there are options
+to turn it on.
+
+You can pass options to vesafb using "video=vesafb:option" on
+the kernel command line.  Multiple options should be separated
+by comma, like this: "video=vesafb:ypan,invers"
+
+Accepted options:
+
+invers	no comment...
+
+ypan	enable display panning using the VESA protected mode 
+	interface.  The visible screen is just a window of the
+	video memory, console scrolling is done by changing the
+	start of the window.
+	pro:	* scrolling (fullscreen) is fast, because there is
+		  no need to copy around data.
+		* You'll get scrollback (the Shift-PgUp thing),
+		  the video memory can be used as scrollback buffer
+	kontra: * scrolling only parts of the screen causes some
+		  ugly flicker effects (boot logo flickers for
+		  example).
+
+ywrap	Same as ypan, but assumes your gfx board can wrap-around 
+	the video memory (i.e. starts reading from top if it
+	reaches the end of video memory).  Faster than ypan.
+
+redraw	scroll by redrawing the affected part of the screen, this
+	is the safe (and slow) default.
+
+
+vgapal	Use the standard vga registers for palette changes.
+	This is the default.
+pmipal	Use the protected mode interface for palette changes.
+
+mtrr:n	setup memory type range registers for the vesafb framebuffer
+	where n:
+	      0 - disabled (equivalent to nomtrr) (default)
+	      1 - uncachable
+	      2 - write-back
+	      3 - write-combining
+	      4 - write-through
+
+	If you see the following in dmesg, choose the type that matches the
+	old one. In this example, use "mtrr:2".
+...
+mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
+...
+
+nomtrr  disable mtrr
+
+vremap:n
+        remap 'n' MiB of video RAM. If 0 or not specified, remap memory
+	according to video mode. (2.5.66 patch/idea by Antonino Daplas
+	reversed to give override possibility (allocate more fb memory
+	than the kernel would) to 2.4 by tmb@iki.fi)
+
+vtotal:n
+        if the video BIOS of your card incorrectly determines the total
+        amount of video RAM, use this option to override the BIOS (in MiB).
+
+Have fun!
+
+  Gerd
+
+--
+Gerd Knorr <kraxel@goldbach.in-berlin.de>
+
+Minor (mostly typo) changes 
+by Nico Schmoigl <schmoigl@rumms.uni-mannheim.de>
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/documentation
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/documentation
@@ -0,0 +1,17 @@
+Available Documentation
+=======================
+
+Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22,
+2001, available from VIA:
+
+	http://www.viavpsd.com/product/6/15/DS8601A182.pdf
+
+The datasheet is incomplete, some registers that need to be programmed are not
+explained at all and important bits are listed as "reserved". But you really
+need the datasheet to understand the code.  "p. xxx" comments refer to page
+numbers of this document.
+
+XFree/XOrg drivers are available and of good quality, looking at the code
+there is a good idea if the datasheet does not provide enough information
+or if the datasheet seems to be wrong.
+
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/performance
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/performance
@@ -0,0 +1,79 @@
+Speed
+=====
+
+CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data
+for mode 1280x1024-[8,16,32]@61 Hz.
+
+Test 1: Cat a file with 2000 lines of 0 characters.
+Test 2: Cat a file with 2000 lines of 80 characters.
+Test 3: Cat a file with 2000 lines of 160 characters.
+
+All values show system time use in seconds, kernel 2.6.12 was used for
+the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a
+patch that speeds up kernel bitblitting a lot ( > 20%).
+
++-----------+-----------------------------------------------------+
+|	    |			not accelerated 		  |
+| TRIDENTFB +-----------------+-----------------+-----------------+
+| of 2.6.12 |	   8 bpp      |     16 bpp	|     32 bpp	  |
+|	    | noypan |	 ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |	4.31 |	 4.33 |   6.05 |  12.81 |  ----  |  ----  |
+|    Test 2 |  67.94 |	 5.44 | 123.16 |  14.79 |  ----  |  ----  |
+|    Test 3 | 131.36 |	 6.55 | 240.12 |  16.76 |  ----  |  ----  |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments |		      | 		| completely bro- |
+|	    |		      | 		| ken, monitor	  |
+|	    |		      | 		| switches off	  |
++-----------+-----------------+-----------------+-----------------+
+
+
++-----------+-----------------------------------------------------+
+|	    |			  accelerated			  |
+| TRIDENTFB +-----------------+-----------------+-----------------+
+| of 2.6.12 |	   8 bpp      |     16 bpp	|     32 bpp	  |
+|	    | noypan |	 ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |  ----  |	----  |  20.62 |   1.22 |  ----  |  ----  |
+|    Test 2 |  ----  |	----  |  22.61 |   3.19 |  ----  |  ----  |
+|    Test 3 |  ----  |	----  |  24.59 |   5.16 |  ----  |  ----  |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments | broken, writing | broken, ok only | completely bro- |
+|	    | to wrong places | if bgcolor is	| ken, monitor	  |
+|	    | on screen + bug | black, bug in	| switches off	  |
+|	    | in fillrect()   | fillrect()	|		  |
++-----------+-----------------+-----------------+-----------------+
+
+
++-----------+-----------------------------------------------------+
+|	    |			not accelerated 		  |
+|   VESAFB  +-----------------+-----------------+-----------------+
+| of 2.6.12 |	   8 bpp      |     16 bpp	|     32 bpp	  |
+|	    | noypan |	 ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |	4.26 |	 3.76 |   5.99 |   7.23 |  ----  |  ----  |
+|    Test 2 |  65.65 |	 4.89 | 120.88 |   9.08 |  ----  |  ----  |
+|    Test 3 | 126.91 |	 5.94 | 235.77 |  11.03 |  ----  |  ----  |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments | vga=0x307       | vga=0x31a	| vga=0x31b not   |
+|	    | fh=80kHz	      | fh=80kHz	| supported by	  |
+|	    | fv=75kHz	      | fv=75kHz	| video BIOS and  |
+|	    |		      | 		| hardware	  |
++-----------+-----------------+-----------------+-----------------+
+
+
++-----------+-----------------------------------------------------+
+|	    |			  accelerated			  |
+|  CYBLAFB  +-----------------+-----------------+-----------------+
+|	    |	   8 bpp      |     16 bpp	|     32 bpp	  |
+|	    | noypan |	 ypan | noypan |   ypan | noypan |   ypan |
++-----------+--------+--------+--------+--------+--------+--------+
+|    Test 1 |	8.02 |	 0.23 |  19.04 |   0.61 |  57.12 |   2.74 |
+|    Test 2 |	8.38 |	 0.55 |  19.39 |   0.92 |  57.54 |   3.13 |
+|    Test 3 |	8.73 |	 0.86 |  19.74 |   1.24 |  57.95 |   3.51 |
++-----------+--------+--------+--------+--------+--------+--------+
+|  Comments |		      | 		|		  |
+|	    |		      | 		|		  |
+|	    |		      | 		|		  |
+|	    |		      | 		|		  |
++-----------+-----------------+-----------------+-----------------+
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/whycyblafb
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/whycyblafb
@@ -0,0 +1,85 @@
+I tried the following framebuffer drivers:
+
+	- TRIDENTFB is full of bugs. Acceleration is broken for Blade3D
+	  graphics cores like the cyberblade/i1. It claims to support a great
+	  number of devices, but documentation for most of these devices is
+	  unfortunately not available. There is _no_ reason to use tridentfb
+	  for cyberblade/i1 + CRT users. VESAFB is faster, and the one
+	  advantage, mode switching, is broken in tridentfb.
+
+	- VESAFB is used by many distributions as a standard. Vesafb does
+	  not support mode switching. VESAFB is a bit faster than the working
+	  configurations of TRIDENTFB, but it is still too slow, even if you
+	  use ypan.
+
+	- EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1
+	  graphics core, but it still has serious bugs and developement seems
+	  to have stopped. This is the one driver with TV-out support. If you
+	  do need this feature, try epiafb.
+
+None of these drivers was a real option for me.
+
+I believe that is unreasonable to change code that announces to support 20
+devices if I only have more or less sufficient documentation for exactly one
+of these. The risk of breaking device foo while fixing device bar is too high.
+
+So I decided to start CyBlaFB as a stripped down tridentfb.
+
+All code specific to other Trident chips has been removed. After that there
+were a lot of cosmetic changes to increase the readability of the code. All
+register names were changed to those mnemonics used in the datasheet. Function
+and macro names were changed if they hindered easy understanding of the code.
+
+After that I debugged the code and implemented some new features. I'll try to
+give a little summary of the main changes:
+
+	- calculation of vertical and horizontal timings was fixed
+
+	- video signal quality has been improved dramatically
+
+	- acceleration:
+
+		- fillrect and copyarea were fixed and reenabled
+
+		- color expanding imageblit was newly implemented, color
+		  imageblit (only used to draw the penguine) still uses the
+		  generic code.
+
+		- init of the acceleration engine was improved and moved to a
+		  place where it really works ...
+
+		- sync function has a timeout now and tries to reset and
+		  reinit the accel engine if necessary
+
+		- fewer slow copyarea calls when doing ypan scrolling by using
+		  undocumented bit d21 of screen start address stored in
+		  CR2B[5]. BIOS does use it also, so this should be safe.
+
+	- cyblafb rejects any attempt to set modes that would cause vclk
+	  values above reasonable 230 MHz. 32bit modes use a clock
+	  multiplicator of 2, so fbset does show the correct values for
+	  pixclock but not for vclk in this case. The fbset limit is 115 MHz
+	  for 32 bpp modes.
+
+	- cyblafb rejects modes known to be broken or unimplemented (all
+	  interlaced modes, all doublescan modes for now)
+
+	- cyblafb now works independant of the video mode in effect at startup
+	  time (tridentfb does not init all needed registers to reasonable
+	  values)
+
+	- switching between video modes does work reliably now
+
+	- the first video mode now is the one selected on startup using the
+	  vga=???? mechanism or any of
+		- 640x480, 800x600, 1024x768, 1280x1024
+		- 8, 16, 24 or 32 bpp
+		- refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32
+		  is limited to 63Hz)
+
+	- pci retry and pci burst mode are settable (try to disable if you
+	  experience latency problems)
+
+	- built as a module cyblafb might be unloaded and reloaded using
+	  the vfb module and con2vt or might be used together with vesafb
+
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/bugs
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/bugs
@@ -0,0 +1,13 @@
+Bugs
+====
+
+I currently don't know of any bug. Please do send reports to:
+ - linux-fbdev-devel@lists.sourceforge.net
+ - Knut_Petersen@t-online.de.
+
+
+Untested features
+=================
+
+All LCD stuff is untested. If it worked in tridentfb, it should work in
+cyblafb. Please test and report the results to Knut_Petersen@t-online.de.
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/todo
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/todo
@@ -0,0 +1,31 @@
+TODO / Missing features
+=======================
+
+Verify LCD stuff		"stretch" and "center" options are
+				completely untested ... this code needs to be
+				verified. As I don't have access to such
+				hardware, please contact me if you are
+				willing run some tests.
+
+Interlaced video modes		The reason that interleaved
+				modes are disabled is that I do not know
+				the meaning of the vertical interlace
+				parameter. Also the datasheet mentions a
+				bit d8 of a horizontal interlace parameter,
+				but nowhere the lower 8 bits. Please help
+				if you can.
+
+low-res double scan modes	Who needs it?
+
+accelerated color blitting	Who needs it? The console driver does use color
+				blitting for nothing but drawing the penguine,
+				everything else is done using color expanding
+				blitting of 1bpp character bitmaps.
+
+ioctls				Who needs it?
+
+TV-out				Will be done later. Use "vga= " at boot time
+				to set a suitable video mode.
+
+???				Feel free to contact me if you have any
+				feature requests
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/usage
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/usage
@@ -0,0 +1,217 @@
+CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated
+into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
+tested using a VIA EPIA 5000 board.
+
+Cyblafb - compiled into the kernel or as a module?
+==================================================
+
+You might compile cyblafb either as a module or compile it permanently into the
+kernel.
+
+Unless you have a real reason to do so you should not compile both vesafb and
+cyblafb permanently into the kernel. It's possible and it helps during the
+developement cycle, but it's useless and will at least block some otherwise
+usefull memory for ordinary users.
+
+Selecting Modes
+===============
+
+	Startup Mode
+	============
+
+	First of all, you might use the "vga=???" boot parameter as it is
+	documented in vesafb.txt and svga.txt. Cyblafb will detect the video
+	mode selected and will use the geometry and timings found by
+	inspecting the hardware registers.
+
+		video=cyblafb vga=0x317
+
+	Alternatively you might use a combination of the mode, ref and bpp
+	parameters. If you compiled the driver into the kernel, add something
+	like this to the kernel command line:
+
+		video=cyblafb:1280x1024,bpp=16,ref=50 ...
+
+	If you compiled the driver as a module, the same mode would be
+	selected by the following command:
+
+		modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ...
+
+	None of the modes possible to select as startup modes are affected by
+	the problems described at the end of the next subsection.
+
+	For all startup modes cyblafb chooses a virtual x resolution of 2048,
+	the only exception is mode 1280x1024 in combination with 32 bpp. This
+	allows ywrap scrolling for all those modes if rotation is 0 or 2, and
+	also fast scrolling if rotation is 1 or 3. The default virtual y reso-
+	lution is 4096 for bpp == 8, 2048 for bpp==16 and 1024 for bpp == 32,
+	again with the only exception of 1280x1024 at 32 bpp.
+
+	Please do set your video memory size to 8 Mb in the Bios setup. Other
+	values will work, but performace is decreased for a lot of modes.
+
+	Mode changes using fbset
+	========================
+
+	You might use fbset to change the video mode, see "man fbset". Cyblafb
+	generally does assume that you know what you are doing. But it does
+	some checks, especially those that are needed to prevent you from
+	damaging your hardware.
+
+		- only 8, 16, 24 and 32 bpp video modes are accepted
+		- interlaced video modes are not accepted
+		- double scan video modes are not accepted
+		- if a flat panel is found, cyblafb does not allow you
+		  to program a resolution higher than the physical
+		  resolution of the flat panel monitor
+		- cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp
+		  and (currently) 24 bit modes use a doubled vclk internally,
+		  the dotclock limit as seen by fbset is 115 MHz for those
+		  modes and 230 MHz for 8 and 16 bpp modes.
+		- cyblafb will allow you to select very high resolutions as
+		  long as the hardware can be programmed to these modes. The
+		  documented limit 1600x1200 is not enforced, but don't expect
+		  perfect signal quality.
+
+	Any request that violates the rules given above will be either changed
+	to something the hardware supports or an error value will be returned.
+
+	If you program a virtual y resolution higher than the hardware limit,
+	cyblafb will silently decrease that value to the highest possible
+	value. The same is true for a virtual x resolution that is not
+	supported by the hardware. Cyblafb tries to adapt vyres first because
+	vxres decides if ywrap scrolling is possible or not.
+
+	Attempts to disable acceleration are ignored, I believe that this is
+	safe.
+
+	Some video modes that should work do not work as expected. If you use
+	the standard fb.modes, fbset 640x480-60 will program that mode, but
+	you will see a vertical area, about two characters wide, with only
+	much darker characters than the other characters on the screen.
+	Cyblafb does allow that mode to be set, as it does not violate the
+	official specifications. It would need a lot of code to reliably sort
+	out all invalid modes, playing around with the margin values will
+	give a valid mode quickly. And if cyblafb would detect such an invalid
+	mode, should it silently alter the requested values or should it
+	report an error? Both options have some pros and cons. As stated
+	above, none of the startup modes are affected, and if you set
+	verbosity to 1 or higher, cyblafb will print the fbset command that
+	would be needed to program that mode using fbset.
+
+
+Other Parameters
+================
+
+
+crt		don't autodetect, assume monitor connected to
+		standard VGA connector
+
+fp		don't autodetect, assume flat panel display
+		connected to flat panel monitor interface
+
+nativex 	inform driver about native x resolution of
+		flat panel monitor connected to special
+		interface (should be autodetected)
+
+stretch 	stretch image to adapt low resolution modes to
+		higer resolutions of flat panel monitors
+		connected to special interface
+
+center		center image to adapt low resolution modes to
+		higer resolutions of flat panel monitors
+		connected to special interface
+
+memsize 	use if autodetected memsize is wrong ...
+		should never be necessary
+
+nopcirr 	disable PCI read retry
+nopciwr 	disable PCI write retry
+nopcirb 	disable PCI read bursts
+nopciwb 	disable PCI write bursts
+
+bpp		bpp for specified modes
+		valid values: 8 || 16 || 24 || 32
+
+ref		refresh rate for specified mode
+		valid values: 50 <= ref <= 85
+
+mode		640x480 or 800x600 or 1024x768 or 1280x1024
+		if not specified, the startup mode will be detected
+		and used, so you might also use the vga=??? parameter
+		described in vesafb.txt. If you do not specify a mode,
+		bpp and ref parameters are ignored.
+
+verbosity	0 is the default, increase to at least 2 for every
+		bug report!
+
+Development hints
+=================
+
+It's much faster do compile a module and to load the new version after
+unloading the old module than to compile a new kernel and to reboot. So if you
+try to work on cyblafb, it might be a good idea to use cyblafb as a module.
+In real life, fast often means dangerous, and that's also the case here. If
+you introduce a serious bug when cyblafb is compiled into the kernel, the
+kernel will lock or oops with a high probability before the file system is
+mounted, and the danger for your data is low. If you load a broken own version
+of cyblafb on a running system, the danger for the integrity of the file
+system is much higher as you might need a hard reset afterwards. Decide
+yourself.
+
+Module unloading, the vfb method
+================================
+
+If you want to unload/reload cyblafb using the virtual framebuffer, you need
+to enable vfb support in the kernel first. After that, load the modules as
+shown below:
+
+	modprobe vfb vfb_enable=1
+	modprobe fbcon
+	modprobe cyblafb
+	fbset -fb /dev/fb1 1280x1024-60 -vyres 2662
+	con2fb /dev/fb1 /dev/tty1
+	...
+
+If you now made some changes to cyblafb and want to reload it, you might do it
+as show below:
+
+	con2fb /dev/fb0 /dev/tty1
+	...
+	rmmod cyblafb
+	modprobe cyblafb
+	con2fb /dev/fb1 /dev/tty1
+	...
+
+Of course, you might choose another mode, and most certainly you also want to
+map some other /dev/tty* to the real framebuffer device. You might also choose
+to compile fbcon as a kernel module or place it permanently in the kernel.
+
+I do not know of any way to unload fbcon, and fbcon will prevent the
+framebuffer device loaded first from unloading. [If there is a way, then
+please add a description here!]
+
+Module unloading, the vesafb method
+===================================
+
+Configure the kernel:
+
+	<*> Support for frame buffer devices
+	[*]   VESA VGA graphics support
+	<M>   Cyberblade/i1 support
+
+Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan
+parameter is important, choose any vga parameter you like as long as it is
+a graphics mode.
+
+After booting, load cyblafb without any mode and bpp parameter and assign
+cyblafb to individual ttys using con2fb, e.g.:
+
+	modprobe cyblafb
+	con2fb /dev/fb1 /dev/tty1
+
+Unloading cyblafb works without problems after you assign vesafb to all
+ttys again, e.g.:
+
+	con2fb /dev/fb0 /dev/tty1
+	rmmod cyblafb
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/whatsnew
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/whatsnew
@@ -0,0 +1,29 @@
+0.62
+====
+
+      - the vesafb parameter has been removed as I decided to allow the
+      	feature without any special parameter.
+
+      - Cyblafb does not use the vga style of panning any longer, now the
+      	"right view" register in the graphics engine IO space is used. Without
+	that change it was impossible to use all available memory, and without
+	access to all available memory it is impossible to ywrap.
+
+      - The imageblit function now uses hardware acceleration for all font
+        widths. Hardware blitting across pixel column 2048 is broken in the
+	cyberblade/i1 graphics core, but we work around that hardware bug.
+
+      - modes with vxres != xres are supported now.
+
+      - ywrap scrolling is supported now and the default. This is a big
+        performance gain.
+
+      - default video modes use vyres > yres and vxres > xres to allow
+        almost optimal scrolling speed for normal and rotated screens
+
+      - some features mainly usefull for debugging the upper layers of the
+        framebuffer system have been added, have a look at the code
+
+      - fixed: Oops after unloading cyblafb when reading /proc/io*
+
+      - we work around some bugs of the higher framebuffer layers.
--- fbset-2.1.orig/debian/doc/kernel-doc/cyblafb/credits
+++ fbset-2.1/debian/doc/kernel-doc/cyblafb/credits
@@ -0,0 +1,7 @@
+Thanks to
+=========
+   * 	Alan Hourihane, for writing the X trident driver
+   *	Jani Monoses, for writing the tridentfb driver
+   *	Antonino A. Daplas, for review of the first published
+	version of cyblafb and some code
+   *	Jochen Hein, for testing and a helpfull bug report
--- fbset-2.1.orig/debian/doc/kernel-doc/internals.txt
+++ fbset-2.1/debian/doc/kernel-doc/internals.txt
@@ -0,0 +1,82 @@
+
+This is a first start for some documentation about frame buffer device
+internals.
+
+Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
+James Simmons <jsimmons@user.sf.net>, Nov 26 2002
+
+--------------------------------------------------------------------------------
+
+	    ***  STRUCTURES USED BY THE FRAME BUFFER DEVICE API  ***
+
+The following structures play a role in the game of frame buffer devices. They
+are defined in <linux/fb.h>.
+
+1. Outside the kernel (user space)
+
+  - struct fb_fix_screeninfo
+
+    Device independent unchangeable information about a frame buffer device and
+    a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO
+    ioctl.
+
+  - struct fb_var_screeninfo
+
+    Device independent changeable information about a frame buffer device and a
+    specific video mode. This can be obtained using the FBIOGET_VSCREENINFO
+    ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan
+    the screen only, you can use the FBIOPAN_DISPLAY ioctl.
+
+  - struct fb_cmap
+
+    Device independent colormap information. You can get and set the colormap
+    using the FBIOGETCMAP and FBIOPUTCMAP ioctls.
+
+
+2. Inside the kernel
+
+  - struct fb_info
+
+    Generic information, API and low level information about a specific frame
+    buffer device instance (slot number, board address, ...).
+
+  - struct `par'
+
+    Device dependent information that uniquely defines the video mode for this
+    particular piece of hardware.
+
+
+--------------------------------------------------------------------------------
+
+	    ***  VISUALS USED BY THE FRAME BUFFER DEVICE API  ***
+
+
+Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)
+-------------------------------------------------
+Each pixel is either black or white.
+
+
+Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR)
+---------------------------------------------------------------------
+The whole pixel value is fed through a programmable lookup table that has one
+color (including red, green, and blue intensities) for each possible pixel
+value, and that color is displayed.
+
+
+True color (FB_VISUAL_TRUECOLOR)
+--------------------------------
+The pixel value is broken up into red, green, and blue fields.
+
+
+Direct color (FB_VISUAL_DIRECTCOLOR)
+------------------------------------
+The pixel value is broken up into red, green, and blue fields, each of which 
+are looked up in separate red, green, and blue lookup tables.
+
+
+Grayscale displays
+------------------
+Grayscale and static grayscale are special variants of pseudo color and static
+pseudo color, where the red, green and blue components are always equal to
+each other.
+
--- fbset-2.1.orig/debian/compat
+++ fbset-2.1/debian/compat
@@ -0,0 +1 @@
+5
--- fbset-2.1.orig/debian/fbset-udeb.dirs
+++ fbset-2.1/debian/fbset-udeb.dirs
@@ -0,0 +1,2 @@
+etc
+bin
--- fbset-2.1.orig/debian/patches/08_rgba_keyword.patch
+++ fbset-2.1/debian/patches/08_rgba_keyword.patch
@@ -0,0 +1,48 @@
+Status: sent-upstream
+
+Index: b/modes.l
+===================================================================
+--- a/modes.l	2007-09-16 19:05:33.000000000 +0300
++++ b/modes.l	2007-09-16 19:06:21.000000000 +0300
+@@ -99,6 +99,7 @@ static const char *CopyString(const char
+ 
+ keyword	[a-zA-Z][a-zA-Z0-9]*
+ number	[0-9]*
++colors	[0-9/,]*
+ string	\"[^\"\n]*\"
+ comment	\#([^\n]*)
+ space	[ \t]+
+@@ -115,6 +116,11 @@ junk	.
+ 		return NUMBER;
+ 	    }
+ 
++{colors}    {
++		yylval = (unsigned long)CopyString(yytext);
++		return COLORS;
++	    }
++
+ {string}    {
+ 		yylval = (unsigned long)CopyString(yytext);
+ 		return STRING;
+Index: b/modes.y
+===================================================================
+--- a/modes.y	2007-09-16 19:05:33.000000000 +0300
++++ b/modes.y	2007-09-16 19:06:21.000000000 +0300
+@@ -42,7 +42,7 @@ static void ClearVideoMode(void)
+ 
+ %token MODE GEOMETRY TIMINGS HSYNC VSYNC CSYNC GSYNC EXTSYNC BCAST LACED DOUBLE
+        RGBA NONSTD ACCEL GRAYSCALE
+-       ENDMODE POLARITY BOOLEAN STRING NUMBER 
++       ENDMODE POLARITY BOOLEAN STRING NUMBER COLORS
+ 
+ %%
+ 
+@@ -148,7 +148,7 @@ double	  : DOUBLE BOOLEAN
+ 	    }
+ 	  ;
+ 
+-rgba      : RGBA STRING
++rgba      : RGBA COLORS
+             {
+ 		makeRGBA(&VideoMode, (const char*)$2);
+ 	    }
--- fbset-2.1.orig/debian/patches/01_kernel_fb.h.patch
+++ fbset-2.1/debian/patches/01_kernel_fb.h.patch
@@ -0,0 +1,1163 @@
+Status: sent-upstream
+
+Index: b/fb.h
+===================================================================
+--- a/fb.h	2007-09-16 19:05:35.000000000 +0300
++++ b/fb.h	2007-09-16 19:05:54.000000000 +0300
+@@ -5,12 +5,8 @@
+ 
+ /* Definitions of frame buffers						*/
+ 
+-#define FB_MAJOR	29
+-
+-#define FB_MODES_SHIFT		5	/* 32 modes per framebuffer */
+-#define FB_NUM_MINORS		256	/* 256 Minors               */
+-#define FB_MAX			(FB_NUM_MINORS / (1 << FB_MODES_SHIFT))
+-#define GET_FB_IDX(node)	(MINOR(node) >> FB_MODES_SHIFT)
++#define FB_MAJOR		29
++#define FB_MAX			32	/* sufficient for now */
+ 
+ /* ioctls
+    0x46 is 'F'								*/
+@@ -20,12 +16,26 @@
+ #define FBIOGETCMAP		0x4604
+ #define FBIOPUTCMAP		0x4605
+ #define FBIOPAN_DISPLAY		0x4606
++#ifdef __KERNEL__
++#define FBIO_CURSOR            _IOWR('F', 0x08, struct fb_cursor_user)
++#else
++#define FBIO_CURSOR            _IOWR('F', 0x08, struct fb_cursor)
++#endif
+ /* 0x4607-0x460B are defined below */
+ /* #define FBIOGET_MONITORSPEC	0x460C */
+ /* #define FBIOPUT_MONITORSPEC	0x460D */
+ /* #define FBIOSWITCH_MONIBIT	0x460E */
+ #define FBIOGET_CON2FBMAP	0x460F
+ #define FBIOPUT_CON2FBMAP	0x4610
++#define FBIOBLANK		0x4611		/* arg: 0 or vesa level + 1 */
++#define FBIOGET_VBLANK		_IOR('F', 0x12, struct fb_vblank)
++#define FBIO_ALLOC              0x4613
++#define FBIO_FREE               0x4614
++#define FBIOGET_GLYPH           0x4615
++#define FBIOGET_HWCINFO         0x4616
++#define FBIOPUT_MODEINFO        0x4617
++#define FBIOGET_DISPINFO        0x4618
++
+ 
+ #define FB_TYPE_PACKED_PIXELS		0	/* Packed Pixels	*/
+ #define FB_TYPE_PLANES			1	/* Non interleaved planes */
+@@ -73,14 +83,61 @@
+ #define FB_ACCEL_MATROX_MGAG100	20	/* Matrox G100 (Productiva G100) */
+ #define FB_ACCEL_MATROX_MGAG200	21	/* Matrox G200 (Myst, Mill, ...) */
+ #define FB_ACCEL_SUN_CG14	22	/* Sun cgfourteen		 */
+-#define FB_ACCEL_SUN_BWTWO	23	/* Sun bwtwo			 */
+-#define FB_ACCEL_SUN_CGTHREE	24	/* Sun cgthree			 */
+-#define FB_ACCEL_SUN_TCX	25	/* Sun tcx			 */
+-#define FB_ACCEL_MATROX_MGAG400	26	/* Matrox G400			 */
++#define FB_ACCEL_SUN_BWTWO	23	/* Sun bwtwo			*/
++#define FB_ACCEL_SUN_CGTHREE	24	/* Sun cgthree			*/
++#define FB_ACCEL_SUN_TCX	25	/* Sun tcx			*/
++#define FB_ACCEL_MATROX_MGAG400	26	/* Matrox G400			*/
++#define FB_ACCEL_NV3		27	/* nVidia RIVA 128              */
++#define FB_ACCEL_NV4		28	/* nVidia RIVA TNT		*/
++#define FB_ACCEL_NV5		29	/* nVidia RIVA TNT2		*/
++#define FB_ACCEL_CT_6555x	30	/* C&T 6555x			*/
++#define FB_ACCEL_3DFX_BANSHEE	31	/* 3Dfx Banshee			*/
++#define FB_ACCEL_ATI_RAGE128	32	/* ATI Rage128 family		*/
++#define FB_ACCEL_IGS_CYBER2000	33	/* CyberPro 2000		*/
++#define FB_ACCEL_IGS_CYBER2010	34	/* CyberPro 2010		*/
++#define FB_ACCEL_IGS_CYBER5000	35	/* CyberPro 5000		*/
++#define FB_ACCEL_SIS_GLAMOUR    36	/* SiS 300/630/540              */
++#define FB_ACCEL_3DLABS_PERMEDIA3 37	/* 3Dlabs Permedia 3		*/
++#define FB_ACCEL_ATI_RADEON	38	/* ATI Radeon family		*/
++#define FB_ACCEL_I810           39      /* Intel 810/815                */
++#define FB_ACCEL_SIS_GLAMOUR_2  40	/* SiS 315, 650, 740		*/
++#define FB_ACCEL_SIS_XABRE      41	/* SiS 330 ("Xabre")		*/
++#define FB_ACCEL_I830           42      /* Intel 830M/845G/85x/865G     */
++#define FB_ACCEL_NV_10          43      /* nVidia Arch 10               */
++#define FB_ACCEL_NV_20          44      /* nVidia Arch 20               */
++#define FB_ACCEL_NV_30          45      /* nVidia Arch 30               */
++#define FB_ACCEL_NV_40          46      /* nVidia Arch 40               */
++#define FB_ACCEL_XGI_VOLARI_V	47	/* XGI Volari V3XT, V5, V8      */
++#define FB_ACCEL_XGI_VOLARI_Z	48	/* XGI Volari Z7                */
++#define FB_ACCEL_NEOMAGIC_NM2070 90	/* NeoMagic NM2070              */
++#define FB_ACCEL_NEOMAGIC_NM2090 91	/* NeoMagic NM2090              */
++#define FB_ACCEL_NEOMAGIC_NM2093 92	/* NeoMagic NM2093              */
++#define FB_ACCEL_NEOMAGIC_NM2097 93	/* NeoMagic NM2097              */
++#define FB_ACCEL_NEOMAGIC_NM2160 94	/* NeoMagic NM2160              */
++#define FB_ACCEL_NEOMAGIC_NM2200 95	/* NeoMagic NM2200              */
++#define FB_ACCEL_NEOMAGIC_NM2230 96	/* NeoMagic NM2230              */
++#define FB_ACCEL_NEOMAGIC_NM2360 97	/* NeoMagic NM2360              */
++#define FB_ACCEL_NEOMAGIC_NM2380 98	/* NeoMagic NM2380              */
++
++#define FB_ACCEL_SAVAGE4        0x80	/* S3 Savage4                   */
++#define FB_ACCEL_SAVAGE3D       0x81	/* S3 Savage3D                  */
++#define FB_ACCEL_SAVAGE3D_MV    0x82	/* S3 Savage3D-MV               */
++#define FB_ACCEL_SAVAGE2000     0x83	/* S3 Savage2000                */
++#define FB_ACCEL_SAVAGE_MX_MV   0x84	/* S3 Savage/MX-MV              */
++#define FB_ACCEL_SAVAGE_MX      0x85	/* S3 Savage/MX                 */
++#define FB_ACCEL_SAVAGE_IX_MV   0x86	/* S3 Savage/IX-MV              */
++#define FB_ACCEL_SAVAGE_IX      0x87	/* S3 Savage/IX                 */
++#define FB_ACCEL_PROSAVAGE_PM   0x88	/* S3 ProSavage PM133           */
++#define FB_ACCEL_PROSAVAGE_KM   0x89	/* S3 ProSavage KM133           */
++#define FB_ACCEL_S3TWISTER_P    0x8a	/* S3 Twister                   */
++#define FB_ACCEL_S3TWISTER_K    0x8b	/* S3 TwisterK                  */
++#define FB_ACCEL_SUPERSAVAGE    0x8c    /* S3 Supersavage               */
++#define FB_ACCEL_PROSAVAGE_DDR  0x8d	/* S3 ProSavage DDR             */
++#define FB_ACCEL_PROSAVAGE_DDRK 0x8e	/* S3 ProSavage DDR-K           */
+ 
+ struct fb_fix_screeninfo {
+ 	char id[16];			/* identification string eg "TT Builtin" */
+-	char *smem_start;		/* Start of frame buffer mem */
++	unsigned long smem_start;	/* Start of frame buffer mem */
+ 					/* (physical address) */
+ 	__u32 smem_len;			/* Length of frame buffer mem */
+ 	__u32 type;			/* see FB_TYPE_*		*/
+@@ -90,10 +147,11 @@ struct fb_fix_screeninfo {
+ 	__u16 ypanstep;			/* zero if no hardware panning  */
+ 	__u16 ywrapstep;		/* zero if no hardware ywrap    */
+ 	__u32 line_length;		/* length of a line in bytes    */
+-	char *mmio_start;		/* Start of Memory Mapped I/O   */
++	unsigned long mmio_start;	/* Start of Memory Mapped I/O   */
+ 					/* (physical address) */
+ 	__u32 mmio_len;			/* Length of Memory Mapped I/O  */
+-	__u32 accel;			/* Type of acceleration available */
++	__u32 accel;			/* Indicate to driver which	*/
++					/*  specific chip/card we have	*/
+ 	__u16 reserved[3];		/* Reserved for future compatibility */
+ };
+ 
+@@ -120,8 +178,10 @@ struct fb_bitfield {
+ #define FB_ACTIVATE_VBL	       16	/* activate values on next vbl  */
+ #define FB_CHANGE_CMAP_VBL     32	/* change colormap on vbl	*/
+ #define FB_ACTIVATE_ALL	       64	/* change all VCs on this fb	*/
++#define FB_ACTIVATE_FORCE     128	/* force apply even when no change*/
++#define FB_ACTIVATE_INV_MODE  256       /* invalidate videomode */
+ 
+-#define FB_ACCELF_TEXT		1	/* text mode acceleration */
++#define FB_ACCELF_TEXT		1	/* (OBSOLETE) see fb_info.flags and vc_mode */
+ 
+ #define FB_SYNC_HOR_HIGH_ACT	1	/* horizontal sync high active	*/
+ #define FB_SYNC_VERT_HIGH_ACT	2	/* vertical sync high active	*/
+@@ -141,6 +201,17 @@ struct fb_bitfield {
+ #define FB_VMODE_SMOOTH_XPAN	512	/* smooth xpan possible (internally used) */
+ #define FB_VMODE_CONUPDATE	512	/* don't update x/yoffset	*/
+ 
++/*
++ * Display rotation support
++ */
++#define FB_ROTATE_UR      0
++#define FB_ROTATE_CW      1
++#define FB_ROTATE_UD      2
++#define FB_ROTATE_CCW     3
++
++#define PICOS2KHZ(a) (1000000000UL/(a))
++#define KHZ2PICOS(a) (1000000000UL/(a))
++
+ struct fb_var_screeninfo {
+ 	__u32 xres;			/* visible resolution		*/
+ 	__u32 yres;
+@@ -164,7 +235,7 @@ struct fb_var_screeninfo {
+ 	__u32 height;			/* height of picture in mm    */
+ 	__u32 width;			/* width of picture in mm     */
+ 
+-	__u32 accel_flags;		/* acceleration flags (hints)	*/
++	__u32 accel_flags;		/* (OBSOLETE) see fb_info.flags */
+ 
+ 	/* Timing: All values in pixclocks, except pixclock (of course) */
+ 	__u32 pixclock;			/* pixel clock in ps (pico seconds) */
+@@ -176,7 +247,8 @@ struct fb_var_screeninfo {
+ 	__u32 vsync_len;		/* length of vertical sync	*/
+ 	__u32 sync;			/* see FB_SYNC_*		*/
+ 	__u32 vmode;			/* see FB_VMODE_*		*/
+-	__u32 reserved[6];		/* Reserved for future compatibility */
++	__u32 rotate;			/* angle we rotate counter clockwise */
++	__u32 reserved[5];		/* Reserved for future compatibility */
+ };
+ 
+ struct fb_cmap {
+@@ -193,305 +265,732 @@ struct fb_con2fbmap {
+ 	__u32 framebuffer;
+ };
+ 
+-struct fb_monspecs {
+-	__u32 hfmin;			/* hfreq lower limit (Hz) */
+-	__u32 hfmax; 			/* hfreq upper limit (Hz) */
+-	__u16 vfmin;			/* vfreq lower limit (Hz) */
+-	__u16 vfmax;			/* vfreq upper limit (Hz) */
+-	unsigned dpms : 1;		/* supports DPMS */
++/* VESA Blanking Levels */
++#define VESA_NO_BLANKING        0
++#define VESA_VSYNC_SUSPEND      1
++#define VESA_HSYNC_SUSPEND      2
++#define VESA_POWERDOWN          3
++
++
++enum {
++	/* screen: unblanked, hsync: on,  vsync: on */
++	FB_BLANK_UNBLANK       = VESA_NO_BLANKING,
++
++	/* screen: blanked,   hsync: on,  vsync: on */
++	FB_BLANK_NORMAL        = VESA_NO_BLANKING + 1,
++
++	/* screen: blanked,   hsync: on,  vsync: off */
++	FB_BLANK_VSYNC_SUSPEND = VESA_VSYNC_SUSPEND + 1,
++
++	/* screen: blanked,   hsync: off, vsync: on */
++	FB_BLANK_HSYNC_SUSPEND = VESA_HSYNC_SUSPEND + 1,
++
++	/* screen: blanked,   hsync: off, vsync: off */
++	FB_BLANK_POWERDOWN     = VESA_POWERDOWN + 1
++};
++
++#define FB_VBLANK_VBLANKING	0x001	/* currently in a vertical blank */
++#define FB_VBLANK_HBLANKING	0x002	/* currently in a horizontal blank */
++#define FB_VBLANK_HAVE_VBLANK	0x004	/* vertical blanks can be detected */
++#define FB_VBLANK_HAVE_HBLANK	0x008	/* horizontal blanks can be detected */
++#define FB_VBLANK_HAVE_COUNT	0x010	/* global retrace counter is available */
++#define FB_VBLANK_HAVE_VCOUNT	0x020	/* the vcount field is valid */
++#define FB_VBLANK_HAVE_HCOUNT	0x040	/* the hcount field is valid */
++#define FB_VBLANK_VSYNCING	0x080	/* currently in a vsync */
++#define FB_VBLANK_HAVE_VSYNC	0x100	/* verical syncs can be detected */
++
++struct fb_vblank {
++	__u32 flags;			/* FB_VBLANK flags */
++	__u32 count;			/* counter of retraces since boot */
++	__u32 vcount;			/* current scanline position */
++	__u32 hcount;			/* current scandot position */
++	__u32 reserved[4];		/* reserved for future compatibility */
++};
++
++/* Internal HW accel */
++#define ROP_COPY 0
++#define ROP_XOR  1
++
++struct fb_copyarea {
++	__u32 dx;
++	__u32 dy;
++	__u32 width;
++	__u32 height;
++	__u32 sx;
++	__u32 sy;
++};
++
++struct fb_fillrect {
++	__u32 dx;	/* screen-relative */
++	__u32 dy;
++	__u32 width;
++	__u32 height;
++	__u32 color;
++	__u32 rop;
++};
++
++struct fb_image {
++	__u32 dx;		/* Where to place image */
++	__u32 dy;
++	__u32 width;		/* Size of image */
++	__u32 height;
++	__u32 fg_color;		/* Only used when a mono bitmap */
++	__u32 bg_color;
++	__u8  depth;		/* Depth of the image */
++	const char *data;	/* Pointer to image data */
++	struct fb_cmap cmap;	/* color map info */
++};
++
++/*
++ * hardware cursor control
++ */
++
++#define FB_CUR_SETIMAGE 0x01
++#define FB_CUR_SETPOS   0x02
++#define FB_CUR_SETHOT   0x04
++#define FB_CUR_SETCMAP  0x08
++#define FB_CUR_SETSHAPE 0x10
++#define FB_CUR_SETSIZE	0x20
++#define FB_CUR_SETALL   0xFF
++
++struct fbcurpos {
++	__u16 x, y;
++};
++
++struct fb_cursor {
++	__u16 set;		/* what to set */
++	__u16 enable;		/* cursor on/off */
++	__u16 rop;		/* bitop operation */
++	const char *mask;	/* cursor mask bits */
++	struct fbcurpos hot;	/* cursor hot spot */
++	struct fb_image	image;	/* Cursor image */
+ };
+ 
+ #ifdef __KERNEL__
+ 
+ #include <linux/fs.h>
++#include <linux/init.h>
++#include <linux/tty.h>
++#include <linux/device.h>
++#include <linux/workqueue.h>
++#include <linux/devfs_fs_kernel.h>
++#include <linux/notifier.h>
++#include <linux/list.h>
++#include <asm/io.h>
+ 
+-
+-struct fb_info;
+-struct fb_info_gen;
+ struct vm_area_struct;
++struct fb_info;
++struct device;
+ struct file;
+ 
+-    /*
+-     *  Frame buffer operations
+-     */
++/* Definitions below are used in the parsed monitor specs */
++#define FB_DPMS_ACTIVE_OFF	1
++#define FB_DPMS_SUSPEND		2
++#define FB_DPMS_STANDBY		4
++
++#define FB_DISP_DDI		1
++#define FB_DISP_ANA_700_300	2
++#define FB_DISP_ANA_714_286	4
++#define FB_DISP_ANA_1000_400	8
++#define FB_DISP_ANA_700_000	16
++
++#define FB_DISP_MONO		32
++#define FB_DISP_RGB		64
++#define FB_DISP_MULTI		128
++#define FB_DISP_UNKNOWN		256
++
++#define FB_SIGNAL_NONE		0
++#define FB_SIGNAL_BLANK_BLANK	1
++#define FB_SIGNAL_SEPARATE	2
++#define FB_SIGNAL_COMPOSITE	4
++#define FB_SIGNAL_SYNC_ON_GREEN	8
++#define FB_SIGNAL_SERRATION_ON	16
++
++#define FB_MISC_PRIM_COLOR	1
++#define FB_MISC_1ST_DETAIL	2	/* First Detailed Timing is preferred */
++struct fb_chroma {
++	__u32 redx;	/* in fraction of 1024 */
++	__u32 greenx;
++	__u32 bluex;
++	__u32 whitex;
++	__u32 redy;
++	__u32 greeny;
++	__u32 bluey;
++	__u32 whitey;
++};
+ 
+-struct fb_ops {
+-    /* open/release and usage marking */
+-    int (*fb_open)(struct fb_info *info, int user);
+-    int (*fb_release)(struct fb_info *info, int user);
+-    /* get non settable parameters */
+-    int (*fb_get_fix)(struct fb_fix_screeninfo *fix, int con,
+-		      struct fb_info *info); 
+-    /* get settable parameters */
+-    int (*fb_get_var)(struct fb_var_screeninfo *var, int con,
+-		      struct fb_info *info);		
+-    /* set settable parameters */
+-    int (*fb_set_var)(struct fb_var_screeninfo *var, int con,
+-		      struct fb_info *info);		
+-    /* get colormap */
+-    int (*fb_get_cmap)(struct fb_cmap *cmap, int kspc, int con,
+-		       struct fb_info *info);
+-    /* set colormap */
+-    int (*fb_set_cmap)(struct fb_cmap *cmap, int kspc, int con,
+-		       struct fb_info *info);
+-    /* pan display */
+-    int (*fb_pan_display)(struct fb_var_screeninfo *var, int con,
+-			  struct fb_info *info);
+-    /* perform fb specific ioctl */
+-    int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
+-		    unsigned long arg, int con, struct fb_info *info);
+-    /* perform fb specific mmap */
+-    int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
+-    /* switch to/from raster image mode */
+-    int (*fb_rasterimg)(struct fb_info *info, int start);
++struct fb_monspecs {
++	struct fb_chroma chroma;
++	struct fb_videomode *modedb;	/* mode database */
++	__u8  manufacturer[4];		/* Manufacturer */
++	__u8  monitor[14];		/* Monitor String */
++	__u8  serial_no[14];		/* Serial Number */
++	__u8  ascii[14];		/* ? */
++	__u32 modedb_len;		/* mode database length */
++	__u32 model;			/* Monitor Model */
++	__u32 serial;			/* Serial Number - Integer */
++	__u32 year;			/* Year manufactured */
++	__u32 week;			/* Week Manufactured */
++	__u32 hfmin;			/* hfreq lower limit (Hz) */
++	__u32 hfmax;			/* hfreq upper limit (Hz) */
++	__u32 dclkmin;			/* pixelclock lower limit (Hz) */
++	__u32 dclkmax;			/* pixelclock upper limit (Hz) */
++	__u16 input;			/* display type - see FB_DISP_* */
++	__u16 dpms;			/* DPMS support - see FB_DPMS_ */
++	__u16 signal;			/* Signal Type - see FB_SIGNAL_* */
++	__u16 vfmin;			/* vfreq lower limit (Hz) */
++	__u16 vfmax;			/* vfreq upper limit (Hz) */
++	__u16 gamma;			/* Gamma - in fractions of 100 */
++	__u16 gtf	: 1;		/* supports GTF */
++	__u16 misc;			/* Misc flags - see FB_MISC_* */
++	__u8  version;			/* EDID version... */
++	__u8  revision;			/* ...and revision */
++	__u8  max_x;			/* Maximum horizontal size (cm) */
++	__u8  max_y;			/* Maximum vertical size (cm) */
++};
++
++struct fb_cmap_user {
++	__u32 start;			/* First entry	*/
++	__u32 len;			/* Number of entries */
++	__u16 __user *red;		/* Red values	*/
++	__u16 __user *green;
++	__u16 __user *blue;
++	__u16 __user *transp;		/* transparency, can be NULL */
++};
++
++struct fb_image_user {
++	__u32 dx;			/* Where to place image */
++	__u32 dy;
++	__u32 width;			/* Size of image */
++	__u32 height;
++	__u32 fg_color;			/* Only used when a mono bitmap */
++	__u32 bg_color;
++	__u8  depth;			/* Depth of the image */
++	const char __user *data;	/* Pointer to image data */
++	struct fb_cmap_user cmap;	/* color map info */
++};
++
++struct fb_cursor_user {
++	__u16 set;			/* what to set */
++	__u16 enable;			/* cursor on/off */
++	__u16 rop;			/* bitop operation */
++	const char __user *mask;	/* cursor mask bits */
++	struct fbcurpos hot;		/* cursor hot spot */
++	struct fb_image_user image;	/* Cursor image */
+ };
+ 
++/*
++ * Register/unregister for framebuffer events
++ */
++
++/*	The resolution of the passed in fb_info about to change */ 
++#define FB_EVENT_MODE_CHANGE		0x01
++/*	The display on this fb_info is beeing suspended, no access to the
++ *	framebuffer is allowed any more after that call returns
++ */
++#define FB_EVENT_SUSPEND		0x02
++/*	The display on this fb_info was resumed, you can restore the display
++ *	if you own it
++ */
++#define FB_EVENT_RESUME			0x03
++/*      An entry from the modelist was removed */
++#define FB_EVENT_MODE_DELETE            0x04
++/*      A driver registered itself */
++#define FB_EVENT_FB_REGISTERED          0x05
++/*      CONSOLE-SPECIFIC: get console to framebuffer mapping */
++#define FB_EVENT_GET_CONSOLE_MAP        0x06
++/*      CONSOLE-SPECIFIC: set console to framebuffer mapping */
++#define FB_EVENT_SET_CONSOLE_MAP        0x07
++/*      A display blank is requested       */
++#define FB_EVENT_BLANK                  0x08
++/*      Private modelist is to be replaced */
++#define FB_EVENT_NEW_MODELIST           0x09
++/*	The resolution of the passed in fb_info about to change and
++        all vc's should be changed         */
++#define FB_EVENT_MODE_CHANGE_ALL	0x0A
++/*      CONSOLE-SPECIFIC: set console rotation */
++#define FB_EVENT_SET_CON_ROTATE         0x0B
++/*      CONSOLE-SPECIFIC: get console rotation */
++#define FB_EVENT_GET_CON_ROTATE         0x0C
++/*      CONSOLE-SPECIFIC: rotate all consoles */
++#define FB_EVENT_SET_CON_ROTATE_ALL     0x0D
++
++struct fb_event {
++	struct fb_info *info;
++	void *data;
++};
+ 
+-   /*
+-    *    This is the interface between the low-level console driver and the
+-    *    low-level frame buffer device
+-    */
+-
+-struct display {
+-    /* Filled in by the frame buffer device */
+-
+-    struct fb_var_screeninfo var;   /* variable infos. yoffset and vmode */
+-				    /* are updated by fbcon.c */
+-    struct fb_cmap cmap;            /* colormap */
+-    char *screen_base;              /* pointer to top of virtual screen */    
+-				    /* (virtual address) */
+-    int visual;
+-    int type;                       /* see FB_TYPE_* */
+-    int type_aux;                   /* Interleave for interleaved Planes */
+-    u_short ypanstep;               /* zero if no hardware ypan */
+-    u_short ywrapstep;              /* zero if no hardware ywrap */
+-    u_long line_length;             /* length of a line in bytes */
+-    u_short can_soft_blank;         /* zero if no hardware blanking */
+-    u_short inverse;                /* != 0 text black on white as default */
+-    struct display_switch *dispsw;  /* low level operations */
+-    void *dispsw_data;		    /* optional dispsw helper data */
+-
+-#if 0
+-    struct fb_fix_cursorinfo fcrsr;
+-    struct fb_var_cursorinfo *vcrsr;
+-    struct fb_cursorstate crsrstate;
+-#endif
+ 
+-    /* Filled in by the low-level console driver */
++extern int fb_register_client(struct notifier_block *nb);
++extern int fb_unregister_client(struct notifier_block *nb);
++
++/*
++ * Pixmap structure definition
++ *
++ * The purpose of this structure is to translate data
++ * from the hardware independent format of fbdev to what
++ * format the hardware needs.
++ */
+ 
+-    struct vc_data *conp;           /* pointer to console data */
+-    struct fb_info *fb_info;        /* frame buffer for this console */
+-    int vrows;                      /* number of virtual rows */
+-    unsigned short cursor_x;	    /* current cursor position */
+-    unsigned short cursor_y;
+-    int fgcol;                      /* text colors */
+-    int bgcol;
+-    u_long next_line;               /* offset to one line below */
+-    u_long next_plane;              /* offset to next plane */
+-    u_char *fontdata;               /* Font associated to this display */
+-    unsigned short _fontheightlog;
+-    unsigned short _fontwidthlog;
+-    unsigned short _fontheight;
+-    unsigned short _fontwidth;
+-    int userfont;                   /* != 0 if fontdata kmalloc()ed */
+-    u_short scrollmode;             /* Scroll Method */
+-    short yscroll;                  /* Hardware scrolling */
+-    unsigned char fgshift, bgshift;
+-    unsigned short charmask;	    /* 0xff or 0x1ff */
++#define FB_PIXMAP_DEFAULT 1     /* used internally by fbcon */
++#define FB_PIXMAP_SYSTEM  2     /* memory is in system RAM  */
++#define FB_PIXMAP_IO      4     /* memory is iomapped       */
++#define FB_PIXMAP_SYNC    256   /* set if GPU can DMA       */
++
++struct fb_pixmap {
++	u8  *addr;		/* pointer to memory			*/
++	u32 size;		/* size of buffer in bytes		*/
++	u32 offset;		/* current offset to buffer		*/
++	u32 buf_align;		/* byte alignment of each bitmap	*/
++	u32 scan_align;		/* alignment per scanline		*/
++	u32 access_align;	/* alignment per read/write (bits)	*/
++	u32 flags;		/* see FB_PIXMAP_*			*/
++	/* access methods */
++	void (*writeio)(struct fb_info *info, void __iomem *dst, void *src, unsigned int size);
++	void (*readio) (struct fb_info *info, void *dst, void __iomem *src, unsigned int size);
+ };
+ 
+ 
+-struct fb_info {
+-   char modename[40];			/* default video mode */
+-   kdev_t node;
+-   int flags;
+-#define FBINFO_FLAG_MODULE	1	/* Low-level driver is a module */
+-   struct fb_ops *fbops;
+-   struct fb_monspecs monspecs;
+-   struct display *disp;		/* initial display variable */
+-   struct vc_data *display_fg;		/* Console visible on this display */
+-   char fontname[40];			/* default font name */
+-   int (*changevar)(int);		/* tell console var has changed */
+-   int (*switch_con)(int, struct fb_info*);
+-					/* tell fb to switch consoles */
+-   int (*updatevar)(int, struct fb_info*);
+-					/* tell fb to update the vars */
+-   void (*blank)(int, struct fb_info*);	/* tell fb to (un)blank the screen */
+-					/* arg = 0: unblank */
+-					/* arg > 0: VESA level (arg-1) */
++/*
++ * Frame buffer operations
++ *
++ * LOCKING NOTE: those functions must _ALL_ be called with the console
++ * semaphore held, this is the only suitable locking mecanism we have
++ * in 2.6. Some may be called at interrupt time at this point though.
++ */
+ 
+-   /* From here on everything is device dependent */
++struct fb_ops {
++	/* open/release and usage marking */
++	struct module *owner;
++	int (*fb_open)(struct fb_info *info, int user);
++	int (*fb_release)(struct fb_info *info, int user);
++
++	/* For framebuffers with strange non linear layouts or that do not
++	 * work with normal memory mapped access
++	 */
++	ssize_t (*fb_read)(struct file *file, char __user *buf, size_t count, loff_t *ppos);
++	ssize_t (*fb_write)(struct file *file, const char __user *buf, size_t count, loff_t *ppos);
++
++	/* checks var and eventually tweaks it to something supported,
++	 * DO NOT MODIFY PAR */
++	int (*fb_check_var)(struct fb_var_screeninfo *var, struct fb_info *info);
++
++	/* set the video mode according to info->var */
++	int (*fb_set_par)(struct fb_info *info);
++
++	/* set color register */
++	int (*fb_setcolreg)(unsigned regno, unsigned red, unsigned green,
++			    unsigned blue, unsigned transp, struct fb_info *info);
++
++	/* set color registers in batch */
++	int (*fb_setcmap)(struct fb_cmap *cmap, struct fb_info *info);
++
++	/* blank display */
++	int (*fb_blank)(int blank, struct fb_info *info);
++
++	/* pan display */
++	int (*fb_pan_display)(struct fb_var_screeninfo *var, struct fb_info *info);
++
++	/* Draws a rectangle */
++	void (*fb_fillrect) (struct fb_info *info, const struct fb_fillrect *rect);
++	/* Copy data from area to another */
++	void (*fb_copyarea) (struct fb_info *info, const struct fb_copyarea *region);
++	/* Draws a image to the display */
++	void (*fb_imageblit) (struct fb_info *info, const struct fb_image *image);
++
++	/* Draws cursor */
++	int (*fb_cursor) (struct fb_info *info, struct fb_cursor *cursor);
++
++	/* Rotates the display */
++	void (*fb_rotate)(struct fb_info *info, int angle);
++
++	/* wait for blit idle, optional */
++	int (*fb_sync)(struct fb_info *info);
++
++	/* perform fb specific ioctl (optional) */
++	int (*fb_ioctl)(struct inode *inode, struct file *file, unsigned int cmd,
++			unsigned long arg, struct fb_info *info);
++
++	/* Handle 32bit compat ioctl (optional) */
++	long (*fb_compat_ioctl)(struct file *f, unsigned cmd, unsigned long arg,
++			       struct fb_info *info);
++
++	/* perform fb specific mmap */
++	int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
++
++	/* save current hardware state */
++	void (*fb_save_state)(struct fb_info *info);
++
++	/* restore saved state */
++	void (*fb_restore_state)(struct fb_info *info);
++};
++
++#ifdef CONFIG_FB_TILEBLITTING
++
++#define FB_TILE_CURSOR_NONE        0
++#define FB_TILE_CURSOR_UNDERLINE   1
++#define FB_TILE_CURSOR_LOWER_THIRD 2
++#define FB_TILE_CURSOR_LOWER_HALF  3
++#define FB_TILE_CURSOR_TWO_THIRDS  4
++#define FB_TILE_CURSOR_BLOCK       5
++
++struct fb_tilemap {
++	__u32 width;                /* width of each tile in pixels */
++	__u32 height;               /* height of each tile in scanlines */
++	__u32 depth;                /* color depth of each tile */
++	__u32 length;               /* number of tiles in the map */
++	const __u8 *data;           /* actual tile map: a bitmap array, packed
++				       to the nearest byte */
++};
++
++struct fb_tilerect {
++	__u32 sx;                   /* origin in the x-axis */
++	__u32 sy;                   /* origin in the y-axis */
++	__u32 width;                /* number of tiles in the x-axis */
++	__u32 height;               /* number of tiles in the y-axis */
++	__u32 index;                /* what tile to use: index to tile map */
++	__u32 fg;                   /* foreground color */
++	__u32 bg;                   /* background color */
++	__u32 rop;                  /* raster operation */
++};
++
++struct fb_tilearea {
++	__u32 sx;                   /* source origin in the x-axis */
++	__u32 sy;                   /* source origin in the y-axis */
++	__u32 dx;                   /* destination origin in the x-axis */
++	__u32 dy;                   /* destination origin in the y-axis */
++	__u32 width;                /* number of tiles in the x-axis */
++	__u32 height;               /* number of tiles in the y-axis */
++};
++
++struct fb_tileblit {
++	__u32 sx;                   /* origin in the x-axis */
++	__u32 sy;                   /* origin in the y-axis */
++	__u32 width;                /* number of tiles in the x-axis */
++	__u32 height;               /* number of tiles in the y-axis */
++	__u32 fg;                   /* foreground color */
++	__u32 bg;                   /* background color */
++	__u32 length;               /* number of tiles to draw */
++	__u32 *indices;             /* array of indices to tile map */
++};
++
++struct fb_tilecursor {
++	__u32 sx;                   /* cursor position in the x-axis */
++	__u32 sy;                   /* cursor position in the y-axis */
++	__u32 mode;                 /* 0 = erase, 1 = draw */
++	__u32 shape;                /* see FB_TILE_CURSOR_* */
++	__u32 fg;                   /* foreground color */
++	__u32 bg;                   /* background color */
++};
++
++struct fb_tile_ops {
++	/* set tile characteristics */
++	void (*fb_settile)(struct fb_info *info, struct fb_tilemap *map);
++
++	/* all dimensions from hereon are in terms of tiles */
++
++	/* move a rectangular region of tiles from one area to another*/
++	void (*fb_tilecopy)(struct fb_info *info, struct fb_tilearea *area);
++	/* fill a rectangular region with a tile */
++	void (*fb_tilefill)(struct fb_info *info, struct fb_tilerect *rect);
++	/* copy an array of tiles */
++	void (*fb_tileblit)(struct fb_info *info, struct fb_tileblit *blit);
++	/* cursor */
++	void (*fb_tilecursor)(struct fb_info *info,
++			      struct fb_tilecursor *cursor);
++};
++#endif /* CONFIG_FB_TILEBLITTING */
++
++/* FBINFO_* = fb_info.flags bit flags */
++#define FBINFO_MODULE		0x0001	/* Low-level driver is a module */
++#define FBINFO_HWACCEL_DISABLED	0x0002
++	/* When FBINFO_HWACCEL_DISABLED is set:
++	 *  Hardware acceleration is turned off.  Software implementations
++	 *  of required functions (copyarea(), fillrect(), and imageblit())
++	 *  takes over; acceleration engine should be in a quiescent state */
++
++/* hints */
++#define FBINFO_PARTIAL_PAN_OK	0x0040 /* otw use pan only for double-buffering */
++#define FBINFO_READS_FAST	0x0080 /* soft-copy faster than rendering */
++
++/* hardware supported ops */
++/*  semantics: when a bit is set, it indicates that the operation is
++ *   accelerated by hardware.
++ *  required functions will still work even if the bit is not set.
++ *  optional functions may not even exist if the flag bit is not set.
++ */
++#define FBINFO_HWACCEL_NONE		0x0000
++#define FBINFO_HWACCEL_COPYAREA		0x0100 /* required */
++#define FBINFO_HWACCEL_FILLRECT		0x0200 /* required */
++#define FBINFO_HWACCEL_IMAGEBLIT	0x0400 /* required */
++#define FBINFO_HWACCEL_ROTATE		0x0800 /* optional */
++#define FBINFO_HWACCEL_XPAN		0x1000 /* optional */
++#define FBINFO_HWACCEL_YPAN		0x2000 /* optional */
++#define FBINFO_HWACCEL_YWRAP		0x4000 /* optional */
++
++#define FBINFO_MISC_USEREVENT          0x10000 /* event request
++						  from userspace */
++#define FBINFO_MISC_TILEBLITTING       0x20000 /* use tile blitting */
++
++/* A driver may set this flag to indicate that it does want a set_par to be
++ * called every time when fbcon_switch is executed. The advantage is that with
++ * this flag set you can really be shure that set_par is always called before
++ * any of the functions dependant on the correct hardware state or altering
++ * that state, even if you are using some broken X releases. The disadvantage
++ * is that it introduces unwanted delays to every console switch if set_par
++ * is slow. It is a good idea to try this flag in the drivers initialization
++ * code whenever there is a bug report related to switching between X and the
++ * framebuffer console.
++ */
++#define FBINFO_MISC_ALWAYS_SETPAR   0x40000
++
++struct fb_info {
++	int node;
++	int flags;
++	struct fb_var_screeninfo var;	/* Current var */
++	struct fb_fix_screeninfo fix;	/* Current fix */
++	struct fb_monspecs monspecs;	/* Current Monitor specs */
++	struct work_struct queue;	/* Framebuffer event queue */
++	struct fb_pixmap pixmap;	/* Image hardware mapper */
++	struct fb_pixmap sprite;	/* Cursor hardware mapper */
++	struct fb_cmap cmap;		/* Current cmap */
++	struct list_head modelist;      /* mode list */
++	struct fb_videomode *mode;	/* current mode */
++	struct fb_ops *fbops;
++	struct device *device;
++	struct class_device *class_device; /* sysfs per device attrs */
++#ifdef CONFIG_FB_TILEBLITTING
++	struct fb_tile_ops *tileops;    /* Tile Blitting */
++#endif
++	char __iomem *screen_base;	/* Virtual address */
++	unsigned long screen_size;	/* Amount of ioremapped VRAM or 0 */ 
++	void *pseudo_palette;		/* Fake palette of 16 colors */ 
++#define FBINFO_STATE_RUNNING	0
++#define FBINFO_STATE_SUSPENDED	1
++	u32 state;			/* Hardware state i.e suspend */
++	void *fbcon_par;                /* fbcon use-only private area */
++	/* From here on everything is device dependent */
++	void *par;	
+ };
+ 
+ #ifdef MODULE
+-#define FBINFO_FLAG_DEFAULT	FBINFO_FLAG_MODULE
++#define FBINFO_DEFAULT	FBINFO_MODULE
+ #else
+-#define FBINFO_FLAG_DEFAULT	0
++#define FBINFO_DEFAULT	0
+ #endif
+ 
+-    /*
+-     *  This structure abstracts from the underlying hardware. It is not
+-     *  mandatory but used by the `generic' frame buffer operations.
+-     *  Read drivers/video/skeletonfb.c for more information.
+-     */
++// This will go away
++#define FBINFO_FLAG_MODULE	FBINFO_MODULE
++#define FBINFO_FLAG_DEFAULT	FBINFO_DEFAULT
++
++/* This will go away
++ * fbset currently hacks in FB_ACCELF_TEXT into var.accel_flags
++ * when it wants to turn the acceleration engine on.  This is
++ * really a separate operation, and should be modified via sysfs.
++ *  But for now, we leave it broken with the following define
++ */
++#define STUPID_ACCELF_TEXT_SHIT
+ 
+-struct fbgen_hwswitch {
+-    void (*detect)(void);
+-    int (*encode_fix)(struct fb_fix_screeninfo *fix, const void *par,
+-		      struct fb_info_gen *info);
+-    int (*decode_var)(const struct fb_var_screeninfo *var, void *par,
+-		      struct fb_info_gen *info);
+-    int (*encode_var)(struct fb_var_screeninfo *var, const void *par,
+-		      struct fb_info_gen *info);
+-    void (*get_par)(void *par, struct fb_info_gen *info);
+-    void (*set_par)(const void *par, struct fb_info_gen *info);
+-    int (*getcolreg)(unsigned regno, unsigned *red, unsigned *green,
+-		     unsigned *blue, unsigned *transp, struct fb_info *info);
+-    int (*setcolreg)(unsigned regno, unsigned red, unsigned green,
+-		     unsigned blue, unsigned transp, struct fb_info *info);
+-    int (*pan_display)(const struct fb_var_screeninfo *var,
+-		       struct fb_info_gen *info);
+-    int (*blank)(int blank_mode, struct fb_info_gen *info);
+-    void (*set_disp)(const void *par, struct display *disp,
+-		     struct fb_info_gen *info);
+-};
+-
+-struct fb_info_gen {
+-    struct fb_info info;
+-
+-    /* Entries for a generic frame buffer device */
+-    /* Yes, this starts looking like C++ */
+-    u_int parsize;
+-    struct fbgen_hwswitch *fbhw;
++// This will go away
++#if defined(__sparc__)
+ 
+-   /* From here on everything is device dependent */
+-};
++/* We map all of our framebuffers such that big-endian accesses
++ * are what we want, so the following is sufficient.
++ */
+ 
+-    /*
+-     *  `Generic' versions of the frame buffer device operations
+-     */
++// This will go away
++#define fb_readb sbus_readb
++#define fb_readw sbus_readw
++#define fb_readl sbus_readl
++#define fb_readq sbus_readq
++#define fb_writeb sbus_writeb
++#define fb_writew sbus_writew
++#define fb_writel sbus_writel
++#define fb_writeq sbus_writeq
++#define fb_memset sbus_memset_io
++
++#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || defined(__hppa__) || (defined(__sh__) && !defined(__SH5__)) || defined(__powerpc__)
++
++#define fb_readb __raw_readb
++#define fb_readw __raw_readw
++#define fb_readl __raw_readl
++#define fb_readq __raw_readq
++#define fb_writeb __raw_writeb
++#define fb_writew __raw_writew
++#define fb_writel __raw_writel
++#define fb_writeq __raw_writeq
++#define fb_memset memset_io
+ 
+-extern int fbgen_get_fix(struct fb_fix_screeninfo *fix, int con,
+-			 struct fb_info *info);
+-extern int fbgen_get_var(struct fb_var_screeninfo *var, int con,
+-			 struct fb_info *info);
+-extern int fbgen_set_var(struct fb_var_screeninfo *var, int con,
+-			 struct fb_info *info);
+-extern int fbgen_get_cmap(struct fb_cmap *cmap, int kspc, int con,
+-			  struct fb_info *info);
+-extern int fbgen_set_cmap(struct fb_cmap *cmap, int kspc, int con,
+-			  struct fb_info *info);
+-extern int fbgen_pan_display(struct fb_var_screeninfo *var, int con,
+-			     struct fb_info *info);
+-extern int fbgen_ioctl(struct inode *inode, struct file *file,
+-		       unsigned int cmd, unsigned long arg, int con,
+-		       struct fb_info *info);
++#else
++
++#define fb_readb(addr) (*(volatile u8 *) (addr))
++#define fb_readw(addr) (*(volatile u16 *) (addr))
++#define fb_readl(addr) (*(volatile u32 *) (addr))
++#define fb_readq(addr) (*(volatile u64 *) (addr))
++#define fb_writeb(b,addr) (*(volatile u8 *) (addr) = (b))
++#define fb_writew(b,addr) (*(volatile u16 *) (addr) = (b))
++#define fb_writel(b,addr) (*(volatile u32 *) (addr) = (b))
++#define fb_writeq(b,addr) (*(volatile u64 *) (addr) = (b))
++#define fb_memset memset
++
++#endif
++
++#if defined (__BIG_ENDIAN)
++#define FB_LEFT_POS(bpp)          (32 - bpp)
++#define FB_SHIFT_HIGH(val, bits)  ((val) >> (bits))
++#define FB_SHIFT_LOW(val, bits)   ((val) << (bits))
++#define FB_BIT_NR(b)              (7 - (b))
++#else
++#define FB_LEFT_POS(bpp)          (0)
++#define FB_SHIFT_HIGH(val, bits)  ((val) << (bits))
++#define FB_SHIFT_LOW(val, bits)   ((val) >> (bits))
++#define FB_BIT_NR(b)              (b)
++#endif
+ 
+     /*
+-     *  Helper functions
++     *  `Generic' versions of the frame buffer device operations
+      */
+ 
+-extern int fbgen_do_set_var(struct fb_var_screeninfo *var, int isactive,
+-			    struct fb_info_gen *info);
+-extern void fbgen_set_disp(int con, struct fb_info_gen *info);
+-extern void fbgen_install_cmap(int con, struct fb_info_gen *info);
+-extern int fbgen_update_var(int con, struct fb_info *info);
+-extern int fbgen_switch(int con, struct fb_info *info);
+-extern void fbgen_blank(int blank, struct fb_info *info);
++extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var); 
++extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var); 
++extern int fb_blank(struct fb_info *info, int blank);
++extern void cfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect); 
++extern void cfb_copyarea(struct fb_info *info, const struct fb_copyarea *area); 
++extern void cfb_imageblit(struct fb_info *info, const struct fb_image *image);
+ 
++/* drivers/video/fbmem.c */
++extern int register_framebuffer(struct fb_info *fb_info);
++extern int unregister_framebuffer(struct fb_info *fb_info);
++extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);
++extern int fb_show_logo(struct fb_info *fb_info, int rotate);
++extern char* fb_get_buffer_offset(struct fb_info *info, struct fb_pixmap *buf, u32 size);
++extern void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx,
++				u32 height, u32 shift_high, u32 shift_low, u32 mod);
++extern void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 height);
++extern void fb_set_suspend(struct fb_info *info, int state);
++extern int fb_get_color_depth(struct fb_var_screeninfo *var,
++			      struct fb_fix_screeninfo *fix);
++extern int fb_get_options(char *name, char **option);
++extern int fb_new_modelist(struct fb_info *info);
++extern int fb_con_duit(struct fb_info *info, int event, void *data);
+ 
+-struct fb_videomode {
+-    const char *name;
+-    struct fb_var_screeninfo var;
+-};
++extern struct fb_info *registered_fb[FB_MAX];
++extern int num_registered_fb;
+ 
++static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch,
++					   u8 *src, u32 s_pitch, u32 height)
++{
++	int i, j;
++
++	d_pitch -= s_pitch;
++
++	for (i = height; i--; ) {
++		/* s_pitch is a few bytes at the most, memcpy is suboptimal */
++		for (j = 0; j < s_pitch; j++)
++			*dst++ = *src++;
++		dst += d_pitch;
++	}
++}
++
++/* drivers/video/fbsysfs.c */
++extern struct fb_info *framebuffer_alloc(size_t size, struct device *dev);
++extern void framebuffer_release(struct fb_info *info);
++extern int fb_init_class_device(struct fb_info *fb_info);
++extern void fb_cleanup_class_device(struct fb_info *head);
++
++/* drivers/video/fbmon.c */
++#define FB_MAXTIMINGS		0
++#define FB_VSYNCTIMINGS		1
++#define FB_HSYNCTIMINGS		2
++#define FB_DCLKTIMINGS		3
++#define FB_IGNOREMON		0x100
++
++#define FB_MODE_IS_UNKNOWN	0
++#define FB_MODE_IS_DETAILED	1
++#define FB_MODE_IS_STANDARD	2
++#define FB_MODE_IS_VESA		4
++#define FB_MODE_IS_CALCULATED	8
++#define FB_MODE_IS_FIRST	16
++#define FB_MODE_IS_FROM_VAR     32
+ 
+-/* drivers/char/fbmem.c */
+-extern int register_framebuffer(struct fb_info *fb_info);
+-extern int unregister_framebuffer(const struct fb_info *fb_info);
+ extern int fbmon_valid_timings(u_int pixclock, u_int htotal, u_int vtotal,
+ 			       const struct fb_info *fb_info);
+ extern int fbmon_dpms(const struct fb_info *fb_info);
+-
+-
+-extern int num_registered_fb;
+-extern struct fb_info *registered_fb[FB_MAX];
+-extern char con2fb_map[MAX_NR_CONSOLES];
+-
+-/* drivers/video/fbcon.c */
+-extern struct display fb_display[MAX_NR_CONSOLES];
++extern int fb_get_mode(int flags, u32 val, struct fb_var_screeninfo *var,
++		       struct fb_info *info);
++extern int fb_validate_mode(const struct fb_var_screeninfo *var,
++			    struct fb_info *info);
++extern int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var);
++extern const unsigned char *fb_firmware_edid(struct device *device);
++extern void fb_edid_to_monspecs(unsigned char *edid,
++				struct fb_monspecs *specs);
++extern void fb_destroy_modedb(struct fb_videomode *modedb);
++extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
++
++/* drivers/video/modedb.c */
++#define VESA_MODEDB_SIZE 34
++extern void fb_var_to_videomode(struct fb_videomode *mode,
++				struct fb_var_screeninfo *var);
++extern void fb_videomode_to_var(struct fb_var_screeninfo *var,
++				struct fb_videomode *mode);
++extern int fb_mode_is_equal(struct fb_videomode *mode1,
++			    struct fb_videomode *mode2);
++extern int fb_add_videomode(struct fb_videomode *mode, struct list_head *head);
++extern void fb_delete_videomode(struct fb_videomode *mode,
++				struct list_head *head);
++extern struct fb_videomode *fb_match_mode(struct fb_var_screeninfo *var,
++					  struct list_head *head);
++extern struct fb_videomode *fb_find_best_mode(struct fb_var_screeninfo *var,
++					      struct list_head *head);
++extern struct fb_videomode *fb_find_nearest_mode(struct fb_videomode *mode,
++						 struct list_head *head);
++extern void fb_destroy_modelist(struct list_head *head);
++extern void fb_videomode_to_modelist(struct fb_videomode *modedb, int num,
++				     struct list_head *head);
++extern struct fb_videomode *fb_find_best_display(struct fb_monspecs *specs,
++						 struct list_head *head);
+ 
+ /* drivers/video/fbcmap.c */
+ extern int fb_alloc_cmap(struct fb_cmap *cmap, int len, int transp);
+-extern void fb_copy_cmap(struct fb_cmap *from, struct fb_cmap *to,
+-			 int fsfromto);
+-extern int fb_get_cmap(struct fb_cmap *cmap, int kspc,
+-		       int (*getcolreg)(u_int, u_int *, u_int *, u_int *,
+-					u_int *, struct fb_info *),
+-		       struct fb_info *fb_info);
+-extern int fb_set_cmap(struct fb_cmap *cmap, int kspc,
+-		       int (*setcolreg)(u_int, u_int, u_int, u_int, u_int,
+-					struct fb_info *),
+-		       struct fb_info *fb_info);
++extern void fb_dealloc_cmap(struct fb_cmap *cmap);
++extern int fb_copy_cmap(struct fb_cmap *from, struct fb_cmap *to);
++extern int fb_cmap_to_user(struct fb_cmap *from, struct fb_cmap_user *to);
++extern int fb_set_cmap(struct fb_cmap *cmap, struct fb_info *fb_info);
++extern int fb_set_user_cmap(struct fb_cmap_user *cmap, struct fb_info *fb_info);
+ extern struct fb_cmap *fb_default_cmap(int len);
+ extern void fb_invert_cmaps(void);
+ 
+-/* VESA Blanking Levels */
+-#define VESA_NO_BLANKING	0
+-#define VESA_VSYNC_SUSPEND	1
+-#define VESA_HSYNC_SUSPEND	2
+-#define VESA_POWERDOWN		3
++struct fb_videomode {
++	const char *name;	/* optional */
++	u32 refresh;		/* optional */
++	u32 xres;
++	u32 yres;
++	u32 pixclock;
++	u32 left_margin;
++	u32 right_margin;
++	u32 upper_margin;
++	u32 lower_margin;
++	u32 hsync_len;
++	u32 vsync_len;
++	u32 sync;
++	u32 vmode;
++	u32 flag;
++};
++
++extern const struct fb_videomode vesa_modes[];
++
++struct fb_modelist {
++	struct list_head list;
++	struct fb_videomode mode;
++};
++
++extern int fb_find_mode(struct fb_var_screeninfo *var,
++			struct fb_info *info, const char *mode_option,
++			const struct fb_videomode *db,
++			unsigned int dbsize,
++			const struct fb_videomode *default_mode,
++			unsigned int default_bpp);
+ 
+ #endif /* __KERNEL__ */
+ 
+-#if 1
+-
+-#define FBCMD_GET_CURRENTPAR	0xDEAD0005
+-#define FBCMD_SET_CURRENTPAR	0xDEAD8005
+-
+-#endif
+-
+-
+-#if 1 /* Preliminary */
+-
+-   /*
+-    *    Hardware Cursor
+-    */
+-
+-#define FBIOGET_FCURSORINFO     0x4607
+-#define FBIOGET_VCURSORINFO     0x4608
+-#define FBIOPUT_VCURSORINFO     0x4609
+-#define FBIOGET_CURSORSTATE     0x460A
+-#define FBIOPUT_CURSORSTATE     0x460B
+-
+-
+-struct fb_fix_cursorinfo {
+-	__u16 crsr_width;		/* width and height of the cursor in */
+-	__u16 crsr_height;		/* pixels (zero if no cursor)	*/
+-	__u16 crsr_xsize;		/* cursor size in display pixels */
+-	__u16 crsr_ysize;
+-	__u16 crsr_color1;		/* colormap entry for cursor color1 */
+-	__u16 crsr_color2;		/* colormap entry for cursor color2 */
+-};
+-
+-struct fb_var_cursorinfo {
+-	__u16 width;
+-	__u16 height;
+-	__u16 xspot;
+-	__u16 yspot;
+-	__u8 data[1];			/* field with [height][width]        */
+-};
+-
+-struct fb_cursorstate {
+-	__s16 xoffset;
+-	__s16 yoffset;
+-	__u16 mode;
+-};
+-
+-#define FB_CURSOR_OFF		0
+-#define FB_CURSOR_ON		1
+-#define FB_CURSOR_FLASH		2
+-
+-#endif /* Preliminary */
+-
+ #endif /* _LINUX_FB_H */
--- fbset-2.1.orig/debian/patches/06_fbset_usage.patch
+++ fbset-2.1/debian/patches/06_fbset_usage.patch
@@ -0,0 +1,24 @@
+Status: sent-upstream
+
+Index: b/fbset.c
+===================================================================
+--- a/fbset.c	2007-09-16 19:06:09.000000000 +0300
++++ b/fbset.c	2007-09-16 19:06:11.000000000 +0300
+@@ -833,7 +833,8 @@ static int FillScanRates(struct VideoMod
+ static void Usage(void)
+ {
+     puts(VERSION);
+-    Die("\nUsage: %s [options] [mode]\n\n"
++    printf(
++	"\nUsage: %s [options] [mode]\n\n"
+ 	"Valid options:\n"
+ 	"  General options:\n"
+ 	"    -h, --help         : display this usage information\n"
+@@ -888,6 +889,7 @@ static void Usage(void)
+ 	"    -step <value>      : step increment (in pixels or pixel lines)\n"
+ 	"                         (default is 8 horizontal, 2 vertical)\n",
+ 	ProgramName);
++	exit(0);
+ }
+ 
+ 
--- fbset-2.1.orig/debian/patches/05_fbset_devfs.patch
+++ fbset-2.1/debian/patches/05_fbset_devfs.patch
@@ -0,0 +1,40 @@
+Status: obsolete
+# This patch should be removed after etch, as the kernel will not support
+# devfs.
+
+Index: b/fbset.c
+===================================================================
+--- a/fbset.c	2007-09-16 19:06:06.000000000 +0300
++++ b/fbset.c	2007-09-16 19:06:09.000000000 +0300
+@@ -42,6 +42,7 @@ struct inode;
+      */
+ 
+ #define DEFAULT_FRAMEBUFFER	"/dev/fb0"
++#define DEFAULT_FRAMEBUFFER_DEVFS	"/dev/fb/0"
+ 
+ 
+     /*
+@@ -846,7 +847,7 @@ static void Usage(void)
+ 	"    -a, --all          : change all virtual consoles on this device\n"
+ 	"  Frame buffer special device nodes:\n"
+ 	"    -fb <device>       : processed frame buffer device\n"
+-	"                         (default is " DEFAULT_FRAMEBUFFER ")\n"
++	"                         (default is " DEFAULT_FRAMEBUFFER "; " DEFAULT_FRAMEBUFFER_DEVFS " when using devfs)\n"
+ 	"  Video mode database:\n"
+ 	"    -db <file>         : video mode database file\n"
+ 	"                         (default is " DEFAULT_MODEDBFILE ")\n"
+@@ -977,8 +978,12 @@ int main(int argc, char *argv[])
+     if (Opt_version || Opt_verbose)
+ 	puts(VERSION);
+ 
+-    if (!Opt_fb)
+-	Opt_fb = DEFAULT_FRAMEBUFFER;
++    if (!Opt_fb) {
++        if (access("/dev/.devfsd", F_OK) == 0)  /* devfs detected */
++	    Opt_fb = DEFAULT_FRAMEBUFFER_DEVFS;
++	else
++	    Opt_fb = DEFAULT_FRAMEBUFFER;
++    }
+ 
+     /*
+      *  Open the Frame Buffer Device
--- fbset-2.1.orig/debian/patches/02_fb_modes.patch
+++ fbset-2.1/debian/patches/02_fb_modes.patch
@@ -0,0 +1,133 @@
+Index: b/etc/fb.modes.ATI
+===================================================================
+--- a/etc/fb.modes.ATI	2007-09-16 19:05:35.000000000 +0300
++++ b/etc/fb.modes.ATI	2007-09-16 19:06:01.000000000 +0300
+@@ -6,6 +6,8 @@
+ #       Mach64 Programmer's Guide, Appendix C
+ #       (C) 1998 ATI Technologies Inc.
+ #
++#  Kop: this are very generic modes and not only for ATI cards.
++#
+ 
+ #
+ #	640x480, 60 Hz, Non-Interlaced (25.175 MHz dotclock)
+@@ -132,6 +134,36 @@ mode "640x480-100"
+     timings 22272 48 32 17 22 128 12
+ endmode
+  
++
++#
++#       768x576, 75 Hz, Non-Interlaced (49.188 MHz dotclock)
++#
++#                               Horizontal      Vertical
++#       Resolution              768             576
++#       Scan Frequency          46.580 kHz      75.008 Hz
++#       Sync Width              us              ms
++#                               chars           lines
++#       Front Porch             us              ms
++#                               chars           lines
++#       Back Porch              us              ms
++#                               chars           lines
++#       Active Time             us              ms
++#                               chars           lines
++#       Blank Time              us              ms
++#                               chars           lines
++#       Polarity                negative        negative
++#
++# This is a mode often used, because fbtv suggests this, since
++# this is the mode for "normal" TVs.
++#
++
++mode "768x576-75"
++    # D: 49.188 MHz, H: 46.580 kHz, V: 75.008 Hz
++    geometry 768 576 768 576 32
++    timings 20330 128 32 32 8 128 5
++endmode
++
++
+ #
+ #	800x600, 48 Hz, Interlaced (36.00 MHz dotclock)
+ #	
+@@ -430,7 +462,7 @@ endmode
+ #	1024x768, 72 Hz, Non-Interlaced (75.00 MHz dotclock)
+ #	
+ #				Horizontal	Vertical
+-#	Resolution		10224		768
++#	Resolution		1024		768
+ #	Scan Frequency		58.230 kHz	72.245 Hz
+ #	Sync Width		1.813 us	0.103 ms
+ #				17 chars	6 lines
+@@ -447,7 +479,7 @@ endmode
+ 
+ mode "1024x768-72"
+     # D: 75.00 MHz, H: 58.230 kHz, V: 72.245 Hz
+-    geometry 10224 768 10224 768 8
++    geometry 1024 768 1024 768 8
+     timings 13334 104 24 29 3 136 6
+ endmode
+  
+@@ -691,7 +723,45 @@ mode "1152x864-80"
+     hsync high
+     vsync high
+ endmode
+- 
++
++#
++#       1280x960, 75 Hz, Non-Interlaced (126.00 MHz dotclock)
++#
++#                               Horizontal      Vertical
++#       Resolution              1280            960
++#       Scan Frequency          74.788 kHz      74.788 Hz
++#       Sync Width              1.018 us        0.092 ms
++#                               14 chars        7 lines
++#       Front Porch             0.127 us        0.393 ms
++#                               2 chars         30 lines
++#       Back Porch              1.473 us        0.747 ms
++#                               20 chars        57 lines
++#       Active Time             10.473 us       11.311 ms
++#                               144 chars       864 lines
++#       Blank Time              2.618 us        1.231 ms
++#                               36 chars        94 lines
++#       Polarity                positive        positive
++#
++
++mode "1280x960-75-8"
++    # D: 125.644 MHz, H: 74.788 kHz, V: 74.788 Hz
++    geometry 1280 960 1280 960 8
++    timings 7959 224 32 36 1 144 3
++endmode
++
++mode "1280x960-75"
++    # D: 125.644 MHz, H: 74.788 kHz, V: 74.788 Hz
++    geometry 1280 960 1280 960 16
++    timings 7959 224 32 36 1 144 3
++endmode
++
++mode "1280x960-75-32"
++    # D: 125.644 MHz, H: 74.788 kHz, V: 74.788 Hz
++    geometry 1280 960 1280 960 32
++    timings 7959 224 32 36 1 144 3
++endmode
++
++
+ #
+ #	1280x1024, 43 Hz, Interlaced (80.00 MHz dotclock)
+ #	
+@@ -849,13 +919,13 @@ endmode
+ #
+ 
+ mode "1280x1024-75"
+-    # D: 135.00 MHz, H: 79.976 kHz, V: 75.02 Hz
+-    geometry 1280 1024 1280 1024 8
+-    timings 7408 248 16 38 1 144 3
++    # D: 134.880 MHz, H: 79.905 kHz, V: 74.958 Hz
++    geometry 1280 1024 1280 3264 8
++    timings 7414 232 64 38 1 112 3
+     hsync high
+     vsync high
+ endmode
+- 
++
+ #
+ #	1600x1200, 60 Hz, Non-Interlaced (156.00 MHz dotclock)
+ #	
--- fbset-2.1.orig/debian/patches/10_build.patch
+++ fbset-2.1/debian/patches/10_build.patch
@@ -0,0 +1,95 @@
+Status: sent-upstream
+# Sent part of it, not the indentation fixes, nor the con2fbmap.
+
+Index: b/Makefile
+===================================================================
+--- a/Makefile	1999-01-17 21:15:46.000000000 +0200
++++ b/Makefile	2007-09-16 19:24:49.000000000 +0300
+@@ -2,40 +2,56 @@
+ # Linux Frame Buffer Device Configuration
+ #
+ 
+-CC =		gcc -Wall -O2 -I.
+-BISON =		bison -d
+-FLEX =		flex
+-INSTALL =	install
+-RM =		rm -f
++CC = gcc
++CFLAGS = -Wall -O2
++BISON = bison -d
++FLEX = flex
++INSTALL = install
++INSTALL_PROGRAM = $(INSTALL) -m 755
++INSTALL_DATA = $(INSTALL) -m 644
++RM = rm -f
++
++all: fbset con2fbmap
++
++fbset: fbset.o modes.tab.o lex.yy.o
++
++fbset.o: fbset.c fbset.h fb.h
++modes.tab.o: modes.tab.c fbset.h fb.h
++lex.yy.o: lex.yy.c fbset.h modes.tab.h
+ 
+-All:		fbset
+-
+-
+-fbset:		fbset.o modes.tab.o lex.yy.o
+-
+-fbset.o:	fbset.c fbset.h fb.h
+-modes.tab.o:	modes.tab.c fbset.h fb.h
+-lex.yy.o:	lex.yy.c fbset.h modes.tab.h
+-
+-lex.yy.c:	modes.l
+-		$(FLEX) modes.l
++lex.yy.c: modes.l
++	$(FLEX) modes.l
+ 
+ modes.tab.c:	modes.y
+-		$(BISON) modes.y
++	$(BISON) modes.y
++
++con2fbmap: con2fbmap.o
++con2fbmap.o: con2fbmap.c
+ 
+-install:	fbset
+-		if [ -f /sbin/fbset ]; then rm /sbin/fbset; fi
+-		$(INSTALL) fbset /usr/sbin
+-		$(INSTALL) fbset.8 /usr/man/man8
+-		$(INSTALL) fb.modes.5 /usr/man/man5
+-		if [ ! -c /dev/fb0 ]; then mknod /dev/fb0 c 29 0; fi
+-		if [ ! -c /dev/fb1 ]; then mknod /dev/fb1 c 29 32; fi
+-		if [ ! -c /dev/fb2 ]; then mknod /dev/fb2 c 29 64; fi
+-		if [ ! -c /dev/fb3 ]; then mknod /dev/fb3 c 29 96; fi
+-		if [ ! -c /dev/fb4 ]; then mknod /dev/fb4 c 29 128; fi
+-		if [ ! -c /dev/fb5 ]; then mknod /dev/fb5 c 29 160; fi
+-		if [ ! -c /dev/fb6 ]; then mknod /dev/fb6 c 29 192; fi
+-		if [ ! -c /dev/fb7 ]; then mknod /dev/fb7 c 29 224; fi
++install: fbset
++	$(INSTALL) -d $(DESTDIR)/etc
++	$(INSTALL) -d $(DESTDIR)/bin
++	$(INSTALL) -d $(DESTDIR)/usr/share/man/man1
++	$(INSTALL) -d $(DESTDIR)/usr/share/man/man5
++	$(INSTALL_DATA) etc/fb.modes.ATI $(DESTDIR)/etc/fb.modes
++	$(INSTALL_DATA) fb.modes.5 $(DESTDIR)/usr/share/man/man5
++	$(INSTALL_PROGRAM) fbset $(DESTDIR)/bin
++	$(INSTALL_DATA) fbset.8 $(DESTDIR)/usr/share/man/man1/fbset.1
++	$(INSTALL_PROGRAM) modeline2fb $(DESTDIR)/bin
++	$(INSTALL_DATA) modeline2fb.1 $(DESTDIR)/usr/share/man/man1
++	$(INSTALL_PROGRAM) con2fbmap $(DESTDIR)/bin
++	$(INSTALL_DATA) con2fbmap.1 $(DESTDIR)/usr/share/man/man1
++
++install-devices:
++	if [ ! -c /dev/fb0 ]; then mknod $(DESTDIR)/dev/fb0 c 29 0; fi
++	if [ ! -c /dev/fb1 ]; then mknod $(DESTDIR)/dev/fb1 c 29 32; fi
++	if [ ! -c /dev/fb2 ]; then mknod $(DESTDIR)/dev/fb2 c 29 64; fi
++	if [ ! -c /dev/fb3 ]; then mknod $(DESTDIR)/dev/fb3 c 29 96; fi
++	if [ ! -c /dev/fb4 ]; then mknod $(DESTDIR)/dev/fb4 c 29 128; fi
++	if [ ! -c /dev/fb5 ]; then mknod $(DESTDIR)/dev/fb5 c 29 160; fi
++	if [ ! -c /dev/fb6 ]; then mknod $(DESTDIR)/dev/fb6 c 29 192; fi
++	if [ ! -c /dev/fb7 ]; then mknod $(DESTDIR)/dev/fb7 c 29 224; fi
+ 
+ clean:
+-		$(RM) *.o fbset lex.yy.c modes.tab.c modes.tab.h
++	$(RM) *.o fbset con2fbmap lex.yy.c modes.tab.c modes.tab.h
++
--- fbset-2.1.orig/debian/patches/series
+++ fbset-2.1/debian/patches/series
@@ -0,0 +1,10 @@
+01_kernel_fb.h.patch 
+02_fb_modes.patch 
+03_con2fbmap.patch 
+04_fbset_warnings.patch 
+05_fbset_devfs.patch 
+06_fbset_usage.patch 
+07_new_accels.patch 
+08_rgba_keyword.patch 
+10_build.patch 
+11_manpages.patch 
--- fbset-2.1.orig/debian/patches/07_new_accels.patch
+++ fbset-2.1/debian/patches/07_new_accels.patch
@@ -0,0 +1,59 @@
+Status: sent-upstream
+
+Index: b/fbset.c
+===================================================================
+--- a/fbset.c	2007-09-16 19:06:11.000000000 +0300
++++ b/fbset.c	2007-09-16 19:06:19.000000000 +0300
+@@ -200,6 +200,52 @@ static struct accelentry {
+     { FB_ACCEL_SUN_CGTHREE, "Sun cg3" },
+     { FB_ACCEL_SUN_TCX, "Sun tcx" },
+     { FB_ACCEL_MATROX_MGAG400, "Matrox G400" },
++    { FB_ACCEL_NV3, "nVidia RIVA 128" },
++    { FB_ACCEL_NV4, "nVidia RIVA TNT" },
++    { FB_ACCEL_NV5, "nVidia RIVA TNT2" },
++    { FB_ACCEL_CT_6555x, "C&T 6555x" },
++    { FB_ACCEL_3DFX_BANSHEE, "3Dfx Banshee" },
++    { FB_ACCEL_ATI_RAGE128, "ATI Rage128 family" },
++    { FB_ACCEL_ATI_RADEON, "ATI Radeon family" },
++    { FB_ACCEL_IGS_CYBER2000, "CyberPro 2000" },
++    { FB_ACCEL_IGS_CYBER2010, "CyberPro 2010" },
++    { FB_ACCEL_IGS_CYBER5000, "CyberPro 5000" },
++    { FB_ACCEL_SIS_GLAMOUR, "SiS 300/630/540" },
++    { FB_ACCEL_SIS_GLAMOUR_2, "SiS 315/650/740" },
++    { FB_ACCEL_SIS_XABRE, "SiS 330 (Xabre)" },
++    { FB_ACCEL_3DLABS_PERMEDIA3, "3Dlabs Permedia 3" },
++    { FB_ACCEL_I810, "Intel 810/815" },
++    { FB_ACCEL_I830, "Intel 830M/845G/85x/865G" },
++    { FB_ACCEL_NEOMAGIC_NM2070, "NeoMagic NM2070" },
++    { FB_ACCEL_NEOMAGIC_NM2090, "NeoMagic NM2090" },
++    { FB_ACCEL_NEOMAGIC_NM2093, "NeoMagic NM2093" },
++    { FB_ACCEL_NEOMAGIC_NM2097, "NeoMagic NM2097" },
++    { FB_ACCEL_NEOMAGIC_NM2160, "NeoMagic NM2160" },
++    { FB_ACCEL_NEOMAGIC_NM2200, "NeoMagic NM2200" },
++    { FB_ACCEL_NEOMAGIC_NM2230, "NeoMagic NM2230" },
++    { FB_ACCEL_NEOMAGIC_NM2360, "NeoMagic NM2360" },
++    { FB_ACCEL_NEOMAGIC_NM2380, "NeoMagic NM2380" },
++    { FB_ACCEL_SAVAGE4, "S3 Savage4" },
++    { FB_ACCEL_SAVAGE3D, "S3 Savage3D" },
++    { FB_ACCEL_SAVAGE3D_MV, "S3 Savage3D-MV" },
++    { FB_ACCEL_SAVAGE2000, "S3 Savage2000" },
++    { FB_ACCEL_SAVAGE_MX_MV, "S3 Savage/MX-MV" },
++    { FB_ACCEL_SAVAGE_MX, "S3 Savage/MX" },
++    { FB_ACCEL_SAVAGE_IX_MV, "S3 Savage/IX-MV" },
++    { FB_ACCEL_SAVAGE_IX, "S3 Savage/IX" },
++    { FB_ACCEL_PROSAVAGE_PM, "S3 ProSavage PM133" },
++    { FB_ACCEL_PROSAVAGE_KM, "S3 ProSavage KM133" },
++    { FB_ACCEL_S3TWISTER_P, "S3 Twister" },
++    { FB_ACCEL_S3TWISTER_K, "S3 TwisterK" },
++    { FB_ACCEL_SUPERSAVAGE, "S3 Supersavage" },
++    { FB_ACCEL_PROSAVAGE_DDR, "S3 ProSavage DDR" },
++    { FB_ACCEL_PROSAVAGE_DDRK, "S3 ProSavage DDR-K" },
++    { FB_ACCEL_NV_10, "nVidia Arch 10" },
++    { FB_ACCEL_NV_20, "nVidia Arch 20" },
++    { FB_ACCEL_NV_30, "nVidia Arch 30" },
++    { FB_ACCEL_NV_40, "nVidia Arch 40" },
++    { FB_ACCEL_XGI_VOLARI_V, "XGI Volari V3XT, V5, V8" },
++    { FB_ACCEL_XGI_VOLARI_Z, "XGI Volari Z7" },
+ };
+ 
+ 
--- fbset-2.1.orig/debian/patches/03_con2fbmap.patch
+++ fbset-2.1/debian/patches/03_con2fbmap.patch
@@ -0,0 +1,109 @@
+Status: not-sent
+# This supposedly does not need to be sent upstream as there's fbutils,
+# although its development has stagnated.
+
+Index: b/con2fbmap.1
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ b/con2fbmap.1	2007-09-16 19:06:04.000000000 +0300
+@@ -0,0 +1,29 @@
++.TH con2fbmap 1 2006-01-18 2.1 "Linux frame buffer utils"
++.SH NAME
++con2fbmap \- shows and sets mapping between consoles and framebuffer devices.
++.SH SYNOPSIS
++.B con2fbmap
++.RI console
++.RI [ framebuffer ]
++.SH DESCRIPTION
++.B This documentation is not finished
++.PP
++.B con2fbmap
++is a system utility to show or change the mapping of the consoles  to the
++frame buffer device. The frame buffer device provides a simple and unique
++interface to access different kinds of graphic displays.
++.PP
++Frame buffer devices are accessed via special device nodes located in the
++/dev directory. The naming scheme for these nodes is always
++.IR \fBfb < n >,
++where
++.I n
++is the number of the used frame buffer device.
++.PP
++.SH OPTIONS
++The first option must be there, and identify the console on which to work.
++If the second option is not set, con2fbmap shows the current mapping of
++identified console. If the second argument is given (as a number) con2fbmap
++maps the identified console to said framebuffer device.
++.TP
++Sven LUTHER <luther@debian.org>
+Index: b/con2fbmap.c
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ b/con2fbmap.c	2007-09-16 19:06:04.000000000 +0300
+@@ -0,0 +1,66 @@
++#include <stdio.h>
++#include <stdlib.h>
++#include <unistd.h>
++#include <fcntl.h>
++#include <errno.h>
++#include <string.h>
++#include <sys/ioctl.h>
++#include <sys/types.h>
++#include <sys/stat.h>
++#include <linux/fb.h>
++
++#define DEFAULT_FRAMEBUFFER	"/dev/fb0"
++#define DEFAULT_FRAMEBUFFER_DEVFS	"/dev/fb/0"
++
++const char *programname;
++
++void Usage(void)
++{
++    fprintf(stderr, "\nUsage: %s console [framebuffer]\n\n", programname);
++    exit(1);
++}
++
++int main(int argc, char *argv[])
++{
++    int do_write = 0;
++    char *fbpath; /* any frame buffer will do */
++    int fd;
++    struct fb_con2fbmap map;
++
++    programname = argv[0];
++    switch (argc) {
++	case 3:
++	    do_write = 1;
++	    map.framebuffer = atoi(argv[2]);
++	case 2:
++	    map.console = atoi(argv[1]);
++	    break;
++	default:
++	    Usage();
++    }
++
++    if (access("/dev/.devfsd", F_OK) == 0)  /* devfs detected */
++	fbpath = DEFAULT_FRAMEBUFFER_DEVFS;
++    else
++	fbpath = DEFAULT_FRAMEBUFFER;
++
++    if ((fd = open(fbpath, O_RDONLY)) == -1) {
++	fprintf(stderr, "open %s: %s\n", fbpath, strerror(errno));
++	exit(1);
++    }
++    if (do_write) {
++	if (ioctl(fd, FBIOPUT_CON2FBMAP, &map)) {
++	    fprintf(stderr, "ioctl FBIOPUT_CON2FBMAP: %s\n", strerror(errno));
++	    exit(1);
++	}
++    } else {
++	if (ioctl(fd, FBIOGET_CON2FBMAP, &map)) {
++	    fprintf(stderr, "ioctl FBIOGET_CON2FBMAP: %s\n", strerror(errno));
++	    exit(1);
++	}
++	printf("console %d is mapped to framebuffer %d\n", map.console,
++	       map.framebuffer);
++    }
++    close(fd);
++    exit(0);
++}
--- fbset-2.1.orig/debian/patches/11_manpages.patch
+++ fbset-2.1/debian/patches/11_manpages.patch
@@ -0,0 +1,244 @@
+Status: sent-upstream
+
+Index: b/fb.modes.5
+===================================================================
+--- a/fb.modes.5	2007-09-16 19:05:32.000000000 +0300
++++ b/fb.modes.5	2007-09-16 19:06:27.000000000 +0300
+@@ -1,4 +1,4 @@
+-.TH fb.modes 8 "Aug 1996" local "Linux frame buffer utils"
++.TH fb.modes 5 2003-08-07 2.1 "Linux frame buffer utils"
+ .SH NAME
+ fb.modes \- frame buffer modes file
+ .SH DESCRIPTION
+@@ -27,6 +27,9 @@ timings
+ .br
+ .B options
+ .RI < value >
++.br
++.B rgba
++.RI < red , green , blue , alpha >
+ .RE
+ endmode
+ .SH OPTIONS
+@@ -74,6 +77,22 @@ horizontal sync length (in pixels)
+ vertical sync length (in pixel lines)
+ .RE
+ .PP
++rgba options (only valid with truecolor):
++.RS
++.TP
++.I red
++red color bitfields (in length or length/offset)
++.TP
++.I green
++green color bitfields (in length or length/offset)
++.TP
++.I blue
++blue color bitfields (in length or length/offset)
++.TP
++.I alpha
++alpha color bitfields (in length or length/offset)
++.RE
++.PP
+ other options:
+ .RS
+ the first value of this options is the default
+@@ -87,6 +106,14 @@ the vertical sync polarity
+ .IR \fBcsync "\ {" low | high }
+ the composite sync polarity
+ .TP
++.IR \fBgsync "\ {" low | high }
++the sync on green polarity
++.TP
++.IR \fBbcast "\ {" false | true }
++enable or disable broadcast modes. If enabled the frame buffer generates
++the exact timings fot several broadcast modes (e.g. PAL or NTSC). Note that
++this option may not be supported by every frame buffer
++.TP
+ .IR \fBextsync "\ {" false | true }
+ enable or disable external resync. If enabled the sync timings are not
+ generated by the frame buffer device and must be provided externally
+@@ -106,6 +133,15 @@ and this way the horizontal frequency ca
+ same resolution can be displayed on different monitors, even if the
+ horizontal frequency specification differs. Note that this option may not be
+ supported by every frame buffer device
++.TP
++.IR \fBnostd "\ <" number >
++select nonstandard video mode
++.TP
++.IR \fBaccel "\ {" false | true }
++enable or disable hardware text acceleration
++.TP
++.IR \fBgrayscale "\ {" false | true }
++enable or disable graylevels instead of colors
+ .RE
+ .SH INTERNALS
+ Generally a frame buffer display is organized as follows:
+Index: b/fbset.8
+===================================================================
+--- a/fbset.8	2007-09-16 19:05:32.000000000 +0300
++++ b/fbset.8	2007-09-16 19:06:27.000000000 +0300
+@@ -1,4 +1,4 @@
+-.TH fbset 8 "July 1998" local "Linux frame buffer utils"
++.TH fbset 1 2006-01-18 2.1 "Linux frame buffer utils"
+ .SH NAME
+ fbset \- show and modify frame buffer device settings
+ .SH SYNOPSIS
+@@ -6,8 +6,6 @@ fbset \- show and modify frame buffer de
+ .RI [ options ]
+ .RI [ mode ]
+ .SH DESCRIPTION
+-.B This documentation is out of date!!
+-.PP
+ .B fbset
+ is a system utility to show or change the settings of the frame buffer
+ device. The frame buffer device provides a simple and unique interface to
+@@ -15,6 +13,8 @@ access different kinds of graphic displa
+ .PP
+ Frame buffer devices are accessed via special device nodes located in the
+ /dev directory. The naming scheme for these nodes is always
++.IR \fBfb/ < n >
++or
+ .IR \fBfb < n >,
+ where
+ .I n
+@@ -36,10 +36,8 @@ General options:
+ .BR \-\-help ",\ " \-h
+ display an usage information
+ .TP
+-.BR \-\-now ",\ " \-n
+-change the video mode immediately. If no frame buffer device is given via
+-.B \-fb
+-, then this option is activated by default
++.BR \-\-test
++don't change, just test whether the mode is valid
+ .TP
+ .BR \-\-show ",\ " \-s
+ display the video mode settings. This is default if no further option or
+@@ -66,14 +64,18 @@ display the timing information as it's n
+ Frame buffer device nodes:
+ .RS
+ .TP
++.BR \-\-all ",\ "  \-a
++change all virtual consoles on this device
++.TP
+ .BR \-fb "\ <" \fIdevice >
+ .I device
+ gives the frame buffer device node. If no device via
+ .B \-fb
+ is given, 
++.I /dev/fb/0
++or
+ .I /dev/fb0
+ is used
+-.TP
+ .RE
+ .PP
+ Video mode database:
+@@ -86,6 +88,13 @@ see also
+ .BR fb.modes (5)
+ .RE
+ .PP
++Display bitfield colors:
++.RS
++.TP
++.BR \-rgba "\ <" \fIred , \fIgreen , \fIblue , \fIalpha >
++each in length or length/offset color format
++.RE
++.PP
+ Display geometry:
+ .RS
+ .TP
+@@ -104,6 +113,10 @@ set virtual vertical resolution (in pixe
+ .BR \-depth "\ <" \fIvalue >
+ set display depth (in bits per pixel)
+ .TP
++.TP
++.BR \-nonstd "\ <" \fIvalue >
++select nonstandard video mode
++.TP
+ .BR \-\-geometry ",\ " \-g "\ ..."
+ set all geometry parameters at once in the order
+ .RI < xres >
+@@ -154,13 +167,16 @@ set all timing parameters at once in the
+ .RI < hslen >
+ .RI < vslen >,
+ e.g.
+-.B \-g
++.B \-t
+ .I 35242 64 96 35 12 112 2
+ .RE
+ .PP
+ Display flags:
+ .RS
+ .TP
++.IR \fB\-accel "\ {" false | true }
++set hardware text acceleration enable
++.TP
+ .IR \fB\-hsync "\ {" low | high }
+ set the horizontal sync polarity
+ .TP
+@@ -170,6 +186,9 @@ set the vertical sync polarity
+ .IR \fB\-csync "\ {" low | high }
+ set the composite sync polarity
+ .TP
++.IR \fB\-gsync "\ {" false | true }
++set synch on green
++.TP
+ .IR \fB\-extsync "\ {" false | true }
+ enable or disable external resync. If enabled the sync timings are not
+ generated by the frame buffer device and must be provided externally
+@@ -232,7 +251,7 @@ and make the used frame buffer device kn
+ .br
+ .I /etc/fb.modes
+ .SH SEE ALSO
+-.BR fb.modes "(5), " fbdev (4)
++.BR fb.modes "(5), " fbdev "(4), " /usr/share/doc/fbset/FAQ
+ .SH AUTHORS
+ .TP
+ Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
+Index: b/modeline2fb.1
+===================================================================
+--- /dev/null	1970-01-01 00:00:00.000000000 +0000
++++ b/modeline2fb.1	2007-09-16 19:06:27.000000000 +0300
+@@ -0,0 +1,40 @@
++.TH modeline2fb 1 2006-01-18 2.1 "Linux frame buffer utils"
++.SH NAME
++modeline2fb \- simple modeline to fb.modes translator
++.SH SYNOPSIS
++.B modeline2fb
++[\fIOPTION\fR] [\fIFILES\fR]
++.SH DESCRIPTION
++.PP
++.I Modeline2fb
++is a simple Perl script that converts XF86Config-style modelines to options
++suitable for a fb.modes file.
++.PP
++Note that only one option can be successfully enabled at any particular time.
++.SH OPTIONS
++.TP
++\fB\-d\fR, \fB\-\-depth\fR \fIdepth\fR
++Use the given display depth (default is 8).
++.TP
++\fB\-h\fR \fB\-\-help\fR
++Print out a help screen and exit.
++.SH ADVANCED OPTIONS
++.TP
++\fB\-r\fR \fB\-\-rounding\fR \fIdiv\fR
++Sets the vxres divisor (default is 128).
++.TP
++\fB\-x\fR \fB\-\-vxres\fR \fIX,X,X,...\fR
++Sets extra vxres values.
++.PP
++[\fIFILES\fR] refers to one or more XF86Config files.  Note that all modelines 
++must be in single-line format.  If no files are given on the command line, 
++this program reads from standard in.  This program will also write to
++standard out.
++.SH EXAMPLE 
++modeline2fb \-d 16 /etc/X11/XF86Config
++.SH "SEE ALSO"
++.BR fb.modes(5), 
++.BR XF86Config(5)
++.SH AUTHOR
++This manual page is a quick write-up for Debian done by Kevin Kreamer 
++<kkreamer@etherhogz.org>.
--- fbset-2.1.orig/debian/patches/04_fbset_warnings.patch
+++ fbset-2.1/debian/patches/04_fbset_warnings.patch
@@ -0,0 +1,24 @@
+Status: sent-upstream
+
+Index: b/fbset.c
+===================================================================
+--- a/fbset.c	2007-09-16 19:05:34.000000000 +0300
++++ b/fbset.c	2007-09-16 19:06:06.000000000 +0300
+@@ -710,7 +710,7 @@ static void DisplayFBInfo(struct fb_fix_
+ 
+     puts("Frame buffer device information:");
+     printf("    Name        : %s\n", fix->id);
+-    printf("    Address     : %p\n", fix->smem_start);
++    printf("    Address     : %#0lx\n", fix->smem_start);
+     printf("    Size        : %d\n", fix->smem_len);
+     printf("    Type        : ");
+     switch (fix->type) {
+@@ -780,7 +780,7 @@ static void DisplayFBInfo(struct fb_fix_
+     printf("    YWrapStep   : %d\n", fix->ywrapstep);
+     printf("    LineLength  : %d\n", fix->line_length);
+     if (fix->mmio_len) {
+-	printf("    MMIO Address: %p\n", fix->mmio_start);
++	printf("    MMIO Address: %#0lx\n", fix->mmio_start);
+ 	printf("    MMIO Size   : %d\n", fix->mmio_len);
+     }
+     printf("    Accelerator : ");
--- fbset-2.1.orig/debian/fbset.postinst
+++ fbset-2.1/debian/fbset.postinst
@@ -0,0 +1,23 @@
+#!/bin/sh
+#
+# Post-Installation script
+
+set -e
+
+case "$1" in
+configure)
+  # Create framebuffer devices if they don't exist,
+  # and we are not using stuff like udev.
+
+  if [ ! -c /dev/fb0 ] && [ -e /dev/MAKEDEV ] ; then
+    # Not being able to create the device files should not be fatal.
+    cd /dev
+    ./MAKEDEV fb || true
+  fi
+  ;;
+esac
+
+#DEBHELPER#
+
+exit 0
+
--- fbset-2.1.orig/debian/fbset.docs
+++ fbset-2.1/debian/fbset.docs
@@ -0,0 +1,2 @@
+debian/doc/*
+GetVideoMode.c
--- fbset-2.1.orig/debian/modes/fb.modes.ATI+LG
+++ fbset-2.1/debian/modes/fb.modes.ATI+LG
@@ -0,0 +1,17 @@
++# Sun A21 (ATI Mach64) with LG Studioworks 775N
++mode "640x480-89"
++    # D: 37.182 MHz, H: 46.477 kHz, V: 88.528 Hz
++    geometry 640 480 640 6502 8
++    timings 26895 31 33 33 10 96 2
++    accel true
++    rgba 8/0,8/0,8/0,0/0
++endmode
++
++# Sun A21 (ATI Mach64) with LG Studioworks 775N
++mode "640x400-85"
++    # D: 31.50 MHz, H: 37.86 kHz, V: 85.08 Hz
++    geometry 640 400 640 6515 8
++    timings 31746 96 32 41 1 64 3
++    vsync high
++    accel true
++endmode
--- fbset-2.1.orig/debian/modes/fb.modes.CyBla
+++ fbset-2.1/debian/modes/fb.modes.CyBla
@@ -0,0 +1,154 @@
+#
+#   Sample fb.modes file
+#
+#	Provides an incomplete list of working modes for
+#	the cyberblade/i1 graphics core.
+#
+#	The value 4294967256 is used instead of -40. Of course, -40 is not
+#	a really reasonable value, but chip design does not always follow
+#	logic. Believe me, it's ok, and it's the way the BIOS does it.
+#
+#	fbset requires 4294967256 in fb.modes and -40 as an argument to
+#	the -t parameter. That's also not too reasonable, and it might change
+#	in the future or might even be differt for your current version.
+#
+
+mode "640x480-50"
+    geometry 640 480 2048 4096 8
+    timings 47619 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-60"
+    geometry 640 480 2048 4096 8
+    timings 39682 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-70"
+    geometry 640 480 2048 4096 8
+    timings 34013 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-72"
+    geometry 640 480 2048 4096 8
+    timings 33068 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-75"
+    geometry 640 480 2048 4096 8
+    timings 31746 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-80"
+    geometry 640 480 2048 4096 8
+    timings 29761 4294967256 24 17 0 216 3
+endmode
+
+mode "640x480-85"
+    geometry 640 480 2048 4096 8
+    timings 28011 4294967256 24 17 0 216 3
+endmode
+
+mode "800x600-50"
+    geometry 800 600 2048 4096 8
+    timings 30303 96 24 14 0 136 11
+endmode
+
+mode "800x600-60"
+    geometry 800 600 2048 4096 8
+    timings 25252 96 24 14 0 136 11
+endmode
+
+mode "800x600-70"
+    geometry 800 600 2048 4096 8
+    timings 21645 96 24 14 0 136 11
+endmode
+
+mode "800x600-72"
+    geometry 800 600 2048 4096 8
+    timings 21043 96 24 14 0 136 11
+endmode
+
+mode "800x600-75"
+    geometry 800 600 2048 4096 8
+    timings 20202 96 24 14 0 136 11
+endmode
+
+mode "800x600-80"
+    geometry 800 600 2048 4096 8
+    timings 18939 96 24 14 0 136 11
+endmode
+
+mode "800x600-85"
+    geometry 800 600 2048 4096 8
+    timings 17825 96 24 14 0 136 11
+endmode
+
+mode "1024x768-50"
+    geometry 1024 768 2048 4096 8
+    timings 19054 144 24 29 0 120 3
+endmode
+
+mode "1024x768-60"
+    geometry 1024 768 2048 4096 8
+    timings 15880 144 24 29 0 120 3
+endmode
+
+mode "1024x768-70"
+    geometry 1024 768 2048 4096 8
+    timings 13610 144 24 29 0 120 3
+endmode
+
+mode "1024x768-72"
+    geometry 1024 768 2048 4096 8
+    timings 13232 144 24 29 0 120 3
+endmode
+
+mode "1024x768-75"
+    geometry 1024 768 2048 4096 8
+    timings 12703 144 24 29 0 120 3
+endmode
+
+mode "1024x768-80"
+    geometry 1024 768 2048 4096 8
+    timings 11910 144 24 29 0 120 3
+endmode
+
+mode "1024x768-85"
+    geometry 1024 768 2048 4096 8
+    timings 11209 144 24 29 0 120 3
+endmode
+
+mode "1280x1024-50"
+    geometry 1280 1024 2048 4096 8
+    timings 11114 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-60"
+    geometry 1280 1024 2048 4096 8
+    timings 9262 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-70"
+    geometry 1280 1024 2048 4096 8
+    timings 7939 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-72"
+    geometry 1280 1024 2048 4096 8
+    timings 7719 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-75"
+    geometry 1280 1024 2048 4096 8
+    timings 7410 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-80"
+    geometry 1280 1024 2048 4096 8
+    timings 6946 232 16 39 0 160 3
+endmode
+
+mode "1280x1024-85"
+    geometry 1280 1024 2048 4096 8
+    timings 6538 232 16 39 0 160 3
+endmode
--- fbset-2.1.orig/debian/modes/fb.modes.ATI+Samsung
+++ fbset-2.1/debian/modes/fb.modes.ATI+Samsung
@@ -0,0 +1,30 @@
++# Sun A21 (ATI Mach64) with Sun 365-1396 (Samsung CHB7727L)
++mode "1152x900-76"
++    # D: 107.158 MHz, H: 71.249 kHz, V: 75.555 Hz
++    geometry 1152 900 1152 3612 8
++    timings 9332 174 50 33 2 128 8
++    hsync high
++    csync high
++    accel true
++    rgba 8/0,8/0,8/0,0/0
++endmode
++
++# Sun A21 (ATI Mach64) with Sun 365-1396 (Samsung CHB7727L)
++mode "640x480-85"
++    # D: 36.00 MHz, H: 43.27 kHz, V: 85.01 Hz
++    geometry 640 480 640 480 8
++    timings 27777 80 56 25 1 56 3
++    hsync high
++    csync high
++    accel true
++endmode
++
++# Sun A21 (ATI Mach64) with Sun 365-1396 (Samsung CHB7727L)
++mode "640x400-85"
++    # D: 31.50 MHz, H: 37.86 kHz, V: 85.08 Hz
++    geometry 640 400 640 6540 8
++    timings 31746 96 32 41 1 64 3
++    hsync high
++    csync high
++    accel true
++endmode
--- fbset-2.1.orig/debian/rules
+++ fbset-2.1/debian/rules
@@ -0,0 +1,96 @@
+#!/usr/bin/make -f
+# Sample debian/rules that uses debhelper.
+# This file is public domain software, originally written by Joey Hess. 
+
+# Uncomment this to turn on verbose mode.
+#export DH_VERBOSE=1
+
+CFLAGS = -Wall -g
+UDEB_CFLAGS = -Wall -g
+
+ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
+	CFLAGS += -O0
+	UDEB_CFLAGS += -O0
+else
+	CFLAGS += -O2
+	UDEB_CFLAGS += -Os -fomit-frame-pointer
+endif
+
+PACKAGE = fbset
+UDEB_PACKAGE = $(PACKAGE)-udeb
+
+include /usr/share/quilt/quilt.make
+
+build: build-stamp
+build-stamp: patch
+	dh_testdir
+	
+	rm -f build-stamp*
+	$(MAKE) clean
+	$(MAKE) CFLAGS="$(CFLAGS)"
+	
+	touch $@
+
+build-udeb: build-stamp-udeb
+build-stamp-udeb: patch
+	dh_testdir
+	
+	rm -f build-stamp*
+	$(MAKE) clean
+	$(MAKE) CFLAGS="$(UDEB_CFLAGS)"
+	
+	touch $@
+
+clean: unpatch
+	dh_testdir
+	dh_testroot
+	rm -f build-stamp*
+	
+	$(MAKE) clean
+	
+	# FIXME: this can be removed once and if con2fbmap is merged upstream
+	rm -f con2fbmap
+	
+	dh_clean
+
+install: build
+	dh_testdir
+	dh_testroot
+	dh_clean -k -p$(PACKAGE)
+	dh_installdirs
+	
+	$(MAKE) install DESTDIR=$(CURDIR)/debian/$(PACKAGE)
+
+install-udeb: build-udeb
+	dh_testdir
+	dh_testroot
+	dh_clean -k -p$(UDEB_PACKAGE)
+	dh_installdirs
+	
+	$(MAKE) install DESTDIR=$(CURDIR)/debian/$(UDEB_PACKAGE)
+	rm -rf $(CURDIR)/debian/$(UDEB_PACKAGE)/usr
+
+binary-indep:
+# Nothing to do.
+
+binary-arch: install install-udeb
+	dh_testdir
+	dh_testroot
+	dh_installdocs -a
+	dh_installexamples -a
+	dh_installman -a
+	dh_installchangelogs -a
+	dh_link -a
+	dh_strip -a
+	dh_compress -a
+	dh_fixperms -a
+	dh_installdeb -a
+	dh_shlibdeps -a
+	dh_gencontrol -a
+	dh_md5sums -a
+	dh_builddeb -a
+
+binary: binary-indep binary-arch
+
+.PHONY: build build-udeb clean binary-indep binary-arch binary install
+