Re: [9fans] kbd.c

Re: [9fans] kbd.c

[rob pike, esq.]

Interesting you mention this.  I have been considering a unification
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

Re: [9fans] kbd.c

[FJ Ballesteros]

I think that it's reasonable to expect the very first Plan 9 
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´s
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´ll 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).


"rob pike, esq." wrote:
> 
> Interesting you mention this.  I have been considering a unification
> 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

Re: [9fans] kbd.c

[Boyd Roberts]

azerty has AltGr -- ick.

Re: [9fans] kbd.c

[Boyd Roberts]

    I also kind of hate xmodmap (just to ack Boyd).

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

Re: [9fans] kbd.c

[forsyth]

since i've got a freebsd system here,
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.

Re: [9fans] kbd.c

[Lucio De Re]

On Tue, Apr 02, 2002 at 11:48:08AM +0100, forsyth@vitanuova.com wrote:
>
> 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

Re: [9fans] kbd.c

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]

but how are they `weird'?  completely outside the PC/AT model?
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.


[-- Attachment #2: Type: message/rfc822, Size: 2410 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] kbd.c
Date: Tue, 2 Apr 2002 11:44:36 +0200
Message-ID: <200204020944.g329iant027487@theraft.strakt.com>

    it's easier in my experience to build and check these tables if
    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'.

Re: [9fans] kbd.c

[Andries Brouwer]

forsyth@vitanuova.com writes:

::: 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?
: 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.

Re: [9fans] kbd.c

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

it's easier in my experience to build and check these tables if
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?


[-- Attachment #2: Type: message/rfc822, Size: 2219 bytes --]

To: 9fans@cse.psu.edu
Subject: Re: [9fans] kbd.c
Date: Tue, 2 Apr 2002 10:28:54 +0200
Message-ID: <20020402082856.CB18D19988@mail.cse.psu.edu>

:  Just to clarify, I prefer dynamically loadable tables because there are
:  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?

Re: [9fans] kbd.c

[Boyd Roberts]

    it's easier in my experience to build and check these tables if
    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'.

Re: [9fans] kbd.c

[Fco.J.Ballesteros]

:  Just to clarify, I prefer dynamically loadable tables because there are
:  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?

Re: [9fans] kbd.c

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 723 bytes --]

:  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.

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).


[-- Attachment #2: Type: text/plain, Size: 2500 bytes --]

Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Sun Mar 31 14:46:21 MDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.16.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id DCDE119A29; Sun, 31 Mar 2002 07:46:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from theraft.strakt.com (theraft.strakt.com [62.13.29.34])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 81C1819A17
	for <9fans@cse.psu.edu>; Sun, 31 Mar 2002 07:45:59 -0500 (EST)
Received: from theraft.strakt.com (localhost [127.0.0.1])
	by theraft.strakt.com (8.12.1/8.12.1/Debian -5) with ESMTP id g2VCjvpZ029527
	for <9fans@cse.psu.edu>; Sun, 31 Mar 2002 14:45:57 +0200
Received: (from boyd@localhost)
	by theraft.strakt.com (8.12.1/8.12.1/Debian -5) id g2VCjvm0029525
	for 9fans@cse.psu.edu; Sun, 31 Mar 2002 14:45:57 +0200
From: Boyd Roberts <boyd@strakt.com>
Message-Id: <200203311245.g2VCjvm0029525@theraft.strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] kbd.c
In-Reply-To: <3CA62883.43F9B212@gsyc.escet.urjc.es>
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.8
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Help: <mailto:9fans-request@cse.psu.edu?subject=help>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Sun, 31 Mar 2002 14:45:57 +0200

    They are changing this further to let the driver accept
    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.

Re: [9fans] kbd.c

[plan9]

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." <rob@plan9.bell-labs.com> a crit dans le message news:<9163b7652b976780d7b590ac790ad527@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.
> 
> 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
> 

Re: [9fans] kbd.c

[okamoto]

>Yes, it should be done in user mode, with some minimal kernel
>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

Re: [9fans] kbd.c

[rob pike, esq.]

> On condition that the Ctrl and "T" keys don't get redefined by the
> keymap.  I detect a potential vicious circle.

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

Re: [9fans] kbd.c

[okamoto]

By the way, what's the problem of xmodmap method?

Kenji -- just from my curiosity :-)

Re: [9fans] kbd.c

[okamoto]

I have problem to understand the discussions here.  So, please let me
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...

Re: [9fans] kbd.c

[andrey mirtchovski]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

> I think that it's reasonable to expect the very first Plan 9 
> 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 :)

андрей :)


[-- Attachment #2: Type: message/rfc822, Size: 3777 bytes --]

From: FJ Ballesteros <nemo@gsyc.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] kbd.c
Date: Sun, 31 Mar 2002 20:58:14 +0200
Message-ID: <3CA75C46.72061755@gsyc.escet.urjc.es>

I think that it's reasonable to expect the very first Plan 9 
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´s
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´ll 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).


"rob pike, esq." wrote:
> 
> Interesting you mention this.  I have been considering a unification
> 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

Re: [9fans] kbd.c

[bwc]

I feel that I should, at this point, put in a plug for the unicomp Model M4
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.

Re: [9fans] kbd.c

[Boyd Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

    Also, I like the shift lock to really be a shift lock.  I write
    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.

Re: [9fans] kbd.c

[Digby Tarvin]

> I feel that I should, at this point, put in a plug for the unicomp Model M4
> 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
-- 
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] kbd.c

[forsyth]

>>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.

you typically need them to adjust settings in the PC BIOS(!)
but that's about it

Re: [9fans] kbd.c

[rob pike, esq.]

> 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?

It's clumsier.  I admit it's also adequate.

-rob

Re: [9fans] kbd.c

[Russ Cox]

I think Rob's point was more that the HH is a significantly
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.

Re: [9fans] kbd.c

[rob pike, esq.]

> 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.

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

Re: [9fans] kbd.c

[Richard]

rob pike, esq. writes:
>> My favourite keyboard, the Happy Hacking keyboard, doesn't have
>
>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.

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

Re: [9fans] kbd.c

[Digby Tarvin]

>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

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                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk

Re: [9fans] kbd.c

[kazumi iwane]

Digby Tarvin wrote:
> 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

Re: [9fans] kbd.c

[kazumi iwane]

I (kazumi iwane) wrote:
> 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

Re: [9fans] kbd.c

[kazumi iwane]

rob pike, esq. wrote:
> 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

Re: [9fans] kbd.c

[George Bronnikov]

On Sat, 30 Mar 2002, rob pike, esq. wrote:

> > 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

Re: [9fans] kbd.c

[Boyd Roberts]

    Perhaps the caps_lock variable should simply be renamed to something
    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.

Re: [9fans] kbd.c

[George Bronnikov]

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

Re: [9fans] kbd.c

[Lucio De Re]

On Mon, Apr 01, 2002 at 10:50:20AM +0400, George Bronnikov wrote:
>
> 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.
>
On condition that the Ctrl and "T" keys don't get redefined by the
keymap.  I detect a potential vicious circle.

++L

Re: [9fans] kbd.c

[Boyd Roberts]

    I detect a potential vicious circle.

Absolutely right.

Re: [9fans] kbd.c

[kazumi iwane]

Lucio De Re wrote:
> 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

Re: [9fans] kbd.c

[Lucio De Re]

On Tue, Apr 02, 2002 at 01:27:28AM +0900, kazumi iwane wrote:
>
> Using a special key sequence to modify the keyboard behavior
> itself smells a lot like emacs key binding madness.
>
One could declare a key, key combination or key sequence to be outside
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

Re: [9fans] kbd.c

[Boyd Roberts]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]

    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.

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.

Re: [9fans] kbd.c

[Geoff Collyer]

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.

Re: [9fans] kbd.c

[Matthew C Weigel]

Geoff Collyer <9fans@cse.psu.edu> wrote:
>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
 mcweigel+@cs.cmu.edu

Re: [9fans] kbd.c

[rob pike, esq.]

Just to clarify, I prefer dynamically loadable tables because there are
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

[9fans] kbd.c

[George Bronnikov]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 349 bytes --]

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

[-- Attachment #2: Type: TEXT/PLAIN, Size: 64 bytes --]

#!/bin/awk -f
/#/	{next}
/^$/	{next}
	{ print $1, $2, $3}


[-- Attachment #3.1: Type: text/plain, Size: 425 bytes --]

The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Type: TEXT/PLAIN; charset=koi8-r; name="kbmap.cyr"
	Content-Transfer-Encoding: BASE64
	Content-ID: <Pine.LNX.4.30.0203231501411.878@donkey.bronnikov.mccme.ru>
	Content-Description: 
	Content-Disposition: attachment; filename="kbmap.cyr"

[-- Attachment #3.2: kbmap.cyr.suspect --]
[-- Type: application/octet-stream, Size: 1415 bytes --]

# Setting Caps Lock
0	0x3a		0xf864
1	0x3a		0xf864
4	0x3a		0xf864
5	0x3a		0xf864

# Russian unshifted characters
4	0x10	0x439	;й
4	0x11	0x446	;ц
4	0x12	0x443	;у
4	0x13	0x43a	;к
4	0x14	0x435	;е
4	0x15	0x43d	;н
4	0x16	0x433	;г
4	0x17	0x448	;ш
4	0x18	0x449	;щ
4	0x19	0x437	;з
4	0x1a		0x445	;х
4	0x1b	0x44a	;ъ

4	0x1e		0x444	;ф
4	0x1f		0x44b	;ы
4	0x20	0x432	;в
4	0x21	0x430	;а
4	0x22	0x43f	;п
4	0x23	0x440	;р
4	0x24	0x43e	;о
4	0x25	0x43b	;л
4	0x26	0x434	;д
4	0x27	0x436	;ж
4	0x28	0x44d	;э

4	0x2c		0x44f	;я
4	0x2d	0x447	;ч
4	0x2e		0x441	;с
4	0x2f		0x43c	;м
4	0x30	0x438	;и
4	0x31	0x442	;т
4	0x32	0x44c	;ь
4	0x33	0x431	;б
4	0x34	0x44e	;ю

4	0x29	0x451	;ё

# Russian shifted characters
5	0x10	0x419	;Й
5	0x11	0x426	;Ц
5	0x12	0x423	;У
5	0x13	0x41a	;К
5	0x14	0x415	;Е
5	0x15	0x41d	;Н
5	0x16	0x413	;Г
5	0x17	0x428	;Ш
5	0x18	0x429	;Щ
5	0x19	0x417	;З
5	0x1a		0x425	;Х
5	0x1b	0x42a	;Ъ

5	0x1e		0x424	;Ф
5	0x1f		0x42b	;Ы
5	0x20	0x412	;В
5	0x21	0x410	;А
5	0x22	0x41f	;П
5	0x23	0x420	;Р
5	0x24	0x41e	;О
5	0x25	0x41b	;Л
5	0x26	0x414	;Д
5	0x27	0x416	;Ж
5	0x28	0x42d	;Э

5	0x2c		0x42f	;Я
5	0x2d	0x427	;Ч
5	0x2e		0x421	;С
5	0x2f		0x41c	;М
5	0x30	0x418	;И
5	0x31	0x422	;Т
5	0x32	0x42c	;Ь
5	0x33	0x411	;Б
5	0x34	0x42e	;Ю

5	0x29	0x401	;Ё

5	0x04	'"'
5	0x06	':'
5	0x07	','
5	0x08	'.'


[-- Attachment #4: Type: TEXT/PLAIN, Size: 2113 bytes --]

138a139,178
> Rune kbtabcaps[Nscan] = 
> {
> [0x00]	No,	0x1b,	'1',	'2',	'3',	'4',	'5',	'6',
> [0x08]	'7',	'8',	'9',	'0',	'-',	'=',	'\b',	'\t',
> [0x10]	'Q',	'W',	'E',	'R',	'T',	'Y',	'U',	'I',
> [0x18]	'O',	'P',	'[',	']',	'\n',	Ctrl,	'A',	'S',
> [0x20]	'D',	'F',	'G',	'H',	'J',	'K',	'L',	';',
> [0x28]	'\'',	'`',	Shift,	'\\',	'Z',	'X',	'C',	'V',
> [0x30]	'B',	'N',	'M',	',',	'.',	'/',	Shift,	'*',
> [0x38]	Latin,	' ',	Ctrl,	KF|1,	KF|2,	KF|3,	KF|4,	KF|5,
> [0x40]	KF|6,	KF|7,	KF|8,	KF|9,	KF|10,	Num,	Scroll,	'7',
> [0x48]	'8',	'9',	'-',	'4',	'5',	'6',	'+',	'1',
> [0x50]	'2',	'3',	'0',	'.',	No,	No,	No,	KF|11,
> [0x58]	KF|12,	No,	No,	No,	No,	No,	No,	No,
> [0x60]	No,	No,	No,	No,	No,	No,	No,	No,
> [0x68]	No,	No,	No,	No,	No,	No,	No,	No,
> [0x70]	No,	No,	No,	No,	No,	No,	No,	No,
> [0x78]	No,	Up,	No,	Up,	No,	No,	No,	No,
> };
> 
> Rune kbtabshiftcaps[Nscan] =
> {
> [0x00]	No,	0x1b,	'!',	'@',	'#',	'$',	'%',	'^',
> [0x08]	'&',	'*',	'(',	')',	'_',	'+',	'\b',	'\t',
> [0x10]	'q',	'w',	'e',	'r',	't',	'y',	'u',	'i',
> [0x18]	'o',	'p',	'{',	'}',	'\n',	Ctrl,	'a',	's',
> [0x20]	'd',	'f',	'g',	'h',	'j',	'k',	'l',	':',
> [0x28]	'"',	'~',	Shift,	'|',	'z',	'x',	'c',	'v',
> [0x30]	'b',	'n',	'm',	'<',	'>',	'?',	Shift,	'*',
> [0x38]	Latin,	' ',	Ctrl,	KF|1,	KF|2,	KF|3,	KF|4,	KF|5,
> [0x40]	KF|6,	KF|7,	KF|8,	KF|9,	KF|10,	Num,	Scroll,	'7',
> [0x48]	'8',	'9',	'-',	'4',	'5',	'6',	'+',	'1',
> [0x50]	'2',	'3',	'0',	'.',	No,	No,	No,	KF|11,
> [0x58]	KF|12,	No,	No,	No,	No,	No,	No,	No,
> [0x60]	No,	No,	No,	No,	No,	No,	No,	No,
> [0x68]	No,	No,	No,	No,	No,	No,	No,	No,
> [0x70]	No,	No,	No,	No,	No,	No,	No,	No,
> [0x78]	No,	View,	No,	Up,	No,	No,	No,	No,
> };
> 
310c350,354
< 	} else if(shift)
---
> 	} else if (shift &&caps)
> 		c = kbtabshiftcaps[c];
> 	else if (caps)
> 		c = kbtabcaps[c];
> 	else if(shift)
317,319d360
< 	if(caps && c<='z' && c>='a')
< 		c += 'A' - 'a';
< 
475a517,518
> 	case 4:	kbtabcaps[scanc] = r; break;
> 	case 5:	kbtabshiftcaps[scanc] = r; break;
491a535,536
> 	case 4:	*r = kbtabcaps[*sc]; return 1;
> 	case 5:	*r = kbtabshiftcaps[*sc]; return 1;

Re: [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

Re: [9fans] kbd.c

[Boyd Roberts]

    They are changing this further to let the driver accept
    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.