What really changed with the new keyboard driver?
kean at armory.com
Thu Sep 9 08:02:10 PDT 2004
> Heh, no worries ;)
>> 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
> 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*
More information about the xorg