Xserver driver merging pros & cons

Peter Hutterer peter.hutterer at who-t.net
Fri Sep 16 13:34:17 PDT 2011

On Fri, Sep 16, 2011 at 01:21:11PM -0700, Stéphane Marchesin wrote:
> On Thu, Sep 15, 2011 at 22:17, Dave Airlie <airlied at gmail.com> wrote:
> >> If you're talking enterprise distros though, that means committing to at
> >> least one long-term support stable branch, that you backport new driver
> >> support to
> >> for years, not just the 6 months until the next one.
> >
> > Just a note from an enterprise distro maintainer, we are currently
> > rebasing the X server/Mesa stacks as much as we can.
> >
> > The problem with doing backports is you end up running combinations of
> > totally untested variants from upstream. Like does anyone upstream run
> > Xorg ATI 6.14.2 against Xserver 1.1? of course not. The thing is that
> > although <x= random percentage> of the driver code that is compatible
> > with older servers, there is <100-x> of the code that has subtle bugs
> > that aren't obvious ABI breaks. Inherent reliance on fixes in the fb
> > layer, EXA layer, damage, randr layers etc is nearly impossible to
> > find in advance. Like if Intel made SNA the default, the number of
> > server fixes it requires to operate correctly is major, whereas it'll
> > build against any of those servers at an ABI level.
> >
> Well (and I say this with my packager hat on), I think it's the job of
> the packager to line up whatever combination of drivers and xserver he
> feels like and test it/get it to work. If a packager can get latest
> radeon to work with xserver 1.1 and that works fine for his needs, I
> say why not. I'm actually shipping an xserver 1.9 with more recent
> drivers and the combination is very stable.
> On the subject of merging packages, if anything, some (a lot) of the
> proto packages are tied into X much more than the graphics drivers. So
> they'd be prime candidates for a merge.

the protocol headers are needed by libX* as well, so unless you want to
require the server repo for library building that's less than ideal.
better to merge them into one package but that effort seems to have vanished


More information about the xorg-devel mailing list