On Sun, Nov 07, 2010 at 04:01:18PM +0100, Luc Verhaegen wrote: > On Sun, Nov 07, 2010 at 08:05:08AM +1000, Peter Hutterer wrote: > > > > the api for input drivers is quite limited. we have a few structs, but > > most importantly a few calls to initialize various bits of the device > > (does it have buttons, does it have axes, etc.). > > Over the last couple of server releases, those calls have changed > > frequently. the addition of button/axis labels, removal of per-driver > > motion history, now the per-axis valuator mode. in ABI 12 the PreInit > > calls have changed, requiring significant rewrites. > > > > all that can be handled by ifdefs and that's what we do now but it is > > getting towards a big mess. the simple solution is to ditch support for > > older X servers (I don't think anyone really cares about void supporting > > the last 3 server releases) but exactly at that point it starts making > > sense merging the drivers into the server. > > > > Cheers, > > Peter > > I believe that differences in driver APIs should be a build-time > thing, for all currently used versions of X. I personally find > compatibility up to debian stable a very commendable and defendable > goal. > > If the input driver API is that small, then the work needed to keep > drivers compatible should be small too. right, there are a few problems with it though: - while we have the ifdefs in place to compile back to 1.4 or so, I don't know if the drivers even build against those versions. Whenever the ABI is bumped, I test with the current and the next one, but beyond that it's anyone's guess. - With the particular set of drivers I'm talking about here (void, citron, elographics, etc.) I don't even have the hardware to test them. - it still takes time
To frame the argument a bit, here's the number of _actual_ changes (i.e. fixes that aren't packaging cleanup or compile fixes) and the total number of patches (git rev-list XORG-7_1). Both numbers since X11R7.1, tagged April 2006: citron: 1/39 elographics: 10/37 fpit: 4/36 hyperpen: 1/39 mutouch: 3/35 penmount: 6/31 void: 0/34 (well, duh!) I think acecad and aiptek (they actually have maintainers) have a better ratio, didn't check right now though. The best example to show the ifdef mess is vmmouse. Thomas maintains this driver and tests patches against server versions, so vmmouse actually works with multiple server versions. http://cgit.freedesktop.org/xorg/driver/xf86-input-vmmouse/tree/src/vmmouse.c#n828 Similer constructs exist in the drivers listed above, but whether they work (or even compile) I don't know. > If the input driver API is that small, i also find it amazing that there > are such massive changes needed so often. What is going wrong here? Do > you really believe that this logical discrepancy will continue? Or will > there be a time when you see the infrastructure for hardware, which in > comparison to graphics hardware is very simple hardware, get to some > more stable point? I work with evdev hardware nearly 100% of the time, which means the actual hardware is abstracted by the kernel. the only exception here are wacom serial devices that don't add anything to this argument, so they can be ignored. Because of the actual driver hardware issues being mostly detached, much of the rework is to support various new features that the server offers, or simple cleanup. > Lastly, if you really see 1-1 version locking as a worthwhile goal, what > stops you from having a modular driver check for a given input API in > configure.ac? Why do you need to have a driver in the server tree to > make it 1-1 version dependant? Modularity allows you to do whatever you > want here. We can achieve the same thing with version locking in configure.ac, at least on a per-server release base. Note that for the input ABI I follow a different approach than Keith does with the video ABI, I try to accumulate changes and then bump once per incompatible change set, not once per server release. in the last few releases, the input ABI has been bumped more than once per release and the drivers may need updating each time. not all drivers were affected by this, but you may end up with ifdef's that were never part of a release to keep bisectability. for the common drivers, this matters and I'm happy to do it. for the others, you can choose between wasting time adding all the ifdefs or breaking the build. neither is acceptable. having the drivers in the server means they keep building (if not, you can really tell me off...) and the actual time spent updating is minimal because compatibility with past servers doesn't matter. > I still do not see why this is being pushed like this. I fail to find > logical and defendable arguments to demodularize. I do not have time to waste on drivers that are hardly used, have virtually no feedback from users and are untestable (by me). My attempts at convincing the odd bug reporter for these drivers to become the maintainer have failed so far. I'm ok with keeping them compiling against the current X server version. Anything that reduces the time spent doing that, it's a good thing. Note that I am on the record stating that for the same reason, I don't think evdev/synaptics/etc. can be merged at this point. If someone steps up to dig up the hardware, find out how many of the drivers still matter (look at the git history to see how little has changed in the last years), and becomes the maintainer, I'll be happy to help them with keeping them running against all server versions down to whenever. That person ain't going to be me. Cheers, Peter _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel