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: hardy-hardware-detection

• Packages affected: hal, cryptsetup, consolekit, udev, discover, xorg

Summary

In the last years, upstreams have provided vast improvements in hardware detection infrastructure. We review which parts of Debian/Ubuntu specific hardware detection bits are obsolete and how to consolidate and update them.

Release Note

This specification involves a lot of smaller and larger robustifications and changes, but these mostly fall under the "bug fix" and "make it work as it is supposed to" category, and thus are not really worth mentioning in release notes.

Rationale

• Remove maintenance in Debian/Ubuntu, use upstream's solution and collaborate on that instead.
• Much more dynamic, supports future hardware, too.
• Much more robust, since removing overhead.

Use Cases

• Jean-Luc buys a new Canon digicam, which uses the PtP protocol. At the time of Hardy release this was not yet known, but after plugging it in he can access it with the normal photo tools without any permission issues.
• Will has used an nVidia graphics card so far, but now buys a new one from ATi. After installing it, he boots Ubuntu and does not need to figure out how to fix the broken X.org (as he had to do in Gutsy).
• Geordi uses the proprietary nVidia graphics drivers. The other day he installs a newer custom kernel, but the nVidia driver does not yet work on this kernel. X.org automatically falls back to nv.
• Beverley buys a new Dell Latitude laptop which has a bug in its ACPI implementation. The power management recognizes the model and enables a quirk workaround which automatically makes suspend to RAM work flawlessly.

Design

• Device ownership: Make removable USB devices (scanners, cameras, external hard disks, etc.) accessible to the user on the current foreground console instead of providing static udev rules and using group membership based access control. Then the current set of fine-tuned udev rules and large lists of autogenerated udev rules for model-based vendor/product ID matching can disappear entirely, and the access control will work for e. g. future scanners or cameras, too.

• X.org configuration: Drop the vast and hard to maintain set of scripts, discover, and current debconf implementation in favor of using and improving current X.org's built-in autodetection, do not use an xorg.conf in general and only use it for overriding specific settings. Still provide a debconf interface for tweaking xorg.conf, but do it the right way this time ("debconf is not a database").

• Power management: Replace ubuntu specific powermanagement-interface and upstream-unmaintained acpit-support with pm-utils.

• Drop our current legacy kernel options to avoid some race conditions and uncover legacy code which is error prone.

Implementation

Device ownership

• Drop the default system groups plugdev and scanner. Enable ConsoleKit support in hal, which assigns read/write permission to removable USB devices with dynamic ACLs.

• As a followup to above, drop the long vendor/product ID based udev rules of libgphoto and libsane. Ensure that their preinsts remove the obsolete conffiles on upgrade.

• Drop the default system groups netdev and powerdev, drop our in-house development libpam-foreground, drop the network-manager and gnome-power-manager patches to query libpam-foreground. Instead, do the "user is in foreground session" test with PolicyKit rules.

X.org configuration

Aim for fully automatic and dynamic configuration of X.org so that usually xorg.conf is not needed at all. This provides the following advantages:

• Fully utilize upstream's vastly improved hardware autodetection.
• Be robust with hardware changes.
• Provides built-in failover in case a driver stops working for some reason (update, kernel ABI break, proprietary driver update, etc.)
• Can automatically use newly installed drivers without manual configuration (e. g. synaptics or nvidia-glx).
• Changes in driver policy can be made easier, without the need of changing xorg.conf on upgrades.
• xorg.conf will only contain the necessary custom bits and avoids boilerplate.

Notes on particular sections:

• Files: File locations are determined by distribution packages, and should have the right defaults. This particularly affects font packages. Gutsy does not configure any explicit font paths any more, and yet xlsfonts proves that the server finds them, so the section can be dropped entirely.

• InputDevice: X.org server 1.4 now supports dynamic input device detection from hal, the input sections can go away. One particular bit that still needs to be configured is the default keyboard layout, which should be done in a hal FDI (this is already supported). (Note that relying on GNOME to set up the keyboard layout is not sufficient: first, it does not apply to gdm, and second other window managers do not provide their own keyboard layout handling.)

• Device: The X.org server automatically detects the driver to be used based on available hardware and available drivers if this section is missing. However, the preference list still needs some tweaks (e. g. it should be nvidia > nv > vesa, but currently it prefers nv over nvidia). When special options need to be passed to the driver, the section must remain, though. This means that the discover package and a large amount of detection scripts can be dropped.

• Monitor: Again, the X.org server's built in monitor detection usually does a better job than the detection in the Debian/Ubuntu scripts.

• Screen: References to device and monitor are implicit, default monitor resolution is detected automatically, and resolutions and multihead are better configured with XRandR and displayconfig-gtk.

• ServerLayout: This only contains references to the previous sections, which are implicit when not given.

Debconf interface: For manual tweaks and situations where X.org does not start at all, we should still provide a lightweight debconf interface. However, this should use libxf86config, [http://fedoraproject.org/wiki/pyxf86config pyxf86config], or guidance-backends and thus respect the settings in the existing xorg.conf instead of clobbering it with the debconf values and abusing debconf as a database.

Debian is about to do the same changes for X.org, and their and Ubuntu's X.org maintainers are working together on this.

Power management

pm-utils is discovered along with HAL on freedesktop.org, provides a distribution independent power management backend, and is the place to collect all hardware specific quirks. We should make use of this and contribute our changes upstream instead of continuing to maintain the deprecated acpi-support and the Ubuntu specific powermanagement-interface abstraction.

Starting from Hal 0.5.10, the only supported backend is pm-utils.

Kernel configuration

• CONFIG_USB_DEVICE_CLASS=n: This drops /sys/class/usb_device/ which is subject to race conditions when using libusb. With 'n' they get replaced by additional attributes to the actual USB device.

• CONFIG_SYSFS_DEPRECATED=n: Get rid of the /class hierarchy so that all data will be under /devices where it should be.

• CONFIG_TMPFS_POSIX_ACL=y: Required for hal's ConsoleKit integration to set ACLs on device nodes.

• Sync our udev rules with upstream's for the corresponding userspace side.

Test/Demo Plan

To be done when a beta is available.

Outstanding Issues

• Would be nice to have something like sysfs for various X parameters (drivers, pciid->driver mappings, etc.) Much of this info can be gathered via various disparate tools (e.g. xdpyinfo, xdriinfo, xrandr...) however a unified api would give this all in one go and would be much easier. This would be beneficial for programs like restricted-manager and displayconfig-gtk.

CategorySpec