XRoadmap

Introduction

The X server and client libraries are the fundamental GUI platform for Ubuntu. This specification is an overview of our roadmap for X in Ubuntu, and links to more detailed specifications for actual features.

  • X11R7

  • Xgl(x)

  • Modular X build system (implied by R7)

Rationale

Currently, xorg is one of the largest source packages in Ubuntu. Most of this source is utterly stagnant -- neither the upstream code nor the build system for most of the libraries, documentation or fonts have changed upstream in years. The entire tree can be built in a modular fashion, and building it monolithically adds no value. It merely makes it far more difficult to update the relatively small parts of the tree that change regularly (drivers and configuration -- see /XorgAutoconfiguration), and makes security fixes nigh on impossible. A full build of the tree takes around 45min on a modern single-processor Athlon64; closer to two hours on laptops (a ThinkPad X40), and other reasonably modern i386 systems (2.4GHz AthlonXP), and consumes almost 5GB of disk space.

X11R7 will be released upstream on August 19th 2005, with a fully modular build system. DanielStone has been involved in these efforts upstream for some time, and is quite intimately familiar with the build system used (autotools is the poison of choice), as with the code. Using a modular build system will help alleviate many of the difficulties currently faced in packaging xorg, and will allow us to demote giant swathes of code we don't care about to universe, and not have to sit through the long builds all the cruft causes. It will also make security fixes far easier -- currently there have been three or four known sets of vulnerabilities for libXpm (a small pixmap-loading library), which have required full updates of the source package every time.

Currently the Xorg server also has terrible acceleration for the Render protocol (which implements all the Porter-Duff compositing operations, and is used heavily by the Composite extension). This is an architectural restriction imposed by the current acceleration architecture, which will take quite some time to rewrite. However, 3D engines can work through this operation very quickly, and all Render operations translate very neatly to OpenGL commands.

An X server called Xglx has been written, which uses an existing GL implementation and translates all X calls to GL commands. If you run an Xorg server (to set up direct rendering), and then Xglx on top of that, Render operations (e.g. Composite with translucent windows) within Xglx become very, very quick. This makes Composite usable. However, the architecture is rather hackish, and it is not a long-term solution. As it is still useful to play and experiment with, we propose Xglx be built as part of the 'xserver-fdo' (or such) package, which will also contain packages for KDrive.

KDrive in itself is useful for embedded systems, as it is low-footprint, and Xati is also a sort-of-usable server with fantastic acceleration for ATI chips (the usual caveats of no acceleration for >= RV300/Radeon 9550 apply).

Scope and Use Cases

Scope -- all of xorg. There is no real use case in terms of end users, as they will not see a difference, apart from a drastically reduced bandwidth bill.

Implementation Plan

Implement a rolling modularisation: kill xorg via death by a thousand cuts, instead of a gigantic single transition. Break single packages out one by one as seems appropriate (in the bootstrap order of protocol headers, client-side libraries, server, drivers, and then apps; also depending on how ready the build system is upstream). DanielStone has packages of most of the xlibs components from the run-ups to Warty and Hoary, and has packages for the protocol headers ready to cut out now, as well as xterm, fonts and documentation.

Iterate through all the protocol headers, then client-side libraries, then attack the server. The server will take a little while to complete upstream, as it is the most complex piece of code, particularly as the Xorg server needs intimate knowledge of the host system. DanielStone to oversee and implement. This order of implementation tracks exactly the bootstrap order needed to build X from scratch.

Estimated timeline:
week of 9th May -> 13th May: break out protocol headers, fonts, documentation, xterm
week of 16th May -> 20th May: break out Xau, Xdmcp, package XCB, break out libX11, libICE, libSM and as many packages as time allows; depending on time split between modularisation and maintainence of xorg and other packages like linux-restricted-modules
week of 23rd May -> 27th May: hopefully finish libraries
week of 30th May -> 3rd June: modularise applications

Modularise server as upstream development occurs. The given cut-off date for platforms to support the server is June 10th (else they will not be officially supported), so we should have something very solid to work from around this date.

Data Preservation and Migration

None.

Packages Affected

xorg

User Interface Requirements

None.

Outstanding Issues

The xkeyboard-config project from freedesktop.org are taking over maintainence of XKB at this stage, and they have made many improvements, including cleaning up the tree to make a lot more sense, and making all the possible options multi-layout aware (currently some arbitrary combinations are impossible). However, as part of the reorganisation, large swathes of the building and layout have changed, and while they've taken every effort to ensure old configurations will work fine, the xkeyboard-config guys have said that they cannot guarantee all old configurations will continue to work fine. This may be the best target of opportunity in terms of breaking things early, so we can get as much feedback on the XKB component as quickly as possible.

CategoryLookMergeDelete

XRoadmap (last edited 2008-08-06 16:20:06 by localhost)