On Mar 30 at 12:02 -0700, Maksim Yevmenkin wrote: > On 3/29/07, Timothy Bourke <[EMAIL PROTECTED]> wrote: > >It seems that, for the extant drivers: > > * enable only increments kb_active, > > * disable only decrements kb_active. > > well, yes, if all kbdmux did was call KBD_ACTIVATE/_DEACTIVATE > directly, i would not have any problem with it. however, kbdmux calls > enable() method and other drivers (such as the one you wrote) may do > other things in enable/disable() methods. perhaps the right thing to > do to is to have kbdmux check is keyboard is "enabled" and if not - > call enable()?
Maybe there is a gap between the function names, enable() and disable(), and their intended operation? If we interpret enable/disable() as a form of reference counting (as seems to be implemented) then consumers of a keyboard driver should call enable() when they expected to receive data, and disable() when finished with the driver (as done by syscons). Drivers wanting to run regardless of such requests could call enable() themselves when initialized (as they do already). Other drivers could run activation code when enable() is called and kb_active changes from 0 to 1, and deactivation code when disable() is called and kb_active changes from 1 to 0. Specifically my driver could acquire the ppbus and start a polling thread when attached (enable() && 0->1). It could release the ppbus and stop the polling thread when not required (disable() and 1->0). Thank you, Tim.
pgpsK8gJ9WcCQ.pgp
Description: PGP signature
