OpenCloudOS-Kernel/Documentation/fb/cyblafb/whycyblafb

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