[9fans] keyboard maps

[9fans] keyboard maps

[Fco.J.Ballesteros]

Two of my students ({jvergara,jgato}@gsyc.escet.urjc.es) have
changed the keyboard driver to support static maps allowing
to switch at run time between them using the function keys.

The set of maps desired can be specified in the config file.
New maps can be added by creating a .c file with just the tables.

Since some of you thought it was nice to be able to change the
map through devkbmap to learn to build new tables, I'm willing to
add that feature to this driver.

I'm also willing to collect whatever kbd tables you may have built
and add them to this driver.

Let me know what you think

The driver is at http://plan9.escet.urjc.es/export/kbd.tgz

hth

Re: [9fans] keyboard maps

[Boyd Roberts]

This does French azerty:

0	0x02	0x26
0	0x03	0xE9
0	0x04	0x22
0	0x05	0x27
0	0x06	0x28
0	0x07	0x2D
0	0x08	0xE8
0	0x09	0x5F
0	0x0A	0xE7
0	0x0B	0xE0
0	0x0C	0x29
0	0x10	0x61
0	0x11	0x7A
0	0x1A	0x5E
0	0x1B	0x24
0	0x1E	0x71
0	0x27	0x6D
0	0x29	0x2072
0	0x2B	0x2A
0	0x2C	0x77
0	0x32	0x2C
0	0x33	0x3B
0	0x34	0x3A
0	0x35	0x21
0	0x56	0x3C
1	0x02	0x31
1	0x03	0x32
1	0x04	0x33
1	0x05	0x34
1	0x06	0x35
1	0x07	0x36
1	0x08	0x37
1	0x09	0x38
1	0x0A	0x39
1	0x0B	0x30
1	0x0C	0xB0
1	0x10	0x41
1	0x11	0x5A
1	0x1B	0xA3
1	0x1E	0x51
1	0x27	0x4D
1	0x28	0x25
1	0x29	0x00
1	0x2B	0x3BC
1	0x2C	0x57
1	0x32	0x3F
1	0x33	0x2E
1	0x34	0x2F
1	0x35	0xA7
1	0x56	0x3E
3	0x03	0x7E
3	0x04	0x23
3	0x05	0x7B
3	0x06	0x5B
3	0x07	0x7c
3	0x08	0x60
3	0x09	0x5C
3	0x0A	0x5E
3	0x0B	0x40
3	0x0C	0x5D
3	0x0D	0x7D

Re: [9fans] keyboard maps

[Pavel Mihaylov]

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

На 14 май 2002 г. (вторник), в 14.37 часа, Fco.J.Ballesteros писа:
> Two of my students ({jvergara,jgato}@gsyc.escet.urjc.es) have
> changed the keyboard driver to support static maps allowing
> to switch at run time between them using the function keys.
> 

In kbd.h Altgr is defined as 0x38 which disagrees with the other
shift-state keys (Shift, Ctrl, etc). This is apparently the reason to
use variable gr, needed to differentiate between Altgr and simply 0x38
(which is actually '8'). I've changed the definition of Altgr to
Spec|0x67 (right after the other shift keys) and removed gr. I also
removed last_altgr which seems to be unused. All that fixed a bug for me
- when using keymaps without Altgr (i.e. us map) right Alt was supposed
to work as the left one but after pressing it I could enter any
arbitrary character _before_ collecting of compose sequence begins. The
revised kbd.c and kbd.h are attached. Btw, isn't it wise to rename Latin
from kbd.h to something more meaningful, such as Compose, since
composing is used to enter much more than Roman-script based characters?

Pavel



