Driver Files
This page is dedicated to describing what functions live where and how all the actual files fit together for the 2D driver, the 3D driver, and the DRM. There is some variation between different drivers, but for the most part there is pattern of driver structure.
2D Driver
The 2D driver source is found here: xorg/drivers/xf86-video-*
*_driver.c - This is the guts of the 2D driver. It usually contains the mandatory functions (?PreInit() ?ScreenInit(), VT switching, etc. - see the XFree86 DESIGN document for more info on required functions) and the mode setting/switching code.
*_regs.h - Contains the register defines and macros.
*.h or *_driver.h - usually contains the driver specific info struct and other structs needed by the driver. May also contain some macro defines and function definitions shared by the various files in the driver.
*_video.c or *xv.c - Contains the code to set up and use the video overlay (Xv).
*_hwmc.c - Contains the code to set up and use the iDCT or motion compensation features with the video overlay (XvMC). The XvMC user libraries live in xorg/lib/libXvMC.
*_accel.c - Contains the 2D acceleration code.
*_shadow.c - Contains functions to support the shadow framebuffer if the driver supports it.
*_i2c.c - Contains driver specific code for accessing the i2c bus on the card/chip. It's usually used for DDC2.
*_dga.c - Contains code to support DGA, an old feature that lets apps write driectly to the framebuffer. It's rarely used nowadays.
*_cursor.c - Contains code to enable the hardware cursor.
*_dri.c - Contains server side code to set up the DRI.
*_sarea.h - Contains defines needed for the SAREA (shared memory area).
3D driver
The 3D driver source is found here: mesa/src/drv/
*3dreg.h or *_reg.h - 3D register and macro defines.
*_tex.[ch] - Contains texture code.
*xmesa.c or *screen.[ch] and *context.[ch] - These deal with screen and context management. The xmesa name is historical. There used to be a number of callbacks whose names started with XMesa. They were called directly by Mesa. The interface has changed in Mesa 4.0. Now there is an API record that specifies these driver entry points. In some drivers (radeon, r200, r128) these functions are in *screen.[ch] and *_context.[ch].
*_span.[ch] - Access to spans of the frame buffer, used for software rasterization fallbacks.
*tris.[ch] - It draws all primitives using some templates in mesa/tnldd. All primitives are mapped to the ones supported directly by the hardware. At the highest level whole Mesa vertex buffers are rendered.
It is not the most efficient way of rendering because all strips and fans are decomposed into individual triangles. So lots of duplicate vertices are emitted to the hardware. At some point we may implement our own render stage that takes advantages of hardware strips and fans. r128 and mga used to have *_fastpath.[ch] files in Mesa 3 that did just that. So did the savage driver. These were not ported to Mesa 4 in any of these drivers. Maybe it's not such a big performance win in practice.
*_state.[ch] - manage the 3D state in hardware.
*_dd.[ch] - Some selection of device driver functions. I don't know why they are collected in this file. Maybe a historical leftover. The radeon drivers don't have it anymore. It's pretty short in other drivers.
*_ioctl.[ch] - ioctls for use with the DRM.
*vb.[ch] - Vertex setup. Determines which components are needed for the current state and generates appropriate hardware vertices from Mesa vertices. For the D3D-like vertex formats there are templates in mesa/tnldd.
DRM
The linux DRM source is found here: mesa/drm