9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] kbd.c
@ 2002-03-30 21:08 rob pike, esq.
  2002-03-31 18:58 ` FJ Ballesteros
  0 siblings, 1 reply; 44+ messages in thread
From: rob pike, esq. @ 2002-03-30 21:08 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02 10:48 forsyth
  2002-04-02 10:56 ` Lucio De Re
  0 siblings, 1 reply; 44+ messages in thread
From: forsyth @ 2002-04-02 10:48 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02 10:42 forsyth
  2002-04-08 12:54 ` Andries Brouwer
  0 siblings, 1 reply; 44+ messages in thread
From: forsyth @ 2002-04-02 10:42 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02  9:31 forsyth
  2002-04-02  9:44 ` Boyd Roberts
  0 siblings, 1 reply; 44+ messages in thread
From: forsyth @ 2002-04-02  9:31 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02  8:28 Fco.J.Ballesteros
  0 siblings, 0 replies; 44+ messages in thread
From: Fco.J.Ballesteros @ 2002-04-02  8:28 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02  8:17 Fco.J.Ballesteros
  0 siblings, 0 replies; 44+ messages in thread
From: Fco.J.Ballesteros @ 2002-04-02  8:17 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02  5:04 plan9
  0 siblings, 0 replies; 44+ messages in thread
From: plan9 @ 2002-04-02  5:04 UTC (permalink / raw)
  To: 9fans


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
> 



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-02  1:58 okamoto
  0 siblings, 0 replies; 44+ messages in thread
From: okamoto @ 2002-04-02  1:58 UTC (permalink / raw)
  To: 9fans

>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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-01 14:01 rob pike, esq.
  0 siblings, 0 replies; 44+ messages in thread
From: rob pike, esq. @ 2002-04-01 14:01 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-01  1:54 okamoto
  0 siblings, 0 replies; 44+ messages in thread
From: okamoto @ 2002-04-01  1:54 UTC (permalink / raw)
  To: 9fans

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

Kenji -- just from my curiosity :-)



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-04-01  1:40 okamoto
  0 siblings, 0 replies; 44+ messages in thread
From: okamoto @ 2002-04-01  1:40 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-31 19:35 andrey mirtchovski
  0 siblings, 0 replies; 44+ messages in thread
From: andrey mirtchovski @ 2002-03-31 19:35 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-31 14:48 bwc
  2002-03-31 15:13 ` Boyd Roberts
  2002-03-31 17:06 ` Digby Tarvin
  0 siblings, 2 replies; 44+ messages in thread
From: bwc @ 2002-03-31 14:48 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-31 10:24 forsyth
  0 siblings, 0 replies; 44+ messages in thread
From: forsyth @ 2002-03-31 10:24 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-31  5:40 rob pike, esq.
  0 siblings, 0 replies; 44+ messages in thread
From: rob pike, esq. @ 2002-03-31  5:40 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-30 23:13 Russ Cox
  0 siblings, 0 replies; 44+ messages in thread
From: Russ Cox @ 2002-03-30 23:13 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-30 21:28 rob pike, esq.
  2002-03-30 22:41 ` Richard
                   ` (3 more replies)
  0 siblings, 4 replies; 44+ messages in thread
From: rob pike, esq. @ 2002-03-30 21:28 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-30 21:20 Geoff Collyer
  2002-04-08 12:47 ` Matthew C Weigel
  0 siblings, 1 reply; 44+ messages in thread
From: Geoff Collyer @ 2002-03-30 21:20 UTC (permalink / raw)
  To: 9fans

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.



^ permalink raw reply	[flat|nested] 44+ messages in thread
* Re: [9fans] kbd.c
@ 2002-03-30 21:10 rob pike, esq.
  0 siblings, 0 replies; 44+ messages in thread
From: rob pike, esq. @ 2002-03-30 21:10 UTC (permalink / raw)
  To: 9fans

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



^ permalink raw reply	[flat|nested] 44+ messages in thread
* [9fans] kbd.c
@ 2002-03-23 12:01 George Bronnikov
  2002-03-30 21:05 ` FJ Ballesteros
  0 siblings, 1 reply; 44+ messages in thread
From: George Bronnikov @ 2002-03-23 12:01 UTC (permalink / raw)
  To: 9fans

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

^ permalink raw reply	[flat|nested] 44+ messages in thread

end of thread, other threads:[~2002-04-08 12:54 UTC | newest]

Thread overview: 44+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-30 21:08 [9fans] kbd.c rob pike, esq.
2002-03-31 18:58 ` FJ Ballesteros
2002-04-01  0:36   ` Boyd Roberts
2002-04-01  0:42   ` Boyd Roberts
  -- strict thread matches above, loose matches on Subject: below --
2002-04-02 10:48 forsyth
2002-04-02 10:56 ` Lucio De Re
2002-04-02 10:42 forsyth
2002-04-08 12:54 ` Andries Brouwer
2002-04-02  9:31 forsyth
2002-04-02  9:44 ` Boyd Roberts
2002-04-02  8:28 Fco.J.Ballesteros
2002-04-02  8:17 Fco.J.Ballesteros
2002-04-02  5:04 plan9
2002-04-02  1:58 okamoto
2002-04-01 14:01 rob pike, esq.
2002-04-01  1:54 okamoto
2002-04-01  1:40 okamoto
2002-03-31 19:35 andrey mirtchovski
2002-03-31 14:48 bwc
2002-03-31 15:13 ` Boyd Roberts
2002-03-31 17:06 ` Digby Tarvin
2002-03-31 10:24 forsyth
2002-03-31  5:40 rob pike, esq.
2002-03-30 23:13 Russ Cox
2002-03-30 21:28 rob pike, esq.
2002-03-30 22:41 ` Richard
2002-03-30 22:47 ` Digby Tarvin
2002-03-31 11:26   ` kazumi iwane
2002-03-31 12:21     ` kazumi iwane
2002-03-31  2:47 ` kazumi iwane
2002-03-31 18:32 ` George Bronnikov
2002-04-01  0:47   ` Boyd Roberts
2002-04-01  6:50     ` George Bronnikov
2002-04-01  7:22       ` Lucio De Re
2002-04-01 11:35         ` Boyd Roberts
2002-04-01 16:27         ` kazumi iwane
2002-04-01 16:33           ` Lucio De Re
2002-04-01 11:34       ` Boyd Roberts
2002-03-30 21:20 Geoff Collyer
2002-04-08 12:47 ` Matthew C Weigel
2002-03-30 21:10 rob pike, esq.
2002-03-23 12:01 George Bronnikov
2002-03-30 21:05 ` FJ Ballesteros
2002-03-31 12:45   ` Boyd Roberts

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).