Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/driver-device-manager

• Packages affected: hal, gnome

Summary

There is currently no user-friendly way to manage devices, drivers and modules. If a user has to tune (via module params for example) a driver, this has to be done by manually editing files.

The purpose of this spec is to define methods for userspace to handle this better, and to develop a GUI for user control of these methods.

Rationale

With Linux being used more and more by average Joe's and Jane's, requiring them to manually edit files to get a working system is not following the definition of usability that we are aiming for.

Use cases

• Bubba has two bt878 based audio chipsets in his desktop. He wants one to use the normal Alsa driver, and the other to use the multimedia driver (for use with the Tv capture card that accompanies it). Using the device manager, he sets each device to the proper driver.
• Bobby Joe buys a new SATA controller for his computer. He finds that the driver included with his version of Ubuntu detects the card, but doesn't work properly with it. He inserts the IHV's driver disk, installs the new driver, and uses the device manager to tell the system to use the new driver instead of the one included with his system.
• Sally Sue has an old computer, with an ISA card that is supported by a driver in her Ubuntu system. However, the hardware is not well spec'd, which means the driver isn't always correct in how to initialize it. She uses the device manager to set some module parameters for this particular module so it works properly with her card.

Scope

Basic implementation is to take hal-device-manager and create a new package with it. This is already a familiar interface and available on our desktop. It's written in Python/Glade.

The reason for creating a new package is that hal-device-manager is part of hal, and as such is supposed to be OS independent. The extensive changes needed to handle very Linux-centric functionality justifies the fork.

MattZimmerman: I don't like the idea of maintaining a fork of hal. Why is it that these changes can't be integrated into hal? Surely there is other Linux-centric functionality there, and it can only be enabled where it is applicable. Has this been discussed with upstream?

BenCollins: It's not a fork of hal, it's just a fork of the hal-device-manager, which is a small and simple program in the hal package that looks mainly like a proof of concept or testing program more than anything. It does nothing but display the device tree as stored in hal. The reason for forking this one small program is that, as explained, the changes are linux-centric and will more than double the code base in the hal-device-manager. Hardly the type of thing that you want as a local patch to an existing package.

There may need to be kernel changes in order to accommodate some of the preferred logic.

Design

• Functionality required:
  • Detect drivers associated with devices retrieved from hal.
  • Determine list of modules that provide drivers for a specific device.
  • Read meta-data (modinfo) associated with the module for that driver.
  • Allow admin to assign new defaults to these module params, or accept defaults.
  • Ability to disable/enable a device (bind/unbind).
  • Ability to associate a specific driver with a device.
  • For drivers which allow it, enable the ability to force bind a device to a driver (e.g. new_id for PCI devices and drivers).
• Generic system wide options:
  • Enable/Disable USB2.0 (ehci driver).
  • Driver profiles, to allow rebooting with different configurations?

Implementation

Basic implementation covered in Scope and Design sections.

Code

Most code will be implemented in the new linux-device-manager package. Other code may be needed in the kernel. The interaction with udev may require some tweaking there as well.

Unresolved issues

• The kernel currently has no mechanism to stop from binding a device to an already loaded driver. Upstream suggests unbinding after noticing this, and binding to the preferred driver. This is not ideal, and is the portion that is likely to require kernel changes.

Remarks

Hal upstream currently developes a similar thing, [http://lists.freedesktop.org/archives/hal/2007-April/007926.html gnome-device-manager]. This looks promising, and we should cooperate with them.

CategorySpec