From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Bronnikov To: <9fans@cse.psu.edu> Subject: Re: [9fans] kbd.c In-Reply-To: <200204010047.g310lReH004506@theraft.strakt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 1 Apr 2002 10:50:20 +0400 Topicbox-Message-UUID: 70ad9d26-eaca-11e9-9e20-41e7f4b1d025 On Mon, 1 Apr 2002, Boyd Roberts wrote: > caps lock is caps lock -- it should not be overloaded. Well the key itself is overloaded as another Ctrl in the default keymap. Moreover, I was not happy with the code for handling it -- it only worked for symbols between 'a' and 'z'. That said, of course my code was a hack on top of your hack, to let me work in my own language with minimal effort. I think what we need is: 1. Some key that can act as a sticky modifier -- that's why the current kbd.c is inappropriate. I like the idea of ^t^t n. 2. Some way to change keymaps on the fly. This is why I'm not so fond of Nemo's solution -- I don't want to recompile the kernel each time I need another keymap. Moreover, I don't want to write code in C each time I need to define a keymap (did I misunderstand his proposal?). 3. I don't like the idea of having a builtin English qwerty and making translations in userspace -- what's so special about qwerty? What shall we do with keyboards that have more keys than the standard English one (like Japanese, if I correctly understand Kenji)? On the other hand, userspace solution is more flexible, if only we can get the raw input, something like keycodes, from the kernel. But then again, we would need to imitate not just /dev/cons but also /dev/consctl -- another complexity. In the end, my vote goes to a version with /dev/kbmap+^t^t n to change maps, an arbitrary number of them. The /dev/kbmap protocol needs to be extended a little to reflect multiple maps. Goga