cvs commit: src/sys/dev/vkbd vkbd.c vkbd_var.h
brooks at one-eyed-alien.net
Wed Nov 17 01:48:00 GMT 2004
On Wed, Nov 17, 2004 at 02:17:27AM +0100, Philip Paeps wrote:
> On 2004-11-16 16:45:08 (-0800), Brooks Davis <brooks at one-eyed-alien.net> wrote:
> > On Wed, Nov 17, 2004 at 01:29:59AM +0100, Philip Paeps wrote:
> > > My idea would be to feed all 'input events' from hardware drivers into a
> > > pseudo-driver, serialize it, and send it on to the higher layers of the
> > > system. I see no real reason why we should't allow a user to start typing
> > > a command on one keyboard, finish it on another, and hit <cr> on a third.
> > > Why anyone would want to do that is beyond me, but it should be possible.
> > That's basicly what I would like to see. I don't think we need to support
> > people hitting the accent key on one keyboard and then finishing typing on
> > the other, but we do need to support multiple keyboards if only because the
> > users expect it.
> I'd like to assume that the fundamental 'event' from a keyboard to reach the
> console is going to be a 'character'. Your example becomes even crazier to
> consider when you add a compose key into the equation. Likewise, I don't
> think it's a good idea to try to support people holding down modifiers on one
> keyboard and pressing keys on another. Alt on kbd0 followed by 'a' on kbd1
> should probably translate to just 'a'.
> One problem we're going to run into quickly are keymaps. Currently, the maps
> are being handled by syscons (and pcvt). If we're going to let people have
> multiple keyboards, there will be those who will want to have a US-qwerty and
> a Belgian azerty side-by-side. Mapping keys will probably need to be handled
> by the driver (or the input system) on a per-device basis rather than by the
> console driver. That little headache has been fermenting at the back of my
> head since I first started thinking about writing an input layer. I've been
> ignoring it by sticking to the mice bits, but...
> Can any syscons gurus shed light on how we could go about convincing syscons
> to go from a 'keypress'-oriented approach to a 'character'-oriented approach?
From looking at the atkbd driver, I thought we were fairly character
oriented, at least with the modifers since there's state for things like
the accent key there (though I could be misreading all this mess). The
seperate keymap issue is one I hadn't thought of since I'm in US-ASCII
land. ;-) It could actually make a fair bit of sense to hook keyboards
up that way. On the other hand, getting the single keymap case working
and doing it well would be a huge step in the right direction.
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20041116/9e19205f/attachment.bin
More information about the cvs-src