[RFC] merged void driver

[Peter Hutterer]

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