Xserver driver merging pros & cons

[Michel Dänzer]

On Don, 2011-09-15 at 10:45 -0500, Jesse Barnes wrote: 
> 
> Pros:
>   1) easier to propagate API changes across drivers (just like Linux)
>      1a) thus easier to change ABI
>   2) developers focused on driver development now have more incentive
>      to make sure the server works well so regular releases can still
>      happen (i.e. more people working on blockers whether driver or not
>      as releases approach)

Incentive is one thing, feasibility is another, see below.

> 3) allows removal of driver compat code for various server versions
>      3a) thus removes combinations of driver+server that developers
>          have to support & test
>   4) increased test coverage for the server as users wanting current
>      driver code will be building new servers too
> 
> Cons:
>   1) more work for distros to backport just driver changes to old
>      servers (especially if people follow through on (3) above)
>      1a) if backporting is harder, new hardware support will be more
>          difficult to land in "enterprise" level distros
>   2) harder for users to just upgrade drivers independently, now
>      they'll have to build the whole server
>      2a) thus less testing of current driver code from technical users

3) Out of tree drivers will become second class citizens. This doesn't
apply to proprietary drivers only but also e.g. to the Gallium xorg
state tracker, which we may want to use for Radeons at some point (and
some nouveau people have been playing with it as well, but I don't know
what their plans are for it).


Speaking as a radeon driver developer, merging the driver into the
server tree would be unworkable at this point because since the "new
development model" has been in effect, it's not possible to get even
trivial changes into the server tree without a ridiculous amount of
time/effort.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer