enable/disable in kbd drivers

[Timothy Bourke]

On Mar 30 at 12:02 -0700, Maksim Yevmenkin wrote:
> On 3/29/07, Timothy Bourke <timbob at bigpond.com> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070331/c84be4a7/attachment.pgp