cvs commit: src/sys/dev/vkbd vkbd.c vkbd_var.h src/sys/modules/vkbd Makefile

[Philip Paeps]

On 2004-11-16 11:38:34 (-0700), Scott Long <scottl at freebsd.org> wrote:
> What we really need is a single unified keyboard and mouse virtualization
> layer that allows bluetooth, usb, and at/ps2 devices to plug in at the
> bottom and talk to the one or more console interfaces at the top.

I sollicited ideas for a 'generic input core' layer on -arch not long ago :-)

My idea/dream/goal/foo is to have a little driver provide an interface to sit
between what we now know as kbd and all its children, psm, ums, and the three
usb-but-not-hid touchscreen drivers I've been procrastinating on porting, and
feed events back to syscons in a consistent sort of way.

Something like input-core in the Linux kernel, but prettier *grin*

I envision an API where we can do an input_register_mouse() or _kbd() during
attachment of a hardware driver (or indeed a virtual driver like vkbd(4)),
followed by input_feed_event() in the interrupt handler to send the events
over to syscons.

Hardware drivers would only need to do a minimum of processing before feeding
to syscons (have the Magic Input Core deal with scaling and translating from
absolute coordinates to motions and whatnot).

The 'on top of the hardware drivers' bit should be fairly simple to do, I
think.  I've been hacking at it on the bus in the last week or so, getting
strange looks from people because apparantly I've been talking to myself.
Getting syscons to like input might be a bit trickier, mainly because
everytime I try to grasp how syscons works, it becomes even less clear :-o

One of the things I'd like to achieve as a nice bonus is to be able to get rid
of moused and the duplication it causes, and to allow X11 to get to the mice
directly without stealing them from syscons.

> It should allow devices to be plugged in at runtime and should insulate the
> real console interface from caring which keyboard is plugged in at boot, if
> any are at all.  And yt _does_ need to work in single user mode and in DDB.

That'll be another challenge :-)  The problem with ddb will be getting the
input to the debugger through the different bits of kernel without losing
anything along the way.

> I know I'm saying a lot of 'shoulds' right now, but the rise of these
> non-at/ps2 keyboards is causing us lots of problems and we need to fix it.
> Brooks had talked about working on something similar to what I've described
> above, so please work with him to mold your vkbd work into that model.

Keyboards, mice, joysticks, voodoo dolls, anything that produces input, I'd
like to see under one happy little interface...  I hope to have some useful
code to post on -hackers or -arch in a couple of busrides.  Ideas most
welcome.

 - Philip

-- 
Philip Paeps                                    Please don't Cc me, I am
philip at freebsd.org                               subscribed to the list.

  The organisation of any program reflects the organisation
  of the people who developed it.