RestrictedManagerImprovements

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.

Summary

We want to make it easy for users to become aware of the possibilty of enabling additional restricted drivers and provide support for more drivers.

Rationale

Feisty's restricted-manager is limited to configuring drivers which are directly mapped to an already existing available kernel module; there are situations where this is not the case.

We also do not enable all drivers by default. If the set of unused drivers changes (or, as a special case, when we boot the system the first time), we want to notify the user about the possibility of installing additional drivers.

Use Cases

  • Pitti has a Broadcom WiFi card in his laptop. The driver loads automatically, but it does not work at all by default. r-m points out that this driver needs non-free firmware. Pitti agrees to enable it, then he is asked for a source of the firmware (Windows installation, CD, or URL). bcm43xx-fwcutter extracts and installs the firmware and reloads the driver.

  • Jani installs a new Ubuntu box which has an ATI card. r-m tells him that he can install a restricted driver for his hardware. He clicks on the notification, sees that he can enable the ATI driver and does so.
  • Scott installs Gutsy in VMWare. r-m tells him that he can install the 'VMWare tools' for improving the work with the guest system and sets them up if Scott agrees.

Scope

These changes apply to a standard Ubuntu installation and the Ubuntu live system. Once we get a KDE frontend of restricted-manager, it will apply to Kubuntu as well.

Design

  1. Keep track of the list of available, but unused modules. Whenever there are changes, r-m displays a notification: In order to use your hardware more efficiently, you can enable drivers which are not free software. When the user clicks on the tray applet, r-m opens.

  2. Provide support for additional device handlers which are not related to a kernel module (vmware) or need non-free firmware (bcm43xx).
  3. Provide a way how to group a set of modules into one handler, since e. g. the 25 non-free OSS modules or the 5 VMWare modules are not enabled independently from each other.

Implementation

  1. r-m already has code to handle the caching of the "used" lists. This will be generalized and reused to manage the list of unused modules. The check will be done along with the updating of used modules in restricted-manager --check.

    • RestrictedManager.core.get_handlers() currently only considers handlers which have a matching kernel module. This will be extended to always try to add instances of a new subclass NonModuleHandler of DefaultHandler. Their constructors need to check the current system state and should just fail if they are not applicable.

    • These additional handlers can be shipped either in the restricted-manager package itself, or in linux-restricted-modules-common, depending on where it is easier to maintain. The latter package only contains infrastructure for restricted kernel modules and only contains free software, so it will always be installed by default.

  2. Device handlers can ship a list of kernel module names or a regular expression over module paths if they want to care about an entire set of drivers.

Code cleanup:

  • r-m currently contains a code of xorgconfig.py, stolen from displayconfig-gtk, which in turn stole it from KDE guidance. This module should be provided in a python-xorg-config package. The xorg.conf spacing fixes which are applied to r-m's version should be incorporated in that.


CategorySpec

RestrictedManagerImprovements (last edited 2008-08-06 16:40:20 by localhost)