Xserver driver merging pros & cons

[Chase Douglas]

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.

-- Chase