Jockey

Jockey is a tool for installing third-party hardware drivers.

Jockey provides the infrastructure and the user interface for finding and installing third-party drivers which are applicable to the computer. This includes drivers which are added or updated after the release of a distribution, or drivers which cannot be included into the distribution for various reasons (CD space limitation, licensing problems, etc.).

A common use case is providing a friendly and semiautomatic way to install drivers for new hardware which the current distribution release does not support yet, or install Nvidia and ATI fglrx X.org drivers.

Jockey was designed to be distribution agnostic and fulfill the need of different distributions, driver vendors, and system integrators. It is designed and developed within the LinuxFoundation driver backports workgroup.

Operation

At startup, the Jockey backend probes the system for available hardware. This can happen in various ways, currently implemented is  scanning /sys for modaliases. In the future it is planned to add more methods, such as querying cups for detected printers which do not have a driver.  Detection methods will be added as needed by component vendors and distributions. The set of available hardware is represented as "HardwareID" objects (which can represent anything that uniquely identifies a piece of hardware, such as a vendor/product ID, a modalias, or a printer identification string).

For each hardware ID, a set of driver databases (instances of DriverDB) are queried for available drivers. At the moment, the only existing implementation is LocalKernelModulesDriverDB, which uses the standard Linux kernel modules.alias maps to map modaliases to kernel modules. In the near future we plan to add another implementation which queries an online driver database as well. The DriverDBs transform the set of HardwareIDs to a set of DriverIDs.

A DriverID represents all necessary metadata about a driver, such as:

* driver class (kernel module, printer driver, package, X.org graphics driver, firmware, etc.)
* handler class name (see below)
* location of the driver (repository, package name, possibly sha1 and other checksums, signatures)
* driver specific parameters (arbitrary type/value pairs which the handler understands)

All drivers handled by Jockey need to be encapsulated by a subclass of "Handler". A handler instance provides a hook for arbitrary code which needs to run in order to fully install a driver. Jockey already provides handler implementations for common cases such as kernel modules, kernel module firmware, X.org driver, groups of drivers, etc. The vast majority of drivers will use parameterized instances of these default handlers, but drivers which need some more sophisticated local configuration can ship their own handler subclass and add the necessary code.

Structure

The bulk of Jockey's work (hardware detection, driver database queries, package installation, etc.) is done by an UI independent backend which provides its functionality over the system D-BUS. Access is controlled by PolicyKit privileges (see backend/com.ubuntu.devicedriver.policy.in for details); by default, all users can do local device driver status queries, all local users can trigger a remote driver database query, and actually installing/removing drivers is restricted to system administrators.

The different user interfaces (GTK, and KDE, and both provide a CLI as well) run with normal user privileges and just provide a human friendly and internationalized presentation/UI of the backend services. They do not contain any driver logic.

Adapting Jockey to a Linux distribution

Jockey is carefully written to not be specific to any Linux distribution. All OS/distro specific operations are encapsulated in the "OSLib" class, which needs to be subclassed and implemented by the Linux distributions. Most methods already have a reasonable default implementation upstream, but some are just inherently distro specific (search for "NotImplementedError" to find those).

This minimizes the porting efforts of distributors while retaining the possibility to make adjustments in one central place.

The abstract OSLib class is thoroughly documented, and there already exists a branch for Ubuntu[3], and the test suite has a dummy implementation (see tests/sandbox.py). These should suffice to implement Jockey for other distributions as well.

What is new in this release:

• This version fixes a ton of bugs, including all the ones which are currently selected as blockers for the final 0.5 release.
• It does not have new features.

What is new in version 0.5 Alpha 1:

• This is the first preview of the upcoming 0.5 release which focuses on a large design overhaul to improve portability, support for printer detection, printer drivers from openprinting.org, a D-BUS interface for driver lookup for desktop applications, and a refurbished GTK user interface.