Google Summer of Code: Display control and Acceleration

Almost all modern display hardware feature various screen resolutions and some form of 2D hardware acceleration - usually as a "bitblit" function to move pixel data around video memory while the processor does something else. Unfortunately the only facility that can make use of this on NetBSD is X, and even then through it's own device drivers. Other popular operating systems (ie linux) feature accelerated framebuffer consoles and kernel display mode setting, as well as numerous display managers for embedded systems that use hardware acceleration (for example Qt/Embedded or DirectFB).

This project is to create a device independent framework to work with wscons, providing kernel mode setting, accelerated framebuffer console support, and allowing userland applications to use 2D acceleration features. More information about this can be found on the project web page

So far I've written a sample driver for my own video hardware (laptop with i915GM chipset). Unfortunately Intel don't provide a programming manual for the i915 chipset, only their later i965 chipset, so I've been using xorg's xf86-video-intel module as a reference implementation.

Mode enumeration is easy to perform on the hardware - the ddc(4) driver already exists to pull EDID timing information from an attached monitor over the i2c bus in VGA connections. However the hardware only provides a pair of GPIO pins to do this with, and I dislike bit-banging, so for the moment modes are enumerated by making vesa bios calls. To export this data to userland, the resolution and colour information for each mode are stored in a prop_dictionary, which in turn is stored in a prop_array that contains a dictionary for each possible modes. This is then copied to the user when requested via an ioctl. Mode detection and setting is then done by specifying an index into this prop_array. This use of proplib neatly avoids future ABI issues should display drivers wish to return optional information about their display modes.

The next task, of providing acceleration support to the console was simple to implement - vcons(9) already exists to provide terminal emulation and rasops(9) provides operations to draw directly to the framebuffer. The most significant change here was creating alternative rasop functions which used the device-driver provided acceleration routines.

The last part of the project is export this acceleration support to userland. It's likely that the existing drm(4) api will be used here in some form, as it's designed specifically for transferring acceleration commands to the hardware, and also manages some of the mapping of user buffers into video memory