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. It is unclear if 7.3 will be officially released in time for Gutsy, but since the new Xorg is highly modularized, if this fails to occur in time, we will upgrade as many of the packages to their latest versions as possible.

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.

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 ChangesForX11R73 page at wiki.x.org, Xorg 7.3 is scheduled to be released in May, however no firm date commitment has been made. 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.

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 resprobe/ddcprobe infrastructure. Cases where the hardware configuration cannot be handled at all will be handled as per the bulletproof-x specification.

Implementation

Package merging

1. Sync xserver 1.3 with debian
2. Resolve all sync issues of xserver-xorg-* components in MoM/DaD
3. 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, then skip writing an xorg.conf file during installation

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 white list, 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.

BoF agenda and discussion

xorg session

• a) review composite readiness for gutsy b) easy configuration c) monitor resolution / driver issues d) xorg 7.3 integration e) projectors

displayconfig-gtk - xrandr-frontend

compiz unreadiness was an issue more on the driver side than on the user side. also complexities in configuration tool design

guidance - python backend for display config tool

xorg autodetection - might be concerns with proprietary drivers

<tepsipakki> how? are they going to be enabled by some other means than restricted-manager (by default?) nv - probably should be replaced with nouveau driver once it has comparable 2D and Xv support

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

Fallback: try first Vesa, then VGA 640x480x16, then Framebuffer. if fallback mode is activated, launch displayconfig-gtk.

fallback to vesa - failsafe. Supposed to work 100%, but some hardware. Or fallback to 256 or 16k vga if that doesn't work. Create blacklist for cards that vesa fails on (like R500). May have to provide a grub boot option.

An X crashing should revert back to a known-good Blacklist not a terribly good idea, since it isn't future-proof at all. True but the vesa failure is quite likely a very rare issue, and a whitelist would be even worse. 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.

Fallback Use Cases:

• Bob changes his monitor for an older one because his monitor broke. Xorg fails to launch because the 'new' (the older one) monitor fails to work with the frequency configured. Bob want to use the older monitor while his monitor is being repaired.
• Ann changes her VGA for a new one. Xorg fails to start.

Easier multihead display management. Use Cases:

• Peter has a laptop. he want to clone his primary display (the LCD) to the output adapter attached to a projector for presentation purpouses.
• Andy has two LCD TFTs lying around. he want to attach another monitor to his dual-output VGA (DB15 and DVI, for example) and extend his desktop to the second display. He uses compiz, also.

kdrive - will be bringing that in for mobile. vesa mode should be identical to this.

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.

Compiz/Beryl - currently work is a bit stalled due to the two communities working to integrate their code back together. Seeing few if any regressions from Compiz so far. Infrastructure is pretty much ready; some issues with drivers. Needs update for xrandr 1.2 (for intel), probably xserver 1.3.

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

xorg-server 1.3 Integration

Packages should now be upgraded individually, and focus should be less on xorg version numbers and more on xserver itself. If the latest version of drivers don't work with that version of xserver, it is a bug.

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.

May also need newer protoinput

<tepsipakki> gutsy has x11proto-input 1.4.2, which is the latest.

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.

Marc Tardif at Canonical is doing automated X certification testing. Need to find out if this can be made publically available/accessible. Has some mix of both manual and automated testing.

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).

To get proper testing and find the critical bugs, plan is to get new xserver in gutsy asap and then encourage people to test gutsy and report issues. There's a high priority spec on this already. <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.

More xorg 7.3-server 1.3

Once xserver 1.3 is in and everything working, we'd like to also see this extended to support hotplug detection. <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.

Merging xorg-server 1.3 - requires protoinput and maybe mesa

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