X server 1.9 release thoughts

[Peter Hutterer]

On Wed, Apr 07, 2010 at 06:33:25AM -0700, Dan Nicholson wrote:
> On Tue, Apr 6, 2010 at 11:29 PM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> > I'm just replying here so we've got my opinion public and archived rather
> > than spread across several IRC conversations.
> >
> > From the input drivers POV merging them in provides little benefit as of yet
> > and would probably be even detrimental to testing.
> 
> One of the big advantages of putting the input drivers in the same
> repo would be the ability to refactor common functionalities like
> mouse button emulation into the server. One of the things I'd like to
> see happen over time is the input properties becoming less driver
> specific. E.g., I'd much rather make use of the property "Middle
> Button Emulation" than "Evdev Middle Button Emulation". This would
> seem to occur much easier when the server and drivers can be
> refactored simultaneously.

I wholeheartedly agree with that, this is in fact the carrot Keith 
hangs in front of my face every time he brings merging the drivers up :)
 
> > Right now, the drivers that matter build against several X server versions
> > and I get testing of e.g. evdev master against older servers, finding
> > evdev-specific bugs during the development cycle. This is mostly due to the
> > input drivers being much simpler and easier to install than video drivers,
> > they have virtually no dependencies.
> > The work needed to support multiple server versions is mostly negligible.
> > To get the same exposure of testing once the drivers are merged into master
> > requires a lot of cherry-picking on my behalf.
> > Even then, we'd still need users to install the server + dependencies to test
> > a new evdev patch, something which at this point would likely be a
> > deterrent.
> > So at this point, merging drivers in would increase my workload and reduce
> > testing exposure.  That's why I'm reluctant for evdev and synaptics to be
> > merged, even though the "no API/ABI" is tempting. The drivers just don't
> > move enough to make it worthwhile just yet. We'll see how Benjamin's
> > multitouch efforts will affect that.
> 
> In the near term that would hurt you because you'd have the modular
> evdev built against older servers and the monolithic evdev in the
> newer server. So, testing over multiple servers and porting fixes
> would be a pain.

once merged, the modular evdev driver would simply be a minimally maintained
stable branch. so that's easy enough, though more legwork is needed for
patches of course.

> Longer term, I can't see it being that big a deal. If a person says
> that they're having a problem in a stable release, you check out and
> build the stable server with the _exact_ driver they're using and find
> the bug. It would seem to make hunting bugs easier since you can have
> basically an exact copy of the software they're running in one repo.
> 
> Porting fixes from one driver version to the other would still be a
> cherry-pick forward or back, just like if you were fixing a bug in the
> server. If they're on a really old server/driver combo, tell them to
> upgrade. If someone came to you with a xorg-server-1.6 bug right now,
> would you attempt to fix it? I'd guess you'd tell them to try a newer
> server. That advice wouldn't change if the bug happened to be in the
> evdev driver bundled with that server.

not _quite_ the same issue. there is one big difference in there that
matters: I can't yet tell a user to just rebuild the whole server (note the
"just"), but I can do so for input drivers. Get the git repo, then rebuild
and install over the system one and off we go with testing. the server is
more complicated and I've had quite a few ppl go away when requested to test
newer servers (especially those with little experience).

It's a numbers game. How many contributors and testers will I lose or gain
compared to the hours of work spent? Until the server is a lot easier to
build from scratch, I think the numbers aren't in my favour yet.

Cheers,
  Peter