PrinterDriverAutoDownload

Revision 32 as of 2008-06-02 10:39:41

Clear message

Automatic download of printer drivers through the internet

Summary

Printer drivers are continually being created or updated - especially as new printers can come out at any time between distribution releases. It is not reasonable to expect all distributions to be completely up to date all of the time, yet users expect to be able to use a brand new printer straight away.

Rationale

Many printers do not get set up automatically straight away due to their drivers not being shipped with the distribution. Giving easy access to drivers from an external source will widen the scope of printers which will 'just work' a lot.

Use cases

  • User A has an uncommon printer for which there are no drivers in their distribution.
  • User B has a printer for which the manufacturer supplies a closed-source driver which distributions cannot ship
  • User C has a new printer whose driver is not yet in the release of the distribution that they are using.

Scope

All Linux distributions, depending on implementation progress starting with Ubuntu Intrepid.

Design

The automatic download will be triggered by the auto-detection and/or manual selection of a printer by the hal-cups-utils or by using the add-printer wizard of system-config-prnter. In any case functions of system-config-printer will try to assign a locally installed driver to the printer and set up a CUPS queue. In the case that these functions do not find an appropriate driver, a DBUS request will be sent telling that a piece of hardware was found for which there is no driver. The call is accompanied by identity information about the printer (IEEE-1284 device ID, if not available make and model).

A driver manager, in our case Jockey, will catch the DBUS call and query the OpenPrinting database via its web query API to get answered back which drivers are available for the printer. It can be no driver, one or several. Then descriptions (and if needed also license text) of the drivers are presented to the user in a GUI, containing the info in the gray boxes at the top of a [http://openprinting.org/show_driver.cgi?driver=splix driver entry page on the OpenPrinting web site]. The user selects the driver, accepts the license (if needed for the driver), and if he agrees with the download and installation of the driver he clicks "OK" or "Next" and the driver gets downloaded and installed. After that, or if the user cancels or if no driver was found, the driver manager closes and returns a success or failure, in success case also which driver was loaded, via DBUS.

Now system-config-printer gets triggered to go on, so that the queue gets set up or the setup gets aborted if the printer is unsupported or the user did not like the available driver.

The driver packages are distribution-independent LSB-based RPMs. To fulfill security and quality standards of the distributions we will apply the following

Binary printer driver packages and also PPD files (for PostScript printers) will be hosted on the OpenPrinting web site. Binary packages will be available as distribution-independent LSB-3.2-based packages. The packages will be automatically alienized to also have .debs (the LSB DDK takes care that the maintainer scripts work with both RPM and DEB). Then the package directories get indexed for apt-get, yum, and urpmi (so that most common distros can manage and auto-update them with their package managers) and the index files get signed to protect against faked packages. Also PostScript PPD files (which cannot be managed with package managers) get signed. In addition, printer manufacturers and driver developers who upload have to follow strict quality, integrity, compatibility, and security guidelines (like for example issuing security updates).

Some driver packages are already available for testing work, but they are not yet indexed.

Description of the printer driver download service at OpenPrinting

Note: This service is completely independent from Ubuntu and is provided to all distributions and also to end users.

These features are already implemented:

  • The LSB 3.2 has requirements for common printer driver interfaces: Driver/renderer interfaces: IJS, CUPS Raster, OpenPrinting Vector, Ghostscript driver pxlmono/pxlcolor, foomatic-rip, libcupsimage library, FHS (File System Hierarchy) extension for printer drivers and PPDs.

  • LSB-compliant binary executables, Adobe-compliant PPDs
  • Make distribution-independent binary RPMs which work with every LSB-3.2-compliant distro (RPMs get converted to Debian packages with alien).

  • Attach these packages as downloadable files to the driver entries of the Foomatic database at OpenPrinting

  • Database entries contain the following information so that users can easily choose the most suitable driver:
    • Driver name
    • Supported printers
    • Release version
    • Does it come from the manufacturer
    • Is it free or non-free?
    • License, with license text if needed
    • Possible patent issues
    • Contact info to get support, report bugs, ...
    • Ratings for typical printing tasks
  • Access is both human- and machine-readable
  • Web API for client software to access: List of all printers, drivers, driver packages, available/recommended drivers for a given printer (specified by device ID, make/model, or Foomatic printer entry), driver free/non-free?, digital signatures, driver download

These feature will be added:

  • Alienizing the RPMs to also get DEBs, this is needed to index for apt-get.
  • Make three indices for apt-get, yum, and urpmi. This allows package manager use with most common distros (Debian, Ubuntu, Red Hat/Fedora, SUSE/Novell, Mandriva, and many derivatives of these).

  • Sign the indices (or the packages), sign also unpackaged PostScript PPDs.

  • Automatically extract PPDs, Foomatic XMLs, CUPS DDK DRVs and generate Foomatic XMLs (driver, perhaps also printer) so that the printers supported by the packages get listed on the OpenPrinting web site and so found both via the web query API and the human-readable web site (and via Google).

  • Publish QA and security guidelines for uploaders (printer manufacturers and driver developers). Driver design guidelines are [https://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers#What_to_do_and_what_not_to_do already available].

For more details see:

Driver download by Ubuntu

In Ubuntu the driver download will get performed by the driver management tool Jockey. See "Design" section above.

Implementation

Web API for database queries and packaging method for distribution-independent binary packages are already implemented. system-config-printer already contains a facility to auto-download pure PPD files (for PostScript printers). Also infrastructure for driver lookup is already in system-config-printer.

As the actual query and download will be done by Jockey, Jockey will use code from system-config-printer as a base to start the query implementation in Jockey.

Next steps of the implementation are the setup of the package repositories and the automatic alienization, indexing, signing and Foomatic-entry generating infrastructure on the OpenPrinting server. One Google Summer of Code student and a volunteer are doing work on the server.

-- CategorySpec