What really changed with the new keyboard driver?

[Kean Johnston]

> Heh, no worries ;)
*Whew* :)

>> It most surely does, thank you. I will start work on it right away.
>> However, of equal interest to me is what is *better* about the new
>> driver?
> 
> 
> It's more cleanly seperated from the server core.  The old driver has a 
> number of os-dependent keyboard driver files in common/ and most of the 
> state of the old driver is stored in the xf86Info global variable. Also, 
> the fact that it's not modularized as the other input driver requires a 
> number of hacks and workaround in the input driver initialization 
> logic.  The new structure allows us to factor out os specific parts into 
> their own file instead of spamming the implementation with #ifdef's.
Ok thatmakes a great deal of sense. Of course the argument *could*
be made (not that I am - I am playing devil's adovate here) that unlike
other input devices which have many varied protocols, the keyboard is
a notable exception. In effect a simpel trade between ifdefs and OS
specific hooks has been made. I'm not saying its a bad thing at all,
but (and this goes to the second part of this reply below) if a choice
had to be made to keep the old stuff around it would not be the worst
decision one could make :)

> If those platforms doesn't provide an os-backend for the new keyboard 
> driver, I think it's a strong signal that they're no longer maintained. 
That is *possibly* true. For some platforms, I am guessing that things
have worked for so long that the *need* for an active maintainer has
waned considerably, until things like this came along. However, if you
are looking for a lithmus test to see how popular/not popular a given
port is, I can't think of a better way than making their keyboards
not work *grin*

Kean