[-- Attachment #2.1: Type: text/plain, Size: 317 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-Disposition: attachment; filename=kbdfix.tgz
	Content-Type: application/x-gzip; name=kbdfix.tgz
	Content-Transfer-Encoding: base64

[-- Attachment #2.2: kbdfix.tgz.suspect --]
[-- Type: application/octet-stream, Size: 2732 bytes --]

Re: [9fans] keyboard maps

[Boyd Roberts]

Pavel Mihaylov wrote:
> In kbd.h Altgr is defined as 0x38 which disagrees with the other
> shift-state keys (Shift, Ctrl, etc). This is apparently the reason to
> use variable gr, needed to differentiate between Altgr and simply 0x38
> (which is actually '8').

IIRC this is so that the 'compose' keys on either side of the space bar
do the same thing.  On keyboards where Alg-Gr acts as a second 'shift'
this is a bad idea.

> I've changed the definition of Altgr to Spec|0x67

Yes that's right.  I'd also change Spec too:

    Spec=		0xF800,		/* Unicode private space */
    Altgr=		Spec|0x67,

If Spec is 0x80 it causes all sorts of woe when you hit Latin-1 characters.

> Btw, isn't it wise to rename Latin from kbd.h to something more meaningful,
> such as Compose, since composing is used to enter much more than Roman-script
> based characters?

Sure would, as it is confusing and actually indicates the collection of a multi
character sequence, which may not be related to 'latin' characters at all.

Re: [9fans] keyboard maps

[Pavel Mihaylov]

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

На 16 май 2002 г. (четвъртък), в 13.02 часа, Boyd Roberts писа:
> > I've changed the definition of Altgr to Spec|0x67
> 
> Yes that's right.  I'd also change Spec too:
> 
>     Spec=		0xF800,		/* Unicode private space */
>     Altgr=		Spec|0x67,
> 
> If Spec is 0x80 it causes all sorts of woe when you hit Latin-1 characters.
> 

I'm changing it back to 0x80 since key View (Down) is defined as
Spec|0x00. The value 0x80 for View is hardcoded in rio, acme and sam and
when redefined those programs no longer recognise View as a special key,
and just insert it as text. According to Unicode characters 0x0080 to
0x009F are designated as control ones so it is safe to use them for
special keys. The old definitions for the other Spec-based keys were
causing conflict with Latin-1 characters because Spec (0x80) was ORed
with values above 0x1F (0x20; 0x60 to 0x67) yielding valid accented
Latin characters. That's why I've also changed the definitions for those
keys to be ORed to saner values (0x10; 0x01 to 0x08). Most of those
special keys are interpreted only inside kbd.c so no conflict with
external hardcoded config is possible. Only Break (does it have any
special meaning in P9 or special interpretation?), PF and Middle (both
unassigned in current keymaps) are put into keyboard buffer. The updated
kbd.h is attached.

Regards,
Pavel


[-- Attachment #2.1: Type: text/plain, Size: 329 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-Disposition: attachment; filename=kbd.h
	Content-Transfer-Encoding: quoted-printable
	Content-Type: text/x-c-header; name=kbd.h; charset=UTF-8

[-- Attachment #2.2: kbd.h.suspect --]
[-- Type: application/octet-stream, Size: 1195 bytes --]


enum {
	Data=		0x60,		/* data port */

	Status=		0x64,		/* status port */
	 Inready=	0x01,		/*  input character ready */
	 Outbusy=	0x02,		/*  output busy */
	 Sysflag=	0x04,		/*  system flag */
	 Cmddata=	0x08,		/*  cmd==0, data==1 */
	 Inhibit=	0x10,		/*  keyboard/mouse inhibited */
	 Minready=	0x20,		/*  mouse character ready */
	 Rtimeout=	0x40,		/*  general timeout */
	 Parity=	0x80,

	Cmd=		0x64,		/* command port (write only) */

	Spec=		0x80,

	PF=		Spec|0x10,	/* num pad function key */
	View=		Spec|0x00,	/* view (shift window up) */
	KF=		0xF000,	/* function key (begin Unicode private space) */
	Shift=		Spec|0x01,
	Break=		Spec|0x02,
	Ctrl=			Spec|0x03,
	Compose=	Spec|0x04,
	Caps=		Spec|0x05,
	Num=		Spec|0x06,
	Middle=		Spec|0x07,
	Altgr=		Spec|0x08,
	No=		0x00,		/* peter */

	Home=		KF|13,
	Up=		KF|14,
	Pgup=		KF|15,
	Print=		KF|16,
	Left=		KF|17,
	Right=		KF|18,
	End=		'\r',
	Down=		View,
	Pgdown=		KF|19,
	Ins=		KF|20,
	Del=		0x7F,
	Scroll=		KF|21,
};


typedef struct Kbmap 
{
 char *name;
 Rune *kbtab;
 Rune *kbtabshift;
 Rune *kbtabesc1;
 Rune *kbtabalt;
}Kbmap;


extern Kbmap kbmaps[];
extern int nkbmaps;

Re: [9fans] keyboard maps

[Boyd Roberts]

Pavel Mihaylov wrote:
> I'm changing it back to 0x80 since key View (Down) is defined as
> Spec|0x00. The value 0x80 for View is hardcoded in rio, acme and sam and
> when redefined those programs no longer recognise View as a special key,
> and just insert it as text.

Are you sure you've taken into account that kbtab and kbtabesc1 map the
scan codes into Runes?  In View's case it should just be defined as 0x80.
It gets that value as a side effect of the value of Spec.

Admittedly I overlooked this case, but I never type View anyway.

> According to Unicode characters 0x0080 to
> 0x009F are designated as control ones so it is safe to use them for
> special keys.

I don't think the following would agree:

    http://www.unicode.org/charts/PDF/U0080.pdf

They may be well control values but some of them have a defined meaning.

Re: [9fans] keyboard maps

[Pavel Mihaylov]

На 21 май 2002 г. (вторник), в 13.43 часа, Boyd Roberts писа:
> Pavel Mihaylov wrote:
> > I'm changing it back to 0x80 since key View (Down) is defined as
> > Spec|0x00. The value 0x80 for View is hardcoded in rio, acme and sam and
> > when redefined those programs no longer recognise View as a special key,
> > and just insert it as text.
> 
> Are you sure you've taken into account that kbtab and kbtabesc1 map the
> scan codes into Runes?  In View's case it should just be defined as 0x80.
> It gets that value as a side effect of the value of Spec.
> 
Scan codes are irrelevant here. Interaction with all those key
definitions takes place _after_ scan codes were mapped to runes. And
even the special keys are defined as normal runes in the tables.

> Admittedly I overlooked this case, but I never type View anyway.
> 
> > According to Unicode characters 0x0080 to
> > 0x009F are designated as control ones so it is safe to use them for
> > special keys.
> 
> I don't think the following would agree:
> 
>     http://www.unicode.org/charts/PDF/U0080.pdf
> 
> They may be well control values but some of them have a defined meaning.
> 
Yes, that is correct. But as I said only Break leaves the kernel, and
possibly PF and Middle in future keymaps. For those keys we can possibly
choose other values from the U0080 control range (there are several
"just control" characters and two "private use" ones without predefined
meaning). The other Spec keys can be assigned arbitrary Unicode value
which is not intended to be typed as a normal character and not used in
Plan 9 as a control one. IMO, using the first characters in U0080 is OK
for all Spec keys as those "predefined control meanings" do control
nothing in Plan 9.

Regards,
Pavel

Re: [9fans] keyboard maps

[andrey mirtchovski]

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

here's a file for typinng in cyrillic, with the bulgarian keyboard
layout..  i've put the necessary changes to add it as the third
keyboard mapping, but i'm sure everyone on the list (who cares) is
able to do it by themselves, so no diff for any other files...

for those interested: bug or a feature?  the cyrillic characters in
p9's utf fonts lack a capital 'ъ'.  russian does not have it,
bulgarian does, even though we have only one word that starts with it
-- 'ъгъл', meaning 'angle'...

андрей

[-- Attachment #2: kbd_bg.c --]
[-- Type: text/plain, Size: 3325 bytes --]

/* bulgarian phonetic keyboard mapping. note the lack of capital 'ъ' */
#include	"u.h"
#include	"libc.h"
#include	"kbd.h"

/*
 * The codes at 0x79 and 0x81 are produed by the PFU Happy Hacking keyboard.
 * A 'standard' keyboard doesn't produce anything above 0x58.
 */
Rune kbtab_bg[] =
{
[0x00]	No,	0x1b,	'1',	'2',	'3',	'4',	'5',	'6',
[0x08]	'7',	'8',	'9',	'0',	'-',	'=',	'\b',	'\t',
[0x10]	'я',	'в,	'е',	'р',	'т',	'ъ',	'у',	'и',
[0x18]	'о',	'п',	'ш', 	'щ',	'\n',	Ctrl,	'а',	'с',
[0x20]	'д',	'ф',	'г',	'х',	'й',	'к',	'л',	';',
[0x28]	'\'',	'ч',	Shift,	'ю',	'з',	'ь',	'ц',	'ж',
[0x30]	'б',	'н',	'м',	',',	'.',	'/',	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,
};

Rune kbtabshift_bg[] =
{
[0x00]	No,	0x1b,	'!',	'@',	'#',	'$',	'%',	'^',
[0x08]	'&',	'*',	'(',	')',	'_',	'+',	'\b',	'\t',
[0x10]	'Я',	'В',	'Е',	'Р',	'Т',	'ъ',	'У',	'И',
[0x18]	'О',	'П',	'Ш',	'Щ',	'\n',	Ctrl,	'А',	'С',
[0x20]	'Д',	'Ф',	'Г',	'Х',	'Й',	'К',	'Л',	':',
[0x28]	'"',	'Ч',	Shift,	'Ю',	'З',	'ь',	'Ц',	'Ж',
[0x30]	'Б',	'Н',	'М',	'<',	'>',	'?',	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 kbtabesc1_bg[] =
{
[0x00]	No,	No,	No,	No,	No,	No,	No,	No,
[0x08]	No,	No,	No,	No,	No,	No,	No,	No,
[0x10]	No,	No,	No,	No,	No,	No,	No,	No,
[0x18]	No,	No,	No,	No,	'\n',	Ctrl,	No,	No,
[0x20]	No,	No,	No,	No,	No,	No,	No,	No,
[0x28]	No,	No,	Shift,	No,	No,	No,	No,	No,
[0x30]	No,	No,	No,	No,	No,	'/',	No,	Print,
[0x38]	Latin,	No,	No,	No,	No,	No,	No,	No,
[0x40]	No,	No,	No,	No,	No,	No,	Break,	Home,
[0x48]	Up,	Pgup,	No,	Left,	No,	Right,	No,	End,
[0x50]	Down,	Pgdown,	Ins,	Del,	No,	No,	No,	No,
[0x58]	No,	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,	No,	No,	No,	No,	No,
};
Rune kbtabalt_bg[] =
{
[0x00]	No,	No,	No,	No,	No,	No,	No,	No,
[0x08]	No,	No,	No,	No,	No,	No,	No,	No,
[0x10]	No,	No,	No,	No,	No,	No,	No,	No,
[0x18]	No,	No,	No,	No,	No,	No,	No,	No,
[0x20]	No,	No,	No,	No,	No,	No,	No,	No,
[0x28]	No,	No,	No,	No,	No,	No,	No,	No,
[0x30]	No,	No,	No,	No,	No,	No,	No,	No,
[0x38]	Latin,	No,	No,	No,	No,	No,	No,	No,
[0x40]	No,	No,	No,	No,	No,	No,	No,	No,
[0x48]	No,	No,	No,	No,	No,	No,	No,	No,
[0x50]	No,	No,	No,	No,	No,	No,	No,	No,
[0x58]	No,	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,	No,	No,	No,	No,	No,	No,	No,
};--upas-twknbbkoeqbzexbchfjdczjqva--

Re: [9fans] keyboard maps

[andrey mirtchovski]

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


> What is the Unicode value of the symbol?  Does it exist in
> Lucida?  More broadly, in what font doesn't it exist? There
> are many to choose from.

the characters exits in the fonts, but there's no way to type them
using a key sequence, hence they don't show up in /lib/keyboard, where
i was looking for them.  immediately after emailing the file i went to
unicode.org and found their appropriate unicode values:

0x042A = Ъ
0x042C = Ь

they most certainly show up in /lib/font/bit/pelm/euro.8.font
which is my console font of choice :)

attached is the revised kbd_bg.c file

andrey

[-- Attachment #2: kbd_bg.c --]
[-- Type: text/plain, Size: 3313 bytes --]

#include	"u.h"
#include	"libc.h"
#include	"kbd.h"

/*
 * The codes at 0x79 and 0x81 are produed by the PFU Happy Hacking keyboard.
 * A 'standard' keyboard doesn't produce anything above 0x58.
 */
Rune kbtab_bg[] =
{
[0x00]	No,	0x1b,	'1',	'2',	'3',	'4',	'5',	'6',
[0x08]	'7',	'8',	'9',	'0',	'-',	'=',	'\b',	'\t',
[0x10]	L'я',	L'в',	L'е',	L'р',	L'т',	L'ъ',	L'у',	L'и',
[0x18]	L'о',	L'п',	L'ш', 	L'щ',	'\n',	Ctrl,	L'а',	L'с',
[0x20]	L'д',	L'ф',	L'г',	L'х',	L'й',	L'к',	L'л',	';',
[0x28]	'\'',	L'ч',	Shift,	L'ю',	L'з',	L'ь',	L'ц',	L'ж',
[0x30]	L'б',	L'н',	L'м',	',',	'.',	'/',	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,
};

Rune kbtabshift_bg[] =
{
[0x00]	No,	0x1b,	'!',	'@',	'#',	'$',	'%',	'^',
[0x08]	'&',	'*',	'(',	')',	'_',	'+',	'\b',	'\t',
[0x10]	L'Я',	L'В',	L'Е',	L'Р',	L'Т',	L'Ъ',	L'У',	L'И',
[0x18]	L'О',	L'П', 	L'Ш',	L'Щ',	'\n',	Ctrl,	L'А',	L'С',
[0x20]	L'Д',	L'Ф',	L'Г',	L'Х',	L'Й',	L'К',	L'Л',	':',
[0x28]	'"',	L'Ч',	Shift,	L'Ю',	L'З',	L'Ь',	L'Ц',	L'Ж',
[0x30]	L'Б',	L'Н',	L'М',	'<',	'>',	'?',	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 kbtabesc1_bg[] =
{
[0x00]	No,	No,	No,	No,	No,	No,	No,	No,
[0x08]	No,	No,	No,	No,	No,	No,	No,	No,
[0x10]	No,	No,	No,	No,	No,	No,	No,	No,
[0x18]	No,	No,	No,	No,	'\n',	Ctrl,	No,	No,
[0x20]	No,	No,	No,	No,	No,	No,	No,	No,
[0x28]	No,	No,	Shift,	No,	No,	No,	No,	No,
[0x30]	No,	No,	No,	No,	No,	'/',	No,	Print,
[0x38]	Latin,	No,	No,	No,	No,	No,	No,	No,
[0x40]	No,	No,	No,	No,	No,	No,	Break,	Home,
[0x48]	Up,	Pgup,	No,	Left,	No,	Right,	No,	End,
[0x50]	Down,	Pgdown,	Ins,	Del,	No,	No,	No,	No,
[0x58]	No,	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,	No,	No,	No,	No,	No,
};
Rune kbtabalt_bg[] =
{
[0x00]	No,	No,	No,	No,	No,	No,	No,	No,
[0x08]	No,	No,	No,	No,	No,	No,	No,	No,
[0x10]	No,	No,	No,	No,	No,	No,	No,	No,
[0x18]	No,	No,	No,	No,	No,	No,	No,	No,
[0x20]	No,	No,	No,	No,	No,	No,	No,	No,
[0x28]	No,	No,	No,	No,	No,	No,	No,	No,
[0x30]	No,	No,	No,	No,	No,	No,	No,	No,
[0x38]	Latin,	No,	No,	No,	No,	No,	No,	No,
[0x40]	No,	No,	No,	No,	No,	No,	No,	No,
[0x48]	No,	No,	No,	No,	No,	No,	No,	No,
[0x50]	No,	No,	No,	No,	No,	No,	No,	No,
[0x58]	No,	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,	No,	No,	No,	No,	No,	No,	No,
};--upas-poycldajitifoemmhshtvtudua--

Re: [9fans] keyboard maps

[rob pike, esq.]

> the cyrillic characters in
> p9's utf fonts lack a capital 'ъ'.

What is the Unicode value of the symbol?  Does it exist in
Lucida?  More broadly, in what font doesn't it exist? There
are many to choose from.

-rob

Re: [9fans] keyboard maps

[rob pike, esq.]

What key sequence should trigger them in /lib/keyboard?  We can
just add them.


-rob

Re: [9fans] keyboard maps

[Fco.J.Ballesteros]

All the maps you sent are in place.
http://plan9.escet.urjc.es/export/kbd.tgz

Would it be keyboard the right man page
to tell users about the Fn thing to change maps?

Re: [9fans] keyboard maps

[nigel]

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

I enclose a UK keyboard map. More changes will be required,
but this corresponds to the map I've used for a time.

I also attach mkkbmap with a fix to make it generate
nkbmaps correctly.

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

From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] keyboard maps
Date: Thu, 16 May 2002 12:00:39 +0200
Message-ID: <fc406cbeb0b9e7656b37a77398f75eae@plan9.escet.urjc.es>

All the maps you sent are in place.
http://plan9.escet.urjc.es/export/kbd.tgz

Would it be keyboard the right man page
to tell users about the Fn thing to change maps?

[-- Attachment #3: kbd_uk.c --]
[-- Type: text/plain, Size: 3165 bytes --]

#include	"u.h"
#include	"libc.h"
#include	"kbd.h"

/*
 * The codes at 0x79 and 0x81 are produed by the PFU Happy Hacking keyboard.
 * A 'standard' keyboard doesn't produce anything above 0x58.
 */
Rune kbtab_uk[] =
{
[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]	Compose,	' ',	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,	'\\',	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,
};

Rune kbtabshift_uk[] =
{
[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]	Compose,	' ',	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,	'|',	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 kbtabesc1_uk[] =
{
[0x00]	No,	No,	No,	No,	No,	No,	No,	No,
[0x08]	No,	No,	No,	No,	No,	No,	No,	No,
[0x10]	No,	No,	No,	No,	No,	No,	No,	No,
[0x18]	No,	No,	No,	No,	'\n',	Ctrl,	No,	No,
[0x20]	No,	No,	No,	No,	No,	No,	No,	No,
[0x28]	No,	No,	Shift,	No,	No,	No,	No,	No,
[0x30]	No,	No,	No,	No,	No,	'/',	No,	Print,
[0x38]	Compose,	No,	No,	No,	No,	No,	No,	No,
[0x40]	No,	No,	No,	No,	No,	No,	Break,	Home,
[0x48]	Up,	Pgup,	No,	Left,	No,	Right,	No,	End,
[0x50]	Down,	Pgdown,	Ins,	Del,	No,	No,	No,	No,
[0x58]	No,	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,	No,	No,	No,	No,	No,
};
Rune kbtabalt_uk[] =
{
[0x00]	No,	No,	No,	No,	No,	No,	No,	No,
[0x08]	No,	No,	No,	No,	No,	No,	No,	No,
[0x10]	No,	No,	No,	No,	No,	No,	No,	No,
[0x18]	No,	No,	No,	No,	No,	No,	No,	No,
[0x20]	No,	No,	No,	No,	No,	No,	No,	No,
[0x28]	No,	No,	No,	No,	No,	No,	No,	No,
[0x30]	No,	No,	No,	No,	No,	No,	No,	No,
[0x38]	Compose,	No,	No,	No,	No,	No,	No,	No,
[0x40]	No,	No,	No,	No,	No,	No,	No,	No,
[0x48]	No,	No,	No,	No,	No,	No,	No,	No,
[0x50]	No,	No,	No,	No,	No,	No,	No,	No,
[0x58]	No,	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,	No,	No,	No,	No,	No,	No,	No,
};

[-- Attachment #4: mkkbmap --]
[-- Type: text/plain, Size: 543 bytes --]

#!/bin/rc
echo '#include "u.h"'
echo '#include "kbd.h"'
echo

maps=`{grep kbd_ $CONF | sed 's/kbd_//g'}
if (~ $maps '')
	maps=us

for ( a in $maps) {
	echo 'extern Rune kbtab_'^$a^'[];'
	echo 'extern Rune kbtabshift_'^$a^'[];'
	echo 'extern Rune kbtabesc1_'^$a^'[];'
	echo 'extern Rune kbtabalt_'^$a^'[];'
}
echo
echo 'Kbmap kbmaps[NKBMAPS] ='
echo '{'
for ( a in $maps) {
	echo '	{kbtab_'^$a^',	kbtabshift_'^$a^',	kbtabesc1_'^$a^',	kbtabalt_'^$a'	},'
}
echo '};'


echo  'int nkbmaps='^`{grep kbd_ $CONF | wc -l}^';'

Re: [9fans] keyboard maps

[rob pike, esq.]

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

> Would it be keyboard the right man page
> to tell users about the Fn thing to change maps?
keyboard(6) sounds good. make it clear this applies
to the PC only, as it stands.

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

From: Fco.J.Ballesteros <nemo@plan9.escet.urjc.es>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] keyboard maps
Date: Thu, 16 May 2002 12:00:39 +0200
Message-ID: <fc406cbeb0b9e7656b37a77398f75eae@plan9.escet.urjc.es>

All the maps you sent are in place.
http://plan9.escet.urjc.es/export/kbd.tgz

Would it be keyboard the right man page
to tell users about the Fn thing to change maps?

[9fans] keyboard maps

[Joel Salomon]

Along with the key maps is there support for bidi text as in inferno's
brutus? utf.ms/ps/html says this is not implemented, but the papers
have not been updated  since they were written and this one is at
least 5 years old. There should, by now, be plenty of implementations
to model on.
Joel

Re: [9fans] keyboard maps

[Joel Salomon]

Joel Salomon <joelcsalomon@excite.com> wrote:
>Along with the key maps is there support for bidi text as in
inferno's brutus?
Sorry if I wasnt't clear - by bidi text I was refering to
bi-directional or right-to-left text as in Hebrew or Arabic.

Boustrophedon support would be nice, too if there was a language that
could use it ;)

>There should, by now, be plenty of implementations to model on.
Although I've never tried it, I am told Sun's Star/Open Office has
strong support for unicode/bidirectional text.

What about combining characters?

- Joel
Followup-To:
Distribution:
Organization: University of Bath Computing Services, UK
Keywords:
Cc:


--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@bath.ac.uk

[9fans] keyboard maps

[Fco.J.Ballesteros]

I've changed the processing of kbd maps in our local driver
to do all the kbdmap thing at user level (the code is in fact
inside the usb user-level kbd driver, that now also knows how
to work with a regular keyboard (i.e. a non-usb one)).

You'd need the sys/src/9/boot/boot.c, the sys/src/9/pc/kbd.c and
the sys/src/cmd/usb/hid/ files I've put in /n/sources/nemo.
We've been using it for a while and it seems to work fine.

Our boot(8) starts usbd and usb/usbhid. Usbhid services
the usb keyboard if it finds one, and the console keyboard
if it finds no usb kbd. In any case, it implements the maps and
the latin1 composition. Our kernel driver is servicing just a us
map.

BTW, we're no longer using what was known as the
`alternate keyboard driver' and therefore I removed it from
/n/sources/nemo. I sincerelly think that the new one can
service all of us well.

I've tried to put all the maps I had into the new program (usb/hid).
If any of you use it and have any problem with any map or any
other thing, let me know.

hth

PS: There are also manual pages updated under /n/sources/nemo

Re: [9fans] keyboard maps

[ron minnich]

On Mon, 17 Nov 2003, Fco.J.Ballesteros wrote:

> I've changed the processing of kbd maps in our local driver
> to do all the kbdmap thing at user level (the code is in fact
> inside the usb user-level kbd driver, that now also knows how
> to work with a regular keyboard (i.e. a non-usb one)).

this work you are doing with user-level USB is really interesting. It will
be neat if this turns into "usb outside the kernel" given the amazing
error-prone lockup nature of the usb chipsets we've seen. Supposing we can
push all this USB crud into user procs, do you think we'll be able to suck
up USB 2.0 at reasonable rates?

thanks
ron

Re: [9fans] keyboard maps

[Fco.J.Ballesteros]

> this work you are doing with user-level USB is really interesting. It will
> be neat if this turns into "usb outside the kernel" given the amazing
> error-prone lockup nature of the usb chipsets we've seen. Supposing we can
> push all this USB crud into user procs, do you think we'll be able to suck
> up USB 2.0 at reasonable rates?

I've only done a HID driver, all of the usb code was already there, and
btw, all of the configuration is in usbd outside the kernel. The kernel seems
to configure (almost) the bare minimum in usb(3).

I'd like to keep the usb stack outside the kernel just while seeing errors;
once it gets stable, I don't know if I wouldnt want to put it all back in the kernel
just to avoid complexity (more file systems, more binds, more levels of
indirection, etc.).

Regarding 2.0, I'm in the mood of using usb for almost any new piece of hw
we buy that is not integrated inside the PC. This means that sooner or later
we'll have usb 2.0, it depends on who needs this earlier, if we or other 9fans.

Re: [9fans] keyboard maps

[mirtchov]

I don't see kbd_bg.c, kbd_ru.c, kbd_fr.c, kbd_jp and kbd_uk.c there, have they
been removed?

andrey

Re: [9fans] keyboard maps

[Fco.J.Ballesteros]

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

The tables go now from rune to rune, not from scancode to rune.
This means that the tables are smaller. They are inside /sys/src/cmd/usb/hid/map.c
For example, this is the ukkbmap now:

Rmap ukkbmap[] = {
	{L'"',	L'@'},	// 0x0022 -> 0x0040
	{L'#',	L'£'},	// 0x0023 -> 0x00a3
	{L'α',	L'\\'},	// 0x0000 -> 0x005c
	{L'β',	L'|'},	// 0x0000 -> 0x007c
	{L'γ',	L'¬'},	// 0x0000 -> 0x00ac
	{L'@',	L'"'},	// 0x0040 -> 0x0022
	{L'\\',	L'#'},	// 0x005c -> 0x0023
	{L'|',	L'~'},	// 0x007c -> 0x007e
	{L'~',	L'¬'},	// 0x007e -> 0x00ac
	{0,	0},
};

You have a xxkbmap[] per keyboard type. Also, you may have a xxaltkbmap[] if
you happen to have AltGr.

The two arrays maps[] and altmaps[] in the same file (map.c) glue all the tables
together.

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

From: mirtchov@cpsc.ucalgary.ca
To: 9fans@cse.psu.edu
Subject: Re: [9fans] keyboard maps
Date: Mon, 17 Nov 2003 12:56:51 -0700
Message-ID: <82daa8d2f0623077fcd23f57b21dd246@plan9.ucalgary.ca>

I don't see kbd_bg.c, kbd_ru.c, kbd_fr.c, kbd_jp and kbd_uk.c there, have they
been removed?

andrey

[9fans] keyboard maps

[David Presotto]

Anyone have keyboard maps other than qwerty and azerty for the
Boyd/Forsyth devkbmap stuff?

[9fans] keyboard maps

[Heiko Dudzus]

After making a replica/pull today, I have problems with the kbmaps in
/sys/lib/kbmap. The third field of each entry (value of unicode
character) has changed from hexadecimal value to literal
representation (e.g. 'o instead of 0x6f and ^[ instead of 0x1b).

Writing a kbmap with representations like ^X for control characters
to /dev/kbmap fails with Ebadarg: "bad arg in system call" (although
that representation conforms to the new version of kbmap(3)).

The kernel is 9pc (binary from sources), dated on Oct 27.  

I stepped back to the old kbmaps as a workaround but thought I should
mention the problem. 

Re: [9fans] keyboard maps

[Russ Cox]

new kernels should be on sources tomorrow,
or you can compile a new one yourself
with the sources you already have.
sorry for the inconvenience.

On 11/1/05, Heiko Dudzus <heiko.dudzus@gmx.de> wrote:
> After making a replica/pull today, I have problems with the kbmaps in
> /sys/lib/kbmap. The third field of each entry (value of unicode
> character) has changed from hexadecimal value to literal
> representation (e.g. 'o instead of 0x6f and ^[ instead of 0x1b).
>
> Writing a kbmap with representations like ^X for control characters
> to /dev/kbmap fails with Ebadarg: "bad arg in system call" (although
> that representation conforms to the new version of kbmap(3)).
>
> The kernel is 9pc (binary from sources), dated on Oct 27.
>
> I stepped back to the old kbmaps as a workaround but thought I should
> mention the problem.
>

Re: [9fans] keyboard maps

[Heiko Dudzus]

Russ Cox wrote:
> new kernels should be on sources tomorrow,
> or you can compile a new one yourself
> with the sources you already have.
> sorry for the inconvenience.

Ok, that works. Thanks for the hint.