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