From owner-cvs-src@FreeBSD.ORG Wed Nov 17 01:47:59 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADE9416A4CE; Wed, 17 Nov 2004 01:47:59 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4875143D39; Wed, 17 Nov 2004 01:47:59 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id iAH1n1HN026002; Tue, 16 Nov 2004 17:49:01 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id iAH1n1iU026001; Tue, 16 Nov 2004 17:49:01 -0800 Date: Tue, 16 Nov 2004 17:49:01 -0800 From: Brooks Davis To: Brooks Davis , Maksim Yevmenkin , Poul-Henning Kamp , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org Message-ID: <20041117014901.GA24989@odin.ac.hmc.edu> References: <7302.1100627038@critter.freebsd.dk> <20041116180905.GA11906@odin.ac.hmc.edu> <20041116183549.GB11906@odin.ac.hmc.edu> <20041117002959.GH24418@fasolt.home.paeps.cx> <20041117004508.GA13628@odin.ac.hmc.edu> <20041117011727.GJ24418@fasolt.home.paeps.cx> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <20041117011727.GJ24418@fasolt.home.paeps.cx> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: Re: cvs commit: src/sys/dev/vkbd vkbd.c vkbd_var.h src/sys/modules/vkbd Makefile X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2004 01:48:00 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 17, 2004 at 02:17:27AM +0100, Philip Paeps wrote: > On 2004-11-16 16:45:08 (-0800), Brooks Davis = 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 int= o a > > > pseudo-driver, serialize it, and send it on to the higher layers of t= he > > > system. I see no real reason why we should't allow a user to start t= yping > > > a command on one keyboard, finish it on another, and hit on a th= ird. > > > Why anyone would want to do that is beyond me, but it should be possi= ble. > >=20 > > That's basicly what I would like to see. I don't think we need to supp= ort > > 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. >=20 > 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 kb= d1 > should probably translate to just 'a'. =20 >=20 > 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 ha= ve > 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 han= dled > 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 b= een > ignoring it by sticking to the mice bits, but... >=20 > Can any syscons gurus shed light on how we could go about convincing sysc= ons > to go from a 'keypress'-oriented approach to a 'character'-oriented appro= ach? =46rom 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 --=20 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 --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBmq4MXY6L6fI4GtQRAltyAJ4zg6tlwhNa8KEovmWge5TewmaklgCfVRg3 MvvDOjXz06/98n8ltD1sIIs= =yk89 -----END PGP SIGNATURE----- --DocE+STaALJfprDB--