9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] Russian keyboard
@ 2002-09-26  7:23 Fco.J.Ballesteros
  2002-09-26 20:56 ` George Bronnikov
  0 siblings, 1 reply; 34+ messages in thread
From: Fco.J.Ballesteros @ 2002-09-26  7:23 UTC (permalink / raw)
  To: 9fans

> One more thing is missing: you cannot create a new kbmap on the
> fly, only modify an existing one.  That should not be hard to
> fix, though.

What's the problem with that?
You can modify one of the maps that you're not going to use.



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-10-01  7:09 Andrew Simmons
  0 siblings, 0 replies; 34+ messages in thread
From: Andrew Simmons @ 2002-10-01  7:09 UTC (permalink / raw)
  To: 9fans

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

Jim Choate wrote:
> (mark my words).

0/10 for content, 2/10 for grammar and spelling, 10/10 for tedium.

[-- Attachment #2: Type: text/html, Size: 247 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-30 12:12 Skip Tavakkolian
  2002-09-30 15:58 ` LacOniC
  0 siblings, 1 reply; 34+ messages in thread
From: Skip Tavakkolian @ 2002-09-30 12:12 UTC (permalink / raw)
  To: 9fans

In company the size of Lucent, it must have been a monumental task
to get something of Plan9's significance released to the public --
with its type of license -- at a time when everyone's goal is to
generate (short term) revenue.

Not understanding that shows a lack of imagination, or plain insensitivity.

> Lucent -has- been the primary factor in holding Plan 9 back for
> at least 10 years now. Do I recognize the fact that this will continue?
> Yes. Do I think that treating Lucent 'nicely' by praising them will help?
> No.



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-30  4:21 Russ Cox
  2002-09-30  4:25 ` Jim Choate
  0 siblings, 1 reply; 34+ messages in thread
From: Russ Cox @ 2002-09-30  4:21 UTC (permalink / raw)
  To: 9fans

> What's wrong, afraid of a little competition?

This is exactly my point.  Why is it competition?

Russ


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-24 13:46 Fco.J.Ballesteros
  2002-09-25 20:28 ` George Bronnikov
  0 siblings, 1 reply; 34+ messages in thread
From: Fco.J.Ballesteros @ 2002-09-24 13:46 UTC (permalink / raw)
  To: 9fans

That's what we have right now.
In its present shape, you can both compile several maps to
be happy at boot time and also use /dev/kbmap to change the thing
at run time. There's only one thing missing, the rc script to
generate the xxmap.c from the /lib/kbmap/kb_xx.map file.


:  I don't see why there can't be a happy medium; compile in a basic map
:  or two, and then have /dev/kbmap for when you need to override it with
:  something different.
:
:  I agree with Goga; it's too much for the case of switching between
:  Russian and American layouts to recompile the kernel.  I had to type
:  some Russian the other day, and producing Cyrillic's with alt sequences
:  was extremely painful (and some of the sequences are, IMHO, funny).
:  That said, most of the time I'm typing in English; switching back and
:  forth between the two by cat'ing a file is fine with me, but having to
:  recompile the kernel is too much.





^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-24 13:45 Fco.J.Ballesteros
  0 siblings, 0 replies; 34+ messages in thread
From: Fco.J.Ballesteros @ 2002-09-24 13:45 UTC (permalink / raw)
  To: 9fans

:  sorry that I waste your time again, but what I need to paste into []
:  of the mkkbmap file for defining: kbtabalt_en, kbtabshift_en, kbtab_en
:  and

Nothing. mkkbmap looks for kbd_* entries in the CONF file for
the kernel. If you add kbd_en to CONF, mkkbmap will add kbtab*_en
entries to the output.

