Xserver driver merging pros & cons

[Peter Hutterer]

On Fri, Sep 16, 2011 at 08:35:21AM -0700, Chase Douglas wrote:
> On 09/16/2011 06:25 AM, Peter Hutterer wrote:
> > On Thu, Sep 15, 2011 at 01:46:30PM -0500, Jeremy Huddleston wrote:
> >>
> >> On Sep 15, 2011, at 11:02 AM, Michel Dänzer wrote:
> >>
> >>> 3) Out of tree drivers will become second class citizens.
> >>
> >> I don't see that as a con.  I see that as a benefit.  If something is not
> >> in the tree, it IS a second class citizen, and users should not expect it
> >> to work any more.  If the trident driver breaks, they can always use vesa.
> > 
> > wacom is GPL but definitely not a second-class driver. unless we're willing
> > to take on the hilarity of discussing GPL-ing the server merging the input
> > drivers is pretty pointless - the driver that needs it the most get's the
> > least benefits.
> 
> Would it be possible to have one source tree and tarball release with
> multiple licenses? The kernel sort of does this, but the licenses are
> reversed. All code is GPLv2, but some is also BSD.
> 
> AFAIK, and IANAL, BSD code can be relicensed as GPL code without any
> issues (as long as none of the BSD code has the dreaded 4th condition).
> X.org could be released as dual BSD/GPL. We could have a requirement
> that any new code be dual licensed or granted an exception (i.e. for wacom).

> > which - for now - at least rules out input driver merging. evdev and
> > synaptics could benefit from some shared code but the effort involved and
> > the potential loss of testers against old releases make me shy away from it
> > right now.
> 
> I think there's still benefit in being able to target only one server
> release in each branch. The input modules have been 2-3 times larger at
> times because of dealing with older ABIs and servers. This makes things
> harder to maintain, and creates extra barriers to new development.

Right, but we can easily do that without merging the drivers too and ditch
old ABIs whenever they become too cumbersome.

Cheers,
  Peter