[9fans] kbd.c
FJ Ballesteros
My students have just implemented a change to the distributed
kbd to let it use different tables. It does not need a different
device like kbmap, but instead lets the user select the table
to be used by using the config file. They are changing this
further to let the driver accept a "kbmap us" string into /dev/consctl
to change the tables at run time.
They plan to select a good implementation of this change and send the
contribution. Perhaps it would be better to unify this all to get just
one driver capable of adapting to most of our keyboards.
George Bronnikov ha escrito:
>
> Hello,
>
> Attached are:
>
> 1. A diff to Boyd's/Forsyth's keyboard driver (/sys/src/9/pc/kbd.c) that
> lets it have separate tables for capslock and shift+capslock (tables 4 and 5).
> 2. Russian keyboard table using this diff (capslock serves to switch
> between cyrillic and latin modes).
> 3. An awk script to feed the table into /dev/kbmap.
>
> goga
>
> ------------------------------------------------------------------------
> Name: kbmap.awk
> kbmap.awk Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
>
> Name: kbmap.cyr
> kbmap.cyr Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
>
> Name: kbd.c.diff
> kbd.c.diff Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
rob pike, esq.
too, but am not familiar enough with the issues to trust my judgement.
I rather like Bronnikov's approach, using caps lock to set the mode and
having loadable tables. The default table could still make caps lock
be a control key. Part of the table would be whether caps lock toggles
or is a shift key, and then if it is a shift key, the table would define
how it affects the state. I can't just install his diffs, though, since they
don't match the kbd.c we have.
So many people have tried to settle this matter I think it's in our interest
to settle it once and for all.
-rob
rob pike, esq.
occasions when, in our Unicode world, it makes sense to switch the
keyboard to another language temporarily. This is a different issue
from setting the default keyboard for regular use, but it would be
preferable to see both issues addressed by a single mechanism.
-rob
Geoff Collyer
lock key, so I'd prefer a mechanism that doesn't require one. The HH
keyboard does have alt and ◊ keys, plus the usual array of function
keys, arrow keys and misc. weird PC keys (scroll lock, home, insert)
on other keys when the "function" modifier key is applied.
rob pike, esq.
Whatever your personal taste, the HH keyboard is a crock. I think
it's a mistake to go in one direction or the other based on that
oddball. The vast majority of keyboards have a caps lock and I think
it's reasonable to assume one is present.
Moreover, I believe the right mechanism is a form of shift key, since
it is a shifting mechanism being proposed. If some Uzbek has a Happy
Hacking Keyboard he'll just have to cope.
-rob
Richard
>> My favourite keyboard, the Happy Hacking keyboard, doesn't have
>
>it's a mistake to go in one direction or the other based on that
>oddball.
Are you sure
The vast majority of keyboards have a caps lock and I think
>it's reasonable to assume one is present.
>
>Moreover, I believe the right mechanism is a form of shift key, since
>it is a shifting mechanism being proposed. If some Uzbek has a Happy
>Hacking Keyboard he'll just have to cope.
>
>-rob
>
>
--
Richard Maxwell Underwood
The Internet Is Missing! http://www.satn.org/about/missinginternet.htm
Digby Tarvin
>it's a mistake to go in one direction or the other based on that
>oddball. The vast majority of keyboards have a caps lock and I think
>it's reasonable to assume one is present.
>
>Moreover, I believe the right mechanism is a form of shift key, since
>it is a shifting mechanism being proposed. If some Uzbek has a Happy
>Hacking Keyboard he'll just have to cope.
>
>-rob
I don't want to start a flame war on this, and I am hesitant to take
issue with a renowned Plan9 guru, but I think that criticism
of the HH keyboard is a little strong. My only real gripe with it is
the lack of separate backspace and DEL keys. In general I like the small
footprint.
My personal pet hate is the bloating battleship keyboards that seem
to be inflicted on us by the MSWindows world, with so many superfluous
keys that it gets hard to find the ones I actually need (like the
shrinking space bar, which is barely an inch and a half wide on my
notebook... ) not to mention the amount of desk space they waste :-/
Personally I could quite happily do without numeric keypads, and
caps lock has only ever been a source of annoyance.
I'm not even sure about function and arrow keys, which I use so
infrequently that I find the HH approach of overloading them on the
numeric keys quite an acceptible compromise.
My other keyboard gripe are 'important' keys, like the control key, which tend
to wander about from keyboard to keyboard.
Anyway, my request would be - don't use the 'silly' keys just because they
are there, otherwise we will end up being stuck with them for ever,
even after sanity is restored.
Regards,
DigbyT
--
Digby R. S. Tarvin dig...@acm.org
http://www.cthulhu.dircon.co.uk
Russ Cox
deviant keyboard, rather than that it's not his personal
favorite. It's not as though HH is the only destroyer-size
keyboard out there. If you want a less deviant but still
keypad-less keyboard, the archives list a Lexmark clone that
goes for $90 and a more clicky one that goes for significantly less.
IBM also sells their Thinkpad keyboards in normal keyboard form,
with the trackpoint if you're so inclined. This might well be
a FAQ.
Digby Tarvin
Maybe I am misinterpreting the use of the word 'crock', but
I took it as a somewhat derogatory term. Or was Rob referring
perhaps to the proverbial 'crock of gold'.... ;-)
I know the HH bucks the prevailing trend by replacing bloat with a
'less is more' philosophy, but this is not entirely dissimilar
to the approach taken in a certain operating sytem of which
(I think) we all approve.
I don't want to sound like I am evangelising about the HH,
I do have other keyboards which I find a better compromise.
For instance, I am not keen on the placement of the '\|' and
DEL key either. But there is a lack of consistency on other keyboards,
and if it had separate BS+DEL keys it would definately be above
average IMHO , and I do tend to use one when I am
travelling and don't wan't to be stuck with someone else's
battleship or a spongy notebook job, as it does seem about as small
as you can get without sacrificing key size...
Perhaps I should have asked what it is exactly about the HH keyboard
that makes it deserving of such scorn. Surely the makers of Plan 9
would not condemn something for being small or different :-)
Anyway, thanks for the suggestions. I have looked at the various
keyboards that have been mentioned on this list, but I still
havn't found my ideal. ( Most have this annoying caps lock key... ;-) )
Regards,
DigbyT
kazumi iwane
> Moreover, I believe the right mechanism is a form of shift key, since
> it is a shifting mechanism being proposed.
I may be missing something, but do you have to use a special key
combination to shift your key layout/language pref. ? What's wrong
with a simple command that spits instructions to keyboard driver?
-- kazumi
rob pike, esq.
> combination to shift your key layout/language pref. ? What's wrong
> with a simple command that spits instructions to keyboard driver?
It's clumsier. I admit it's also adequate.
-rob
for...@caldo.demon.co.uk
>>infrequently that I find the HH approach of overloading them on the
>>numeric keys quite an acceptible compromise.
you typically need them to adjust settings in the PC BIOS(!)
but that's about it
kazumi iwane
> My only real gripe with [HH keyboard] is
> the lack of separate backspace and DEL keys.
I also use a HH keyboard (the original one) in the Mode2 as
documented in
http://www.pfuca.com/products/hhkb/hhkb_dip.html ,
so that the "Delete" key acts as a backspace key, and
"Fn + ` (backquote)" acts as a DEL key. Yes, the DEL is
a little harder to get at, but that is OK by me; it makes me
cautious of interrupting a process.
When I was using Plan9 (2nd ed.) on Suns I surprised myself
a lot, because their type-3/4 keyboards had the Delete key
dangerously close to the Return key and invited me to hit the
wrong one.
-- kazumi iwane
kazumi iwane
> When I was using Plan9 (2nd ed.) on Suns I surprised myself
> a lot, because their type-3/4 keyboards had the Delete key
> dangerously close to the Return key and invited me to hit the
> wrong one.
No, it was not Suns but a PC with a HH keyboard in the
default mode. I got it all mixed up, sorry.
-- kazumi iwane
Boyd Roberts
a "kbmap us" string into /dev/consctl to change the
tables at run time.
Yes, it probably does belong with the files served by cons.
However, the kernel should not know about the various layouts;
these should be loaded when the machine boots.
Admittedly it's not likely that your keyboard is going to
change, but I don't feel it warrants cluttering up the
kernel with specialised (possibly redundant) code when
the problem can be solved in a general way with /dev/kbmap.
They plan to select a good implementation of this change and send the
contribution. Perhaps it would be better to unify this all to get just
one driver capable of adapting to most of our keyboards.
Given I currently type on 3 different layouts [qwerty, azerty, Swedish
qwerty] the ability to load up a keyboard map is a must, but it should
never approach the complexity of that attrocity known as xmodmap(1).
I hacked up forsyth's work for my own personal use.
b...@borf.com
keyboard. www.pckeyboards.com. I buy them by the case.
Brantley
Also, I like the shift lock to really be a shift lock. I write
in some languages that have the keywords in uppercase.
Boyd Roberts
in some languages that have the keywords in uppercase.
Yes it should send/do what's on the the key top.
On azerty I also use it to type numeric sequences because
they and '.' are shifted. It also makes typing IP addresses
easier, but it's a terrible layout for writing code because
all the 'special' characters are in totally off-the-wall places.
Swedish qwerty is very close to qwerty but it has the 3 extra
characters in the Swedish alphabet [ä/å/ö] which permutes things
a bit, but it's very useful to be able to type them directly
(particularily if you live in Göteborg).
Eventually, in my 'copious spare time' (tm), I plan to build
a cpu/auth server which will have a Swedish keyboard.
Digby Tarvin
> keyboard. www.pckeyboards.com. I buy them by the case.
I bought a Unicomp M4 keyboard a while back (September 98) after
it was recommended by someone on the list, and it never worked
properly. (after typing 2-3 characters, it goes into a spasm
of sending a continuous stream of garbage - I think we decided there
was a hairline fracture on the PC board somewhere)
I spoke to their support people, and was promised a replacement,
but it never came, so I went cool on the company.
Consequently I can't say that I have used it enough to have given
it a fair trial, but I thought the keys seemd a bit shallow and
laptop like, which I find less comfortable to type on.
The model number is '98U0176', in case there is more than one type
of 'M4'.
> Brantley
>
> Also, I like the shift lock to really be a shift lock. I write
> in some languages that have the keywords in uppercase
I agree, though I would be inclined to make it a normal sized key
out of the way somewhere, rather than larger than normal and to the
right of the 'a' key, where non PC keyboards used to have the far
more heavily used 'control' key.
I also agree that the shift lock key is useful on some foreign
language keyboards. French ones come to mind as needing a shift
to access numeric digits, amoungst other oddities. I usually find
it easier to switch the key mapping, in which case I have to avoid
looking at the keyboard and then I can type resonably successfully.
Regards,
DigbyT
FJ Ballesteros
user of an "unsupported keyboard type" to be able to fill up a new set
of tables
(the driver we have helps doing that by letting you know the scan
codes). That愀
why we don't have a way to dynamic load a new table.
Apart from this, I think the only difference is that we may have
different
"shift" modifiers (eg. AltGr on spanish keyboards, which is different
from Alt).
I惻l send the driver to the list when my students complete it (which
should happen in just a couple of weeks). I'll try to ensure that new
modifiers could be added easily for those keyboards needing it. And BTW,
I
also kind of hate xmodmap (just to ack Boyd).
andrey mirtchovski
> user of an "unsupported keyboard type" to be able to fill up a new set
> of tables
> (the driver we have helps doing that by letting you know the scan
> codes).
I was thinking of adding bulgarian kbd map modifications to the
russian ones posted here couple of days ago (the differences are very
few, but they do exist).. but because of the 'my keyboard is smaller
than yours' flamewar onset I decided to wait until we've all settled
on a standard way of doing different keyboards/alphabets in p9...
anyways, the number of bulgarian plan9 users besides me is about one
(hi, lucho :) and we're not hard-pressed to write in cyrillic all that
much :)
андрей :)
George Bronnikov
> > My favourite keyboard, the Happy Hacking keyboard, doesn't have a caps
> > lock key, so I'd prefer a mechanism that doesn't require one. The HH
> > keyboard does have alt and Б≈┼ keys, plus the usual array of function
> > keys, arrow keys and misc. weird PC keys (scroll lock, home, insert)
> > on other keys when the "function" modifier key is applied.
> Whatever your personal taste, the HH keyboard is a crock. I think
> it's a mistake to go in one direction or the other based on that
> oddball. The vast majority of keyboards have a caps lock and I think
> it's reasonable to assume one is present.
I needed some sticky modifier key to switch between Cyrillic and Latin;
in fact, nothing is tied to it being Caps Lock. If HH does not have one,
you can choose any key you want and make it send the caps lock code -- the
kbmap mechanism allows that.
Perhaps the caps_lock variable should simply be renamed to something
like sticky_mod.
My solution will not work, of course, if you have more than two layouts
to switch (I've seen English/Russian/Ukrainian keymaps for Linux, for
example). It is not hard to make an arbitrary number of keytables, but
I'm not sure it is worth the complexity.
Goga
Boyd Roberts
Boyd Roberts
My /dev/kbmap stuff was a crude hack -- far from perfect.
Hacking the kernel is not my idea of fun:
crashes to crashes, dust to dust, if you hack the kernel
it's gonna bust
Boyd Roberts
like sticky_mod.
Yes I can see that this could be a feature, given I used to
swap between azerty and cyrillic when I used to know some
Russian. I just think it's the wrong way to do it.
caps lock is caps lock -- it should not be overloaded.
oka...@granite.cias.osakafu-u.ac.jp
elaborate to state our situation more.
According to my understanding, there is a problem to solve various
keyoard only from dynamic loading of keyboard table.
In my ktrans, I set trigger key to 'Shift+Space' to translate 'hiragana' to kanji,
this is because this combination seems to have least chance to batting else.
However, there is no possibility to assign this combination to recognize from
any kind of printable character without changing kbd.c in kernel.
You can see my kbd.c at http://basalt.cias.osakafu-u.ac.jp/plan9/kbd_106JP.c.
So, I assume there is some need to have a mechanism to change kbd.c
in kernel. From this experience, I like Nemo's approarch.
There is another thing around keyboard and language problem.
I'm using English keyboard to enter Japanese, english and Russian or
Greek (The last two, I have no oppotunity though :-), using ktrans.
This case, we need only dynamic translation from English string to some
other language. Ktrans offers that mechanism. So, if the keyboard is fixed
we have no problem to deal with multiple languages in Plan 9.
I also have a notebook, which has Japanese JIS keyboard, and in this case,
the situation is simmilar to that of 'Shift+Space' above. For an example,
Japanese JIS keyboard has some additional keys such as 'kanji' 'hankaku'
'hiragana' 'muhenkan', all of which related to Japanese input, and those
must be assigned by kbd.c in kernel. Also, the key has different layout of
':' ';' '\' etc from those of English keyboard. The latter case can be solved
by both mechanisms, such those of kbd.c or some dynamically loaded
translation table mechanism.
As a conclusion, if we could have a mechanism to change the default kbd.c
dynamically like the Nemo's approach, I'd love to use it.
Kenji --hope to help others not familier with kanji and kana culture...
oka...@granite.cias.osakafu-u.ac.jp
Kenji -- just from my curiosity :-)
George Bronnikov
> 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
Lucio De Re
>
> 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.
>
keymap. I detect a potential vicious circle.
++L
Boyd Roberts
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.
Yes, it should be done in user mode, with some minimal kernel
support. Sticking more glop in the kernel is a bad idea.
Getting the scancodes was a truly dreadful experience, espescially
when I tripped over the 0xE0-two-char-sequence woe (0xE0 is à,
which is kinda useful in French).
The problem is 'orrible; you are in a maze of twisty compromises,
all alike.
Boyd Roberts
Absolutely right.
rob pike, esq.
It seems to me the function keys or one of the other unused ones
are a better choice.
The ^t^t thing is a) a horrible hack (mea culpa) and b) in the wrong
driver anyway. As others have pointed out, it's easy to set the
toggle key itself in the tables you load. If you break the horrible
hack, well, don't. Besides, ^t^t0 would be echoed.
-rob
kazumi iwane
> On condition that the Ctrl and "T" keys don't get redefined by the
> keymap. I detect a potential vicious circle.
I agree.
Using a special key sequence to modify the keyboard behavior
itself smells a lot like emacs key binding madness.
My vote goes to using a command whose name and arguments
consist only of ASCII. It's only a mouse-click away in acme.
-- kazumi iwane
Lucio De Re
>
> Using a special key sequence to modify the keyboard behavior
> itself smells a lot like emacs key binding madness.
>
the boundaries of key mapping, with an undo option, too.
> My vote goes to using a command whose name and arguments
> consist only of ASCII. It's only a mouse-click away in acme.
>
Not unreasonable.
My two cents' worth: what would we do if the keyboard was just another
RS-232 peripheral? Why not treat it as if? In the kernel one
converts all sorts of key madness to 256 (or even 65536) key codes
that can be looked up in a user-supplied UTF-8 lookup table. The
default can be altered in slices and restored with one command.
Am I missing something?
++L
oka...@granite.cias.osakafu-u.ac.jp
>support.
I have no objection to this, however, I believe that keyboard would be
set only at the login time. So, we don't need on the fly toggle switch
for it...
Kenji
pl...@itic.ca
Thanks for pointing out that ^t^tn was a 20 seconds hack in an emergency Banana Republic situation :-)
Further more, I may argue that if beeing able to change the keymap in intial CPU/TERM state is vital, then the location is probably right but not the method.
Also to be considered, there exist much more different keyboards than Plan9 unsued keys...
"rob pike, esq." <r...@plan9.bell-labs.com> a crit dans le message news:<9163b7652b976780...@plan9.bell-labs.com>...
> > On condition that the Ctrl and "T" keys don't get redefined by the
> > keymap. I detect a potential vicious circle.
>
Fco.J.Ballesteros
: change, but I don't feel it warrants cluttering up the
: kernel with specialised (possibly redundant) code when
: the problem can be solved in a general way with /dev/kbmap.
Just to clarify, kbd.c stays almost the same with the
changes made to add new tables. Just the handling of
modifiers is changed to admit new tables (eg AltGr).
I wouldn't say the kernel is cluttered by introducing
separate kbdxx.c files with just the tables
and nothing else. I think that's more simple than the
mechanism needed to fill up the tables at run time; besides
the user can cause a real mess if allowed to fill up those
tables at run time (cf xmodmap).
Fco.J.Ballesteros
: occasions when, in our Unicode world, it makes sense to switch the
: keyboard to another language temporarily. This is a different issue
: from setting the default keyboard for regular use, but it would be
: preferable to see both issues addressed by a single mechanism.
But that does not require dynamiclly loadable tables, does it?
If you include let's say us and whatever tables in your kernel
by saying 'kbdus' and 'kbdxx' in your config file, and you are
allowed to switch later between the two, you're done.
What I was missing is that it's inconvenient to write
echo kbdus >/dev/consctl
when you have certain kbdxx keybards, but what about using
function keys to switch between them? (eg. FN switches to Nth map).
Is this a general mechanism, or am I missing something?
for...@caldo.demon.co.uk
you can do it dynamically. some mappings are more
controversial than others (eg, caps lock and ctrl). i don't see that
dynamic loading must lead to something complex, if that's
what xmodmap is.
actually, at the moment i'd be more interested in a description
of what the tables need to express to cover all possibilities.
i know there are sequences of escapes in the scan codes (because they
ran out of bits), and keys that modify subsequent characters by
adding accents (on a german keyboard we've driven), and probably
much more. is there a concise specification?
Boyd Roberts
you can do it dynamically. some mappings are more
controversial than others (eg, caps lock and ctrl). i don't see that
dynamic loading must lead to something complex, if that's
what xmodmap is.
I agree. xmodmap is this insanely complex X thing with some
whacko language to remap keys -- it is truly awful. /dev/kbmap
is simple and just works.
actually, at the moment i'd be more interested in a description
of what the tables need to express to cover all possibilities.
That's kinda hard.
is there a concise specification?
There might be but I'm sure you'll find something weird (say, a VAIO)
which will invalidate your 'keyboard world view'.
for...@vitanuova.com
no doubt we can't cover everything at once, but it seems reasonable
to try to set the thing going, and surely some initial attempt at a description
of what needs to be covered must help?
it might even help to resolve the tables/code discussion.
for...@vitanuova.com
i had a quick look at the freebsd syscons keyboard maps.
there are about 60 of them. i'm sure they don't do all we need,
but i have to say they don't look onerous
to me as files (and they handle stuff like alt-ctrl-shift, which might
or might not be needed by something) but i'm not sure i'd like to compile all that
all into a kernel for (say) installation from CD. of course, dynamic code loading
would remove the need to relink, but that's just a fancy form of
dynamically-loaded table in this context.
Lucio De Re
>
> since i've got a freebsd system here,
> i had a quick look at the freebsd syscons keyboard maps.
NetBSD uses "wscons" which purports to be less architecture dependent.
I have to confess that the keyboard mapping works, whether it is
acceptable or not. I think wscons is too vast a concept to indulge
in, but that's the GNU bloat striking.
If anyone's interested, I can search for the description URL(s).
++L
Matthew C Weigel
>My favourite keyboard, the Happy Hacking keyboard, doesn't have a caps
>lock key, so I'd prefer a mechanism that doesn't require one. The HH
The Lite and Lite2 variants do, as Fn-Tab. Probably more than
sufficient for the presumed rare use.
--
Matthew Weigel
Research Systems Programmer
mcwe...@cs.cmu.edu
Ian Broster
> Anyway, thanks for the suggestions. I have looked at the various
> keyboards that have been mentioned on this list, but I still
> havn't found my ideal. ( Most have this annoying caps lock key... ;-) )
I have no caps lock, fn keys, numeric keypad, arrows, home/end/page
keys etc....
pictures (sorry for the poor resolution):
http://www-users.cs.york.ac.uk/~ianb/pics/onehand2.jpg
http://www-users.cs.york.ac.uk/~ianb/pics/onehand1.jpg
decription:
http://www-users.cs.york.ac.uk/~ianb/dest/keyboard.html
ian
Andries Brouwer
::: is there a concise specification?
:: There might be but I'm sure you'll find something weird (say, a VAIO)
:: which will invalidate your 'keyboard world view'.
: but how are they `weird'? completely outside the PC/AT model?
Russ Cox
> keys etc....
Neither do I. Are you a keyboard?
Russ