Re: X.org plans for the lenny cycle
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.
Reply to: