xenocara/driver/xf86-video-voodoo
2008-03-15 18:08:24 +00:00
..
man regen with automake 1.9.6p2 2007-03-18 22:41:20 +00:00
src regen with automake 1.9.6p2 2007-03-18 22:41:20 +00:00
aclocal.m4 Regen with autoconf 2.59-p2, with AM_SANITY check zapped. 2008-03-15 18:08:24 +00:00
ChangeLog Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
config.guess regenerate with OpenBSD autotools 2006-11-27 14:55:05 +00:00
config.h.in regen 2007-03-16 01:32:18 +00:00
config.sub regenerate with OpenBSD autotools 2006-11-27 14:55:05 +00:00
configure Regen with autoconf 2.59-p2, with AM_SANITY check zapped. 2008-03-15 18:08:24 +00:00
configure.ac Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
COPYING Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
depcomp Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
install-sh Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
ltmain.sh regen 2007-07-29 10:27:00 +00:00
Makefile.am Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
Makefile.bsd-wrapper $Xenocara$ -> $OpenBSD$ 2006-11-27 19:27:25 +00:00
Makefile.in regen with automake 1.9.6p2 2007-03-18 22:41:20 +00:00
missing Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
README Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00
TODO Importing xf86-video-voodoo 1.1.1 2006-11-26 20:21:27 +00:00

Quick Voodoo/Voodoo2 Crash Course (mostly Alan's notes to save looking
stuff up in the docs all the time)

Voodoo and Voodoo 2 appear as multimedia devices. They may be on a "dual
function" board in which case we should not 'borrow' the Voodoo as we will
blank the main video card. That is reported in the PCI config space.
Voodoo/Voodoo2 hardware may not always be initialized by the host OS because
it is not video.

The voodoo memory is split into two pools. A 1-4Mb pool holds the frame
buffer, an optional second buffer, zbuffers, and alpha. A second 2-8Mb 
memory area holds all the textures.

Texture ram is directly writable but not important for the current 2D
driver. Video RAM is 16bit depth and tiled. The view of the video memory 
area is "magic", it doesn't contain a mapping of the video RAM into PCI
space but contains pixel poking functionality.

The frame buffer always appears untiled and 1024 pixels wide. For write
there are some 16 different write modes including 24/32bit. The hardware
does not support 24/32bit - these are provided for software rendering
fallback. Read back is always 16bit. Endian conversion is hardware. Byte
aligned access is not supported, only word aligned. Also watch how you
access data - you can't access out of frame buffer space and if you get
the control bits wrong you also get zbuffered, fogged and other fun.
LFB writes have depth and alpha if you want.

The real hardware is RGB565, how it sets stuff up internally is out of
our hands - which means X memory alloc/pixmap cache is a little
constrained.

[IDEA: Should we put the mouse and framebuffer at different Z values so
 that we don't have to erase it to draw under it - less flicker]

Acceleration:

All Voodoo
	Fast Fill	-	Solid 2D rectangle fill
				(Also depth buffer clear for 3D)
				Supports a constant alpha option
				Requires a running 3D engine

Voodoo2 and later
	Screen to screen blit
	CPU to screen blit
	Ultra fast fill to some alignments
	Monochrome to colour expansion (cpu to screen only)
	(and they finally made the 2D and 3D state independant
	 if someone ever gets drunk enough to do DRI...)
	Colour conversion on blit
	Dither
	Chroma testing (src/dst) and selection of op by colour
	raster ops are the usual 16 suspects

Other bits supported
	CLUT Gamma correction