| 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 | |