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

Brooks Davis brooks at one-eyed-alien.net
Tue Nov 16 17:47:59 PST 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.

-- Brooks

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-all/attachments/20041116/9e19205f/attachment-0001.bin


More information about the cvs-all mailing list