On Fri, Apr 13, 2007 at 11:06:19AM +1000, Drew Parsons wrote: > Marc 'HE' Brockschmidt enquired: > > The release team is currently working on a schedule for the lenny > > release cycle. For that, we want to gather some data from the bigger > > software packaging teams in Debian first. > > > > We would like to know which major upstream versions of X.org are > > expected to be released in the next 24 months and how much time you > > expect them to need to get stable enough for a Debian stable release. > > > > Our current, very rough plans would mean a release in 18 months, which > > would be in October 2008. We expect to shuffle this a bit around to fit > > everyone's needs, so please tell us if this date works for you. > > As I see it, there are three major developments going on in X.org at > the moment. > > 1) active probing of video cards to allow a more dynamic setting and > resetting of video modes used. This work is mostly complete already > (available in experimental xserver-xorg-video-intel, soon to appear in > unstable).
To expand on Drew's excellent summary further, there is support in a development branch for the -ati driver for this as well, but it's not ready yet. I expect it to be ready in time for lenny. Nouveau, the replacement for -nv, which is in development will also have support for this, which covers all the major chipsets in use today. I wouldn't be surprised if we see several other drivers that are being actively maintained use this. As it is, this goal is flexible, and we'll ship the best support that's available when lenny is ready. For any chips that aren't ready, they can use the current architecture we already have in place. > 2) Support for input-hotplug. As with the dynamic modesetting in 1), > this allows for dynamic plugging in of X-related devices. Currently > being developed on the master X.org branch, should be ready in X11R7.3 > by June or July. It's not clear what's goin on with this. The implementation requires a daemon which talks to HAL via dbus and lets the X server know when a device changes. Currently, there's a prototype implementation in C written by Daniel Stone, which isn't really meant for production use. There's also an implementation in Python written by a Gentoo developer which is probably also not ready. Once we get 7.2 in to unstable, we'll have to make a more serious run at this. Even if it's not ready to turn on by default though, I plan to follow upstream and set the default mouse to /dev/input/mice, which will solve most problems and simplify things for our users. So either way, the release team shouldn't have to worry about things from this end. Expect to see more from us on it in the coming few months though. > 3) More generally, making /etc/X11/xorg.conf completely redundant. I > believe this will not be achieved under 2), but is a longer term goal. I'm actively working on this with upstream, albeit slowly. The infrastructure is in place to run without a xorg.conf completely, but it doesn't work properly when you have to change something. I'm in the process of making this work so that we can ship without a xorg.conf, or with a minimal one that only changes what the user needs. The exact shape of this by the end of the lenny cycle isn't really possible to predict (and it depends on the improved resolution stuff in item 1) but we can at least whittle away at this as the lenny cycle goes on so that we don't cause any disruptions to the release while making the improvements. > As you can see, X.org's broad aims at the moment are to improve > usability by enabling the Xserver to be configured automatically > without user intervention. X.org is striving to keep to a relatively > strict six month release cycle, I would imagine six months is > sufficient time for us to stabilise X for the release of Lenny. So > with a goal of Oct 2008 we would expect to include X11R7.4, which > should have been released around Feb or Mar 2008. This would include > the new input-hotplug features. One thing the XSF needs to do is actively build the packaging infrastructure for the input-hotplugging. I'm not sure exactly how long this will take, but I don't imagine that it will be too difficult. > A long-standing bug which should be thought about is the GL licensing > problem [1]. SGI kindly contributed code for GL support in X, but their > licence is not DSFG. Upstream is not comfortable with the situation > either and there have been intentions to approach colleagues at SGI to > see about rationalising the licence, to the common X11 licence or > otherwise. However these correspondences proceed at a glacial > corporate rate - not high on corporate SGI's TODO list, you might say. > We've conveniently been ignoring the problem for Debian stable, do we > continue doing so, or are we capable of prodding SGI to accelerate the > discussions? Or do we ditch OpenGL support from Debian... ? These are a real thorn in our sides. Another issue is the nvidia code obfuscation bug, which we can fix when we get nouveau in to the archive. I'd love to have a dedicated maintainer for nouveau[0], but right now it's looking like I need to buy myself an nvidia card. Either way, that etch-ignore bug will be fixable for lenny thanks to the upstream work. - David Nusinow [0] Anyone who's interested, *please* write us at debian-x. We'd love to help you get going on this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
