X server 1.9 release thoughts

[Alex Deucher]

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.

Alex