Xserver driver merging pros & cons

[Stéphane Marchesin]

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.

Stéphane