X server 1.9 release thoughts

[Jesse Barnes]

On Wed, 7 Apr 2010 19:32:32 -0400
Alex Deucher <alexdeucher at gmail.com> wrote:

> On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > 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.
> 
> I agree with this sentiment for video drivers right now as well.

On the flip side, unless we have a decent set of video and input
drivers included in the server, building and testing a new one will
always be a bit painful.

Today to test a driver:
  1) grab the latest driver git, build and test
    * or if there have been API/ABI changes that need testing *
  1) grab the whole hairy mess of the server, build
  2) grab latest driver git, build & test
and hope it all works.

If we only get some of the important (i.e. required for a standalone
use case) drivers incorporated, we'll end up in the second scenario
more than we do today I think.

So most people are probably agreed that we should make it as easy as
possible (ideally just one git tree) to build & test new code.

In order to do that, and realize the gains of being able to change APIs
and ABIs more easily, we'd need to have something of an "all or
nothing" approach when it comes to drivers; at least the major ones.

I'm a bit biased since I've been working a lot at the API/ABI
boundaries lately, both within X and between its dependencies with
Mesa, libdrm, and the kernel, so I'm partial to rolling more stuff
together.  But I definitely understand that there are tradeoffs.

-- 
Jesse Barnes, Intel Open Source Technology Center