This page provides some high level advice and guidance for hardware vendors interested in implementing driver support in Ubuntu for new hardware.
Kernel drm driver:
- Compatibility with the kernel and libdrm in the current development version of Ubuntu (and/or the next or last LTS release)
- Kernel Mode Setting (KMS) support for controlling monitor outputs and selecting appropriate resolutions
- Support for RandR output hotplug events - sends X an event when a monitor is connected/disconnected
- Use GEM for integrated graphics chips, or a GEM-ified TTM (Translation Table Maps)
- Dynamic front buffer resizing such as done by -intel's UXA
DDX (X.org) driver:
- Compatibility with xserver and libdrm in the current development version of Ubuntu (and/or the next or last LTS release)
- Support for RandR 1.3
- Use the E-EDID functions in X.org (useful for HDMI support)
- Xv support - allows for video playback
- DRI2 support - allows GLX apps to do direct rendering to redirected windows, so OpenGL and Xv (X video) work correctly in composited environment.
- Support for either VA-API (Video Acceleration API) or VDPAU (Video Decode and Presentation API for Unix) to allow video programs to offload portions of the video decoding process and video post-processing to the GPU video-hardware.
3D Mesa OpenGL driver:
- OpenGL 2.0 (or later) compliant driver, with these extensions:
The X.org project provides video drivers that covers a wide range of graphics hardware. Augmenting one of these drivers or adding a new driver to the X.org project and publishing the hardware documentation are the best strategies to expand support to new hardware.
It may seem expedient to develop a driver some other way, however following these procedures brings a number of important benefits:
When upstream makes API changes, they'll update the driver. If you do not follow the standard process, you'll be on your own to provide resources for keeping your driver compatible with newer Ubuntu releases.
Increased access to X.org expertise. Risk is issues requiring longer time to resolve.
Shortcutting development via reuse of X.org code.
Streamline packaging efforts. Otherwise, non-standard drivers can require additional distro overhead for packaging, integrating and supporting them.
Improved customer acceptance/adoption. Non-standard drivers risk being dropped later in favor of alternate drivers that do follow the standard processes.
X.org Development Conventions
X.org drivers adhere to the following policies:
- License: MIT/X11
Version control: git at freedesktop.org
- Bug tracker: bugzilla at freedesktop.org
A document on X11 driver design explains how to develop a driver to fit the X.org policies.
The -vesa driver can be used as an example of an X11 driver in miniature. While simple, it conforms to the Xserver requirements and is kept up to date.
Existing drivers like -intel, -ati, -nouveau, and others may serve as good examples to derive from, depending on the nature of the hardware you're developing on.