[RFC] merged void driver

[Luc Verhaegen]

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.

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?

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.

I still do not see why this is being pushed like this. I fail to find 
logical and defendable arguments to demodularize.

Luc Verhaegen.