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: xorg7.3

• Packages affected: All xorg packages

Summary

We wish to upgrade Ubuntu to Xorg 7.3 for the Gutsy release. 7.3 is scheduled for release in August, but since it is highly modularized now, we can begin upgrading most packages to their latest versions as soon as they become available. We should strive to do this, as it ensures we gain maximum time for testing.

One of the key features of Xorg 7.3 is better monitor autodetection. In integrating 7.3, we will attempt to leverage this capability for as many graphics cards as possible. For those cards that lack drivers with xrandr support, we will retain the current system.

Release Note

This release, Xorg 7.3, includes the following features:

• RandR 1.2: RandR 1.2 offers output hotplug, as well as on-the-fly output reconfiguration and mode switching.
• Input hotplug: Input hotplug allows hotplugging of input devices, and also adds enhanced support for touchscreens and tablets.
• KDrive: Numerous enhancements have been made to the KDrive codebase, including better support for multiple input devices.
• New -intel driver, intended for replacing -i810 and other intel drivers.

Rationale

Xorg 7.3's new features promise to help us address some core complaints from users regarding monitor detection and other issues such as input hotplug. As well, keeping up with Debian and upstream releases is important for keeping up with fixes in general.

Use Cases

• Zathura has a monitor that rotates into portrait mode. He wishes to use xrandr to rotate his X session 90 degrees to match.
• Yolanda buys a new high resolution LCD monitor to replace an old low resolution CRT. She wishes to have Xorg automatically recognize and configure itself for the new hardware configuration without having to touch any config files.
• Walter buys a new graphics card that only works with the latest released Xorg drivers. It won't work with Xorg 7.2's drivers, so he needs Xorg 7.3.

Assumptions

According to the Xorg developers, Xorg 7.3 is due out in August, but it is uncertain if this is a firm date. We assume that it will be released in time for Gutsy's feature freeze.

Design

Merging the 7.3 components will be standard merge work. Much can simply be synced from Debian, however a number of components are currently merged from upstream Xorg, not from Debian. Debian is planning to do some package reorganization which may result in us being able to sync from them rather than carrying these separate components.

For monitor auto-detection, a list of supportable drivers (and/or hardware) will be used to select when to use Xorg's new xrandr-based detection mechanisms. For hardware/driver combinations not on this list, the system will fall back to the existing xresprobe/ddcprobe infrastructure. Cases where the hardware configuration cannot be handled at all will be handled as per the bullet-proof-x specification.

Implementation

Package merging

1. Sync xserver 1.3 (and possibly xserver 1.4) with debian
2. Resolve all sync issues of xserver-xorg-* components in MoM/DaD
3. Merge xrandr 1.2 from Xorg
4. Merge additional xorg-provided packages in Ubuntu that are not provided by Debian
5. When Xorg announces the official Xorg 7.3 package, ensure we are shipping those versions.

Autoconfiguration support

1. Assemble a list of drivers, cards, and monitors that Xorg is expected to be able to autodetect with no xorg.conf
2. Write script that checks if the current hardware config matches the known-good whitelist.
3. If the system looks okay for Xorg autoconfiguration, during installation write an xorg.conf file that omits the monitor, graphic device, and screen sections. Other sections of the xorg.conf file will remain.

   • We need to ensure that autodetection produces the same results for components other than monitor detection (e.g. font paths, loaded modules). In addition, the keyboard layout usually needs to be configured explicitly; keyboard layouts usually cannot be autodetected because even USB keyboards don't tend to return accurate information, and the specification for USB keyboard layout detection is pretty dire anyway. Can we omit just the Device, Monitor, and Screen sections (or whatever's appropriate) but keep many of the others? --ColinWatson

   • There are debconf preseeding facilities used by Kickstart and the like which allow explicitly overriding certain bits of xorg.conf. If these are used, we should probably continue to write an xorg.conf anyway. --ColinWatson

Test/Demo Plan

1. Attempt installation on hardware from the list of hardware thought to be autodetectable, and verify it is detected correctly.
2. Attempt installation on hardware not on the whitelist, and verify that the current X configuration system is used.

Outstanding Issues

• There may be regressions compared with Xorg 7.2 in hardware support. For instance, some binary drivers won't support xrandr.
• Xorg is deprecating -i810, but it's uncertain if -intel provides regression-free support for -i810. We may need to ship both, at least for a while.
• xserver 1.4 may also be included in 7.3, but will it be out soon enough for adequate testing?

BoF agenda and discussion

Has this all been factored into the main specification? The spec can't be approved until that's done. It's OK to leave things here as historical context for rejected ideas if that's useful; but things that have been written up clearly should be removed from this section. --ColinWatson

guidance - python backend for display config tool

<tepsipakki> nv-2.0.95 also supports xrandr-1.2, but nouveau could be included as well (like -i810/-modesetting was).

VESA failure is seemingly a very big thing w/feisty since Radeon X1300 - X1950 series is so common nowadays on laptops etc. Sounds like a good thing to blacklist.

<tepsipakki> r5xx vesa failure is a bug with a fix. There should be no need for a white/blacklist.

If worse comes to worse and the display won't work at all with default drivers, what about a text tool to prompt user about downloading the proprietary drivers and installing them.

We will need a white list (black list?) to determine when to default to the new xrandr and/or compiz, and when to just use the current system

Input hotplugging dbus: http://lists.freedesktop.org/archives/xorg/2007-April/023894.html

May need to also uprev mesa (may need to uprev anyway for other reasons). We're in 6.5.2 currently; we may need to go up to 7. 6.5.3 was released on April 27, 7.0 (first stable release after 6.4.2) might be coming as soon as this month.

x test suite - esp. for drivers, maybe stress test. Could be useful for blacklisting/whitelisting as well. glean.sf.net - gl calls various modes together (composite, with other combinations) xrandr

basic test - start up server cairo test, perhaps with other backends just running kpdf and checking for corruption

also could have users go through a checklist, run some tools, etc.

Drivers for xserver 1.3 - proprietary drivers have changed. Need to use radeon head with xrandr 1.0. External displays may have some issues such as the order of screens (patch exists).

<tepsipakki> 1.3 will break fglrx/nvidia, since the new server identifies itself as 1.3, not 7.x.

xcb-enabled xlib. There's still a lot of tools that depend on the old xlib. Some applications lock up.

For workaround, we could include both the old and new xlib. We could have a "profile" to allow proprietary apps to get through this.

<tepsipakki> you mean input-hotplug? AFAIK that's going to be in xserver-1.4 (= R7.3)

live.gnome.org - takes advantage of the new stuff in xorg server, extra screens, etc. "Brave New X11 World"

For projectors that don't support EDID, assume it can do 800x600 (maybe 640x480). Make it easy to change it after. The xrandr tool spits out a list of known modes. The GUI tool should be able to tell that the projector does or does not support EDID, and if not it should give the list of possible modes.

For whitelist, build onto discover-data, using pci ID's and falling back to the model name.

<tepsipakki> as a sidenote, the debian xbase-clients is in process being split up, and the results should replace the individual packages which we've had since dapper(?). It should make things more maintainable (=can be synced from debian).

CategorySpec