You just have to write your .c map (if it's not there) and add the map
to the config file (if want it to be compiled in); then mk your kernel.

hth





^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-24  2:42 anothy
  0 siblings, 0 replies; 34+ messages in thread
From: anothy @ 2002-09-24  2:42 UTC (permalink / raw)
  To: 9fans

i realize it's not directly on topic but i wanted to take the
oportunity to say i *really* like ktrans. both for its method
of composing the kanji, but (somewhat more to the point at
hand) for its ctl-X method of changing input methods. i
realize it's not the same as the /dev/kbmap issue (not
dealing with the modified keys, primarialy), but that may be
useful input to people looking at alternative methods of
switching maps. i've recently had a chance to use the
alternate language inputs on other systems (particularly
Mac OS X), and i find ktrans to be *much* nicer (and,
invariably, faster to make the transition).
just a note.
ア


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-24  0:46 Andrey S. Kukhar
  0 siblings, 0 replies; 34+ messages in thread
From: Andrey S. Kukhar @ 2002-09-24  0:46 UTC (permalink / raw)
  To: 9fans

sorry that I waste your time again, but what I need to paste into [] of the
mkkbmap file for defining: kbtabalt_en, kbtabshift_en,  kbtab_en and
kbtabesc1_en?

thanks,
-ask


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-23 20:41 Andrey S. Kukhar
  0 siblings, 0 replies; 34+ messages in thread
From: Andrey S. Kukhar @ 2002-09-23 20:41 UTC (permalink / raw)
  To: 9fans

hello all,
I can`t compile kernel with /dev/kbmap support. mk 'CONF=pcdisk' prints:

	../boot/libboot.a8 doesn't exist: assuming it will be an archive
	8c -FVw kbd.c
	mk: no recipe to make 'devkbmap.8' in directory /sys/src/9/pc
	kbd.c:80 name not declared: Latin
	kbd.c:100 name not declared: Latin
	kbd.c:120 name not declared: Latin
	kbd.c:321 name not declared: Latin
	kbd.c:370 name not declared: Latin

here is my pcdisk file (may be something not correct in it):

	dev
	         root
	         cons
	         arch
	         pnp             pci
	         env
        	 pipe
        	 proc
        	 mnt
        	 srv
        	 dup
        	 rtc
        	 ssl
        	 tls
        	 cap
        	 kprof

        	 ether           netif
        	 ip              arp chandial ip ipaux iproute netlog nullmedium
pktmedium ptclbsum386 inferno

	         draw            screen vga vgax
	         mouse           mouse
	         vga

	         sd
	         floppy          dma
	         lpt

	         audio           dma
	         pccard
	         i82365          cis
	         uart
	         usb

	         kbmap

	link
	         devpccard
	         devi82365
	         apm             apmjump
	         ether2000       ether8390
	         ether2114x      pci
	         ether589        etherelnk3
	         ether79c970     pci
	         ether8003       ether8390
	         ether82557      pci
	         etherec2t       ether8390
	         etherelnk3      pci
	         ethersink
	         ethermedium
	         pcmciamodem
	         netdevmedium
	         usbuhci

	misc
	         edf
	         archmp          mp apic

	         ipconfig.root
	         kfs.root
	         factotum.root
	         cfs.root

	         sdata           pci sdscsi
	         sd53c8xx                pci sdscsi
	         sdmylex                 pci sdscsi

	         uarti8250

	         vga3dfx                 +cur
	         vgaark2000pv    +cur
	         vgabt485        =cur
	         vgaclgd542x     +cur
	         vgaclgd546x     +cur
	         vgact65545      +cur
	         vgacyber938x    +cur
	         vgaet4000       +cur
	         vgahiqvideo     +cur
	         vgai81x         +cur
	         vgamach64xx     +cur
	         vgamga2164w     +cur
	         vganeomagic     +cur
	         vgargb524       =cur
	         vgas3           +cur vgasavage
	         vgat2r4                 +cur
	         vgatvp3020      =cur
	         vgatvp3026      =cur
	         vgavmware       +cur
	         vganvidia       +cur

	ip
	         il
	         tcp
	         udp
	         ipifc
	         icmp

	port
	         int cpuserver = 0;

	boot boot #S/sdC0/
	         il
	         local

thanks,
-ask


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-23 13:40 Fco.J.Ballesteros
  0 siblings, 0 replies; 34+ messages in thread
From: Fco.J.Ballesteros @ 2002-09-23 13:40 UTC (permalink / raw)
  To: 9fans

Did you tried extracting the kbd.tgz files from
http://plan9.escet.urjc.es/ ?

Otherwise, things will be missing for the compilation.


^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-23  8:04 Fco.J.Ballesteros
  0 siblings, 0 replies; 34+ messages in thread
From: Fco.J.Ballesteros @ 2002-09-23  8:04 UTC (permalink / raw)
  To: 9fans

Excuse me for attaching the whole message to my previous reply.
I'm sorry.



^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: [9fans] Russian keyboard
@ 2002-09-23  8:00 Fco.J.Ballesteros
  2002-09-23 19:09 ` George Bronnikov
  0 siblings, 1 reply; 34+ messages in thread
