aboutsummaryrefslogtreecommitdiff
path: root/Documentation/fb/cyblafb/whycyblafb
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/whycyblafb
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/whycyblafb')
-rw-r--r--Documentation/fb/cyblafb/whycyblafb85
1 files changed, 0 insertions, 85 deletions
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
-