summaryrefslogtreecommitdiffstats
path: root/Documentation/fb/cyblafb
diff options
context:
space:
mode:
authorKrzysztof Helt <krzysztof.h1@wp.pl>2009-03-31 15:25:40 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2009-04-01 08:59:33 -0700
commitddb53d48da5b0e691f35e703ac29118747f86c99 (patch)
treebdf0f4a6f3e74a87e5b2ccb9530f708eed6258d2 /Documentation/fb/cyblafb
parentec549a0fdc32171b26677f1ef0b5309faa743362 (diff)
fbdev: remove cyblafb driver
A tridentfb driver has all the functionality of the cyblafb driver without the bugs of the latter. Changes to the tridentfb driver: - FBINFO_READS_FAST added to the tridentfb. The cyblafb used a blitter for scrolling which is faster than color expansion on Cyberblade chipsets. The blitter is slower on a discrete Blade3D core. Use the blitter for scrolling in the tridentfb only for integrated Blade3D cores. Now, scrolling speed is about equal for the tridentfb and the cyblafb. - a copyright notice addition is done on request of Jani Monoses (the first author of the tridentfb). Tested on AGP Blade3D card and PCChips M787CLR motherboard: VIA C3 cpu + VT8601 north bridge (aka Cyberblade/i1). Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl> Cc: "Jani Monoses" <jani@ubuntu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/fb/cyblafb')
-rw-r--r--Documentation/fb/cyblafb/bugs13
-rw-r--r--Documentation/fb/cyblafb/credits7
-rw-r--r--Documentation/fb/cyblafb/documentation17
-rw-r--r--Documentation/fb/cyblafb/fb.modes154
-rw-r--r--Documentation/fb/cyblafb/performance79
-rw-r--r--Documentation/fb/cyblafb/todo31
-rw-r--r--Documentation/fb/cyblafb/usage217
-rw-r--r--Documentation/fb/cyblafb/whatsnew29
-rw-r--r--Documentation/fb/cyblafb/whycyblafb85
9 files changed, 0 insertions, 632 deletions
diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs
deleted file mode 100644
index 9443a6d72cd..00000000000
--- a/Documentation/fb/cyblafb/bugs
+++ /dev/null
@@ -1,13 +0,0 @@
-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.
diff --git a/Documentation/fb/cyblafb/credits b/Documentation/fb/cyblafb/credits
deleted file mode 100644
index 0eb3b443dc2..00000000000
--- a/Documentation/fb/cyblafb/credits
+++ /dev/null
@@ -1,7 +0,0 @@
-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
diff --git a/Documentation/fb/cyblafb/documentation b/Documentation/fb/cyblafb/documentation
deleted file mode 100644
index bb1aac04842..00000000000
--- a/Documentation/fb/cyblafb/documentation
+++ /dev/null
@@ -1,17 +0,0 @@
-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.
-
diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes
deleted file mode 100644
index fe0e5223ba8..00000000000
--- a/Documentation/fb/cyblafb/fb.modes
+++ /dev/null
@@ -1,154 +0,0 @@
-#
-# 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
diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance
deleted file mode 100644
index 8d15d5dfc6b..00000000000
--- a/Documentation/fb/cyblafb/performance
+++ /dev/null
@@ -1,79 +0,0 @@
-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 | | | |
-| | | | |
-| | | | |
-| | | | |
-+-----------+-----------------+-----------------+-----------------+
diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo
deleted file mode 100644
index c5f6d0eae54..00000000000
--- a/Documentation/fb/cyblafb/todo
+++ /dev/null
@@ -1,31 +0,0 @@
-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
diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage
deleted file mode 100644
index a39bb3d402a..00000000000
--- a/Documentation/fb/cyblafb/usage
+++ /dev/null
@@ -1,217 +0,0 @@
-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
diff --git a/Documentation/fb/cyblafb/whatsnew b/Documentation/fb/cyblafb/whatsnew
deleted file mode 100644
index 76c07a26e04..00000000000
--- a/Documentation/fb/cyblafb/whatsnew
+++ /dev/null
@@ -1,29 +0,0 @@
-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.
diff --git a/Documentation/fb/cyblafb/whycyblafb b/Documentation/fb/cyblafb/whycyblafb
deleted file mode 100644
index a123bc11e69..00000000000
--- a/Documentation/fb/cyblafb/whycyblafb
+++ /dev/null
@@ -1,85 +0,0 @@
-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
-