On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer <[email protected]> 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 >> <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
