Date: Thu, 29 Mar 2007 09:08:54 -0800 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: "Timothy Bourke" <timbob@bigpond.com>, hackers@freebsd.org Subject: Re: enable/disable in kbd drivers Message-ID: <bb4a86c70703291008n4a82e627l3f45b1ff8e5ac571@mail.gmail.com> In-Reply-To: <20070325015717.GA797@triptrop> References: <20070325015717.GA797@triptrop>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/24/07, Timothy Bourke <timbob@bigpond.com> wrote:
> I have almost finished a ppbus-based driver for Super Nintendo
> controllers. It presents itself as a keyboard to the operating system. I
> wanted to start and stop the polling thread via, respectively, the
> kbd_enable_t and kbd_disable_t hooks, but these do not seem to be called
> properly. Hence this post.
>
> The enable and disable functions are identical across the keyboard
> drivers (atkbd, ukbd, vkbd, kbdmux). Enable calls the KBD_ACTIVATE macro
> which increments the kb_active count. Disable calls the KBD_DEACTIVATE
> macro which decrements the kb_active count. It seems reasonable to
> assume that the two functions should be called in pairs.
>
> However, enable is called too many times and disable is never called.
>
> In the kbdmux_ioctl routine:
> KBADDKBD: enable is called via the KBDMUX_ENABLE macro.
> KBRELKBD: does NOT call disable
>
> Taking dev/usb/ukbd.c as an example, the effect can be seen by adding
> this line to the ukbd_enable function (after the call to KBD_ACTIVATE):
> printf("ukbd_enable: %d\n", KBD_IS_ACTIVE(kbd));
> And similarly for ukbd_disable and then running dmesg or kbdcontrol.
>
> Additionally, each kbd driver calls its own enable function when
> attached. For example, in USB_ATTACH(ukbd):
> (*sw->enable)(kbd);
> This would appear to be unnecessary for keyboards connected via kbdmux.
> I am less certain about those connected directly, but the syscons
> sccngetch routine does seems to call enable and disable. Perhaps it
> should also call enable when it first starts?
>
> Does the attached patch seem reasonable? It would fix my immediate
> problem.
sorry for the delay. i'm not sure about this patch. basically, i do
not think that keyboard should be disabled if it is released from
kbdmux. it is perfectly fine, imo, to have two (or more) active
keyboards attached to the system as long as only one of them is
primary. it is possible to use /dev/kbdX interface to talk to
non-primary keyboard(s) directly.
thanks,
max
> I could write a patch to remove the calls to enable in the driver init
> routines but tI don't really understand how syscons works.
>
> Tim.
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70703291008n4a82e627l3f45b1ff8e5ac571>