X server 1.9 release thoughts

Jesse Barnes jbarnes at virtuousgeek.org
Thu Apr 8 08:30:52 PDT 2010

On Wed, 7 Apr 2010 20:50:28 -0700
Stephane Marchesin <stephane.marchesin at gmail.com> wrote:

> On Wed, Apr 7, 2010 at 20:44, Daniel Stone <daniel at fooishbar.org> wrote:
> >
> > On Wed, Apr 07, 2010 at 05:02:20PM -0700, Jesse Barnes wrote:
> > > On the flip side, unless we have a decent set of video and input
> > > drivers included in the server, building and testing a new one will
> > > always be a bit painful.
> >
> > Sure, but on the flip-flip side, and it's hard to say this without
> > slighting anyone here, but will the drivers actually be stable enough to
> > ensure that? If I fix a bug in evdev and ask someone to go test current
> > xserver master, hopefully they're not going to come back and say 'I've
> > got an 855 so my display doesn't work, do you have a patch against an
> > older server?'.  To be honest, I'm not sure our regression testing is
> > yet good enough for this.
> >
> Indeed, it seems to me that video drivers are different enough that
> they can be kept separate for now. Also note that the EXA and Randr
> have stabilized (those were the most intrusive changes recently), and
> most of the interface changes are done now. Merging would bring little
> gain then.

I think video drivers have settled down a bit too actually.  With most
of the mode setting logic in the kernel the DDX video drivers are
pretty small, and the intel one at least has seen much less churn

Of course, that argument cuts both ways.  E.g. if the video drivers
aren't changing much, what API/ABIs are we hoping to make easier to
change?  For me the most recent was DRI2.  We already have a bunch of
ugly conditional code in our driver to handle various versions of the
server DRI2 interface we could get rid of with an integrated package.
It would also be easier to factor out common KMS code from the drivers
into the server.

Jesse Barnes, Intel Open Source Technology Center

More information about the xorg-devel mailing list