This spec needs to be formalised, but for now, here is the basic idea:
Assign a hardware ID to all known, supported pieces of hardware, and provide standardised Hardware Support Packages (HSPs).
When the user wants to add support for a new piece of hardware, be it a printer, sound card, mobile phone, web cam, or other device, they simply need to install the one HSP that is specifically associated with that device via this hardware ID. This can be simplified with something not too unlike the Restricted Drivers manager we already have, though the scope obviously extends outside the boundaries of proprietary unsupported kernel modules.
Currently, it appears that we are simply throwing as much hardware support into Ubuntu as possible, without really attempting to keep a clear division between software that pertains to different pieces of hardware.
This leads to a number of problems. A few particular issues currently affecting Ubuntu are:
- "HPLIP Toolbox" installed when it has no business being on the majority of computers
- Bluetooth services installed and running, with no regard to whether the computer owner actually has a Bluetooth module
- "Palm OS Devices" control panel applet when I've never owned or plan to own a Palm device.
I have a Sony Ericsson K750i mobile telephone. It is supported by:
- USB mass storage kernel driver
- HAL FDI data that describes what kind of device it is, where music should be stored on it, what formats it supports, etc.
- Device icons provided by Tango
For the purpose of this example, we can give my device a hardware ID of "f000ba12".
The HSP name for this device would hence be something like "hardware-support-f000ba12". It can depend on hypothetical "usb-mass-storage", "hal-sony-ericsson" and "tango-device-icons-sony-ericsson" packages.
Notes on this example
Currently, USB mass storage support is installed by default, and the (very specific) HAL FDI data for the phone is simply bundled with upstream HAL. Device icon support is all thrown in together in Tango. As more and more hardware becomes supported, it will become very inefficient to do what we are doing with HAL FDI data and icons.
Multiple choice HSPs (e.g. fglrx vs. r300)
When there are multiple driver configurations possible, then two alternative packages can "provide" the standardised HSP.
- ubuntu-devel-discuss thread:
Wouldn't it be more useful to create a package 'hardware-support' which contains a small script and a hardware ID database? The script would be invoked (background) by HAL as soon as a yet unknown (has never been plugged in before) device is plugged in. The script would lookup the ID in the database and would ask the user to install the associated packages. This would avoid the problem of having thousands of hardware-support-xxxxxxxx packages. Fhackenberger
The benefit of supporting hardware by a single package per device is that if, at a later date, we decide that our "Acme Crate" hardware requires a different set of packages, or maybe just an extra package, it can be supported as a simple update of the "hardware-support-xxx" packages dependencies. Otherwise, your hypothetical "hardware-support" package would have to maintain its own internal list of why it installed what, which is duplicating the functionality of the package manager. Do you agree? Also, do you think that there will be issues with having thousands of hardware support packages? email@example.com