Once backported drivers have been built into packages, these packages need to be distributed to the “sysadmin” so installation works as easy as possible for him.

While the Linux user doesn't care too much about different installation methods accross distributions and there is some happy coopetition in this, the hardware vendor techsupport would strongly prefer to have distro agnostic diagnostic tools to check the driver status.

Also, the system and component vendors would prefer to have some distro agnostic base format to maintain their KMPs in, that's why they currently have their distro agnostic own support packs, pro packs and update express packs.

And the distros prefer to have reliable hardware agnostic methods to autodetect the hardware that actually is in the system and are looking for a good way to autoconfigure the right drivers from that information.

• 1 Scope
• 2 How is it currently done?
  • 2.1 Dell
  • 2.2 Fujitsu Siemens Computers
  • 2.3 HP
  • 2.4 IBM
  • 2.5 Red Hat
  • 2.6 SUSE
  • 2.7 ubuntu
• 3 possible common solutions
• 4 who is working on this

• wrapping KMPs into a bundle
• providing the bundle to customers
• degree and method of automation in 'selecting the right driver'
• check wether 'the right drivers' are on this system

Latest stable release of Ubuntu ships a tool called “restricted-manager” (see project and some screenshots).

This provides (Gnome/KDE) desktop integration and an UI for installing non-free hardware drivers, such as the nVidia/ATi graphics drivers, or the Broadcom bcm43xx firmware. It checks for newly available drivers, notifies the users about them, and provides single-click install. This is just HW detection and UI, though, it relies on the normal distribution packaging tools.

r-m is pretty Ubuntu specific, though. Currently I am working on a generalization and rewrite so that it will become an upstream project (see the specification). I recently discussed this with Jon Masters from RedHat, who had similar ideas, so we agreed on a design which would make r-m suitable for all Linux distributions, in the sense of setting up a central driver → package mapping, and offering an UI mode for managing free third-party drivers, too.

The rewrite has gotten quite far now. I have an abstract and distro/UI agnostic backend with full test coverage, a GTK implementation (KDE is in the works by a contributor), and an implementation of the OSLib class (which abstracts the distro specific details such as package queries/installation) for Ubuntu, as well as some working example custom handlers (for the proprietary nVidia drivers ATM).

The biggest problem that I have with it ATM is that it does not have a proper name yet. It's currently called 'driver-manager' but that might be too generic to be palatable for distros. Some random (and not utterly appealing IMHO) ideas were 'driver monkey', 'driverkit' (SCNR), and 'Threepio' (a protocol druid which interacts with humans fits the idea quite nicely, doesn't it?) I greatly appreciate suggestions here, so that I can create a real project page on Launchpad and fix the code to have the final directories, etc.

Now I need to port the smaller features of restricted-manager, such as the notifications, firmware installation dialogs, etc. This should not take too long any more.

To answer the specific points above:

• wrapping KMPs into a bundle

That should be done with normal packaging, i. e. ship the KMPs into .rpm/.debs and put them into a distro repository. There's no point in reinventing the wheel, distribution channels, package authentication, certification, etc.

• providing the bundle to customers

That's done with the UI described below. In Ubuntu we only use the tool for non-free drivers, though, since we believe we should not promote third-party free drivers. However, the rewritten driver-manager has all three modes (non-free only, free only, any).

Since d-m has an abstract UI, it's easy to provide a CLI for servers, too.

• degree and method of automation in 'selecting the right driver'
• check wether 'the right drivers' are on this system

d-m does HW detection by scanning /sys and mapping the modaliases to an instance of 'Handler'. This is a Python class which provides the glue for handling a particular driver and enabling/disabling it in the system. For most drivers this will be an instance of a standard 'kernel module' handler, but there are modules where more work is required (like modifying xorg.conf for X.org graphics drivers) or which are not kernel modules (like winmodem and printer drivers).

Currently the mapping to kernel modules is done locally with modalias files, but Jon and I are designing a central database where d-m can query for additional or updated drivers online.

Since every distro needs to do certification checking and QA, the driver db entries are per-distro and per-release. Thus every distro can put the prefered driver there. d-m just presents the first matching driver which is available, to avoid confusing the user with alternatives. Thus distros can provide an ordered list of possible driver, sorted by preference.

driver-manager is explicitly designed to be a common solution for distributions.

• Martin Pitt: driver-manager implementation
• Jon Masters: http://www.drivertool.org shared driver DB