86 lines
3.4 KiB
Plaintext
86 lines
3.4 KiB
Plaintext
|
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
|
||
|
|