From: Fco.J.Ballesteros @ 2002-09-23  8:00 UTC (permalink / raw)
  To: 9fans

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

:  sent to /dev/kbmap)?  What are the disadvantages of such a scheme
:  compared to compiled-in maps?

A compiled map can be activated even before you get the
connection to the file system. That's useful, since usually
people have to type weird characters to choose their boot file
system (if other than default).

Here we compile the us and the spanish maps, and both students
(spanish map) and me (us map) can type using the preferred map
at the root / user / secstore passwd prompts.

I'll merge your map into the kbmap tar after generating a .c
file from your map file.

thanks a lot

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

[-- Attachment #2.1.1: Type: TEXT/PLAIN, Size: 938 bytes --]

Hello,

with some pushing from Andrey Kuchar (thanks!), I have made
a Russian keyboard map for use with nemo's keyboard drivers.
To use it, you need to compile the kernel with /dev/kbmap
support -- diffs to nemo's /sys/src/9/pcdisk attached.  Upon
startup (in /bin/termrc, preferably), you need to do

	bind -a '#О©╫' /dev
	cat /lib/kbmap/kbd_ru.map > /dev/kbmap

It replaces the Bulgarian keymap (I doubt anyone would want to
use both).

Now the question:

I don't like the idea of having lots of kbmaps compiled into
the kernel (That's why I didn't make kbmap_ru.c).  I'd probably
prefer several maps, initialized to kbmap_default, and
controlled via /dev/kbmap.  Should I make such changes?  Should
maps appear dynamically (for example, a map appears
when a "reset n" or "keymap n" message with a new n is
sent to /dev/kbmap)?  What are the disadvantages of such a scheme
compared to compiled-in maps?

	Goga

[-- Attachment #2.1.2: Type: TEXT/PLAIN, Size: 360 bytes --]

src/sys/src/9/pc/pcdisk:35 a /sys/src/9/pc/pcdisk:36,37
> 	kbmap
> 
src/sys/src/9/pc/pcdisk:49 d /sys/src/9/pc/pcdisk:50
< 	etherwavelan	wavelan devi82365 cis pci
src/sys/src/9/pc/pcdisk:93,99 d /sys/src/9/pc/pcdisk:93
< 	kbd_es
< 	kbd_fr
< 	kbd_uk
< 	kbd_jp
< #	this should be in the dev section
< #	as a "kbmap" entry, and not here.
< 	devkbmap

[-- Attachment #2.1.3.1: Type: text/plain, Size: 430 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="kbd_ru.map"
	Content-Transfer-Encoding: BASE64
	Content-ID: <Pine.LNX.4.44L.0209221445231.2471@corneja.rubinstein.mccme.ru>
	Content-Description:
	Content-Disposition: attachment; filename="kbd_ru.map"

[-- Attachment #2.1.3.2: kbd_ru.map.suspect --]
[-- Type: application/octet-stream, Size: 1076 bytes --]

reset 2
keymap 2
key	0x01	0x1b	0x1b
key	0x02	'1'		'!'
key	0x03	'2'		'"'
key	0x04	'3'		'#'
key 	0x05	'4'		'$'
key	0x06	'5'		':'
key	0x07	'6'		','
key	0x08	'7'		'.'
key	0x09	'8'		';'
key	0x0a		'9'		'('
key	0x0b	'0'		')'
key	0x0c		'-'		'_'
key	0x0d	'='		'+'
key	0x0e		0x08	0x08
key	0x0f		0x09	0x09
key	0x10	'й'		'Й'
key 	0x11	'ц'		'Ц'
key 	0x12	'у'		'У'
key 	0x13	'к'		'К'
key 	0x14	'е'		'Е'
key	0x15	'н'		'Н'
key 	0x16	'г'		'Г'
key	0x17	'ш'		'Ш'
key	0x18	'щ'		'Щ'
key 	0x19	'з'		'З'
key	0x1a		'х'		'Х'
key	0x1b	'ъ'		'Ъ'
key	0x1c		0x0a		0x0a
key	0x1e		'ф'		'Ф'
key	0x1f		'ы'		'Ы'
key	0x20	'в'		'В'
key	0x21	'а'		'А'
key	0x22	'п'		'П'
key	0x23	'р'		'Р'
key	0x24	'о'		'О'
key	0x25	'л'		'Л'
key	0x26	'д'		'Д'
key	0x27	'ж'		'Ж'
key	0x28	'э'		'Э'
key	0x29	'ё'		'Ё'
key	0x2b	0x5c		'|'
key	0x2c		'я'		'Я'
key	0x2d	'ч'		'Ч'
key	0x2e		'с'		'С'
key	0x2f		'м'		'М'
key	0x30	'и'		'И'
key	0x31	'т'		'Т'
key	0x32	'ь'		'Ь'
key	0x33	'б'		'Б'
key	0x34	'ю'		'Ю'
key	0x35	'/'		'?'

^ permalink raw reply	[flat|nested] 34+ messages in thread
* [9fans] Russian keyboard
@ 2002-09-22 10:45 George Bronnikov
  0 siblings, 0 replies; 34+ messages in thread
From: George Bronnikov @ 2002-09-22 10:45 UTC (permalink / raw)
  To: 9fans

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

Hello,

with some pushing from Andrey Kuchar (thanks!), I have made
a Russian keyboard map for use with nemo's keyboard drivers.
To use it, you need to compile the kernel with /dev/kbmap
support -- diffs to nemo's /sys/src/9/pcdisk attached.  Upon
startup (in /bin/termrc, preferably), you need to do

	bind -a '#О©╫' /dev
	cat /lib/kbmap/kbd_ru.map > /dev/kbmap

It replaces the Bulgarian keymap (I doubt anyone would want to
use both).

Now the question:

I don't like the idea of having lots of kbmaps compiled into
the kernel (That's why I didn't make kbmap_ru.c).  I'd probably
prefer several maps, initialized to kbmap_default, and
controlled via /dev/kbmap.  Should I make such changes?  Should
maps appear dynamically (for example, a map appears
when a "reset n" or "keymap n" message with a new n is
sent to /dev/kbmap)?  What are the disadvantages of such a scheme
compared to compiled-in maps?

	Goga

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

src/sys/src/9/pc/pcdisk:35 a /sys/src/9/pc/pcdisk:36,37
> 	kbmap
> 
src/sys/src/9/pc/pcdisk:49 d /sys/src/9/pc/pcdisk:50
< 	etherwavelan	wavelan devi82365 cis pci
src/sys/src/9/pc/pcdisk:93,99 d /sys/src/9/pc/pcdisk:93
< 	kbd_es
< 	kbd_fr
< 	kbd_uk
< 	kbd_jp
< #	this should be in the dev section
< #	as a "kbmap" entry, and not here.
< 	devkbmap

[-- Attachment #3.1: Type: text/plain, Size: 430 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="kbd_ru.map"
	Content-Transfer-Encoding: BASE64
	Content-ID: <Pine.LNX.4.44L.0209221445231.2471@corneja.rubinstein.mccme.ru>
	Content-Description:
	Content-Disposition: attachment; filename="kbd_ru.map"

[-- Attachment #3.2: kbd_ru.map.suspect --]
[-- Type: application/octet-stream, Size: 1076 bytes --]

reset 2
keymap 2
key	0x01	0x1b	0x1b
key	0x02	'1'		'!'
key	0x03	'2'		'"'
key	0x04	'3'		'#'
key 	0x05	'4'		'$'
key	0x06	'5'		':'
key	0x07	'6'		','
key	0x08	'7'		'.'
key	0x09	'8'		';'
key	0x0a		'9'		'('
key	0x0b	'0'		')'
key	0x0c		'-'		'_'
key	0x0d	'='		'+'
key	0x0e		0x08	0x08
key	0x0f		0x09	0x09
key	0x10	'й'		'Й'
key 	0x11	'ц'		'Ц'
key 	0x12	'у'		'У'
key 	0x13	'к'		'К'
key 	0x14	'е'		'Е'
key	0x15	'н'		'Н'
key 	0x16	'г'		'Г'
key	0x17	'ш'		'Ш'
key	0x18	'щ'		'Щ'
key 	0x19	'з'		'З'
key	0x1a		'х'		'Х'
key	0x1b	'ъ'		'Ъ'
key	0x1c		0x0a		0x0a
key	0x1e		'ф'		'Ф'
key	0x1f		'ы'		'Ы'
key	0x20	'в'		'В'
key	0x21	'а'		'А'
key	0x22	'п'		'П'
key	0x23	'р'		'Р'
key	0x24	'о'		'О'
key	0x25	'л'		'Л'
key	0x26	'д'		'Д'
key	0x27	'ж'		'Ж'
key	0x28	'э'		'Э'
key	0x29	'ё'		'Ё'
key	0x2b	0x5c		'|'
key	0x2c		'я'		'Я'
key	0x2d	'ч'		'Ч'
key	0x2e		'с'		'С'
key	0x2f		'м'		'М'
key	0x30	'и'		'И'
key	0x31	'т'		'Т'
key	0x32	'ь'		'Ь'
key	0x33	'б'		'Б'
key	0x34	'ю'		'Ю'
key	0x35	'/'		'?'

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

end of thread, other threads:[~2002-10-01  7:09 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-26  7:23 [9fans] Russian keyboard Fco.J.Ballesteros
2002-09-26 20:56 ` George Bronnikov
2002-09-26 21:30   ` Jack Johnson
2002-09-26 22:01     ` andrey mirtchovski
2002-09-27 11:19       ` Boyd Roberts
2002-09-30  2:20       ` Jim Choate
2002-09-30  2:35         ` Dan Cross
2002-09-30  2:58           ` Jim Choate
2002-09-30  3:14             ` Dan Cross
2002-09-30  4:15               ` Jim Choate
2002-09-30  4:33                 ` William Josephson
2002-09-30  4:34                   ` Jim Choate
2002-09-30  4:45                     ` William Josephson
2002-09-30  5:41                       ` Jim Choate
2002-09-30  6:23                         ` Tomas
2002-09-30 12:05                           ` Jim Choate
2002-09-30 11:21                             ` [9fans] why can't we all just get along? Sam
  -- strict thread matches above, loose matches on Subject: below --
2002-10-01  7:09 [9fans] Russian keyboard Andrew Simmons
2002-09-30 12:12 Skip Tavakkolian
2002-09-30 15:58 ` LacOniC
2002-09-30  4:21 Russ Cox
2002-09-30  4:25 ` Jim Choate
2002-09-24 13:46 Fco.J.Ballesteros
2002-09-25 20:28 ` George Bronnikov
2002-09-24 13:45 Fco.J.Ballesteros
2002-09-24  2:42 anothy
2002-09-24  0:46 Andrey S. Kukhar
2002-09-23 20:41 Andrey S. Kukhar
2002-09-23 13:40 Fco.J.Ballesteros
2002-09-23  8:04 Fco.J.Ballesteros
2002-09-23  8:00 Fco.J.Ballesteros
2002-09-23 19:09 ` George Bronnikov
2002-09-23 22:11   ` Dan Cross
2002-09-22 10:45 George Bronnikov

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