Re: [9fans] Russian keyboard

Re: [9fans] Russian keyboard

[Andrey S. Kukhar]

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

Re: [9fans] Russian keyboard

[Andrew Simmons]

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

Re: [9fans] Russian keyboard

[LacOniC]

mmm

Re: [9fans] Russian keyboard

[Skip Tavakkolian]

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.

Re: [9fans] Russian keyboard

[Jim Choate]

On Mon, 30 Sep 2002, Tomas wrote:

> On Mon, 30 Sep 2002 at 12:41am, Jim Choate wrote:
>
> > On Mon, 30 Sep 2002, William Josephson wrote:
> >
> > > Then why are you always the focal point of flame wars here?
> >
> > There is a significant difference of opinion about Plan 9 and
> > what it represent. A considerable number of the Plan 9
> > community haven't even twigged to this simple fact, yet.
> >
> > The only 'flame war' is from you folks. I haven't called
> > -anyone- anything.
>
> Wow. Just how short is your memory?

Those are my opinions. If you want to argue about them that is
-you- not me. Further, They clearly don't qualify as 'flame war' since
they are direct at -no individual-. Now, if they are not directed at any
individual exactly what has your dander up? What are you mad about, that
somebody is upset with Lucent and says it?

Again, that says more about -you- than me.

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.

Just look at the recent ver. 4 license fiasco for a recent example.
Desp[ite claims from the contrary that still isn't settled (mark my words).

Trying to sugar coat that in euphamism or allegory will do -nobody- any
good. Never has, never will.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[Tomas]

On Mon, 30 Sep 2002 at 12:41am, Jim Choate wrote:

> On Mon, 30 Sep 2002, William Josephson wrote:
>
> > Then why are you always the focal point of flame wars here?
>
> There is a significant difference of opinion about Plan 9 and
> what it represent. A considerable number of the Plan 9
> community haven't even twigged to this simple fact, yet.
>
> The only 'flame war' is from you folks. I haven't called
> -anyone- anything.

Wow. Just how short is your memory?

Writing "the head-up-the-ass attitude of Lucent and their
licenses", "Just another example of why you guys are lost in the
ozone", "You're clearly too complacent from getting your own way
all the time", and quoting "Never ascribe to malice what can be
better explained by incompetence or ignorance" are examples from
the past three days when you've been calling people all sorts of
things, explicitly or implicitly.

And as for you accusing people on this list for not getting their
facts straight, I refer you to Russ' response to your ridiculous
"I -do- take -great- exception to the attitude of these same
people that Plan 9 should be limited to 'research' applications"
statement.

[snip]

> I never start a fight, I'll damn well finish it if I have to.
> I'd rather not have to. I -always- start out with 'Excuse me',
> 'Please', 'If you wouldn't mind'.

You didn't when this whole argument started. Go back and check
the archives if you can't remeber that far back in time.

/Tomas

(Gonk, I'm sorry my first post to this list in almost a year had
to be on a subject such as this.)

Re: [9fans] Russian keyboard

[Jim Choate]

On Mon, 30 Sep 2002, William Josephson wrote:

> Then why are you always the focal point
> of flame wars here?

There is a significant difference of opinion about Plan 9 and what it
represent. A considerable number of the Plan 9 community haven't even
twigged to this simple fact, yet.

The only 'flame war' is from you folks. I haven't called -anyone-
anything. I -have- expressed my view on quite a few ideas and suggestions
that have been made. I will continue to do so. I also am a user of this
OS and have a right to express my views. As a developer or distributor you
have a responsibility to listen. If you don't, then expect the market to
move around or over you. There are after all only three choices in -any-
situation. Once the choice is made, the only remaining question is 'How'.

If that upsets you, that says more about you than me.

The fact is there is a contingent of Plan 9 users who want to  expand the
OS and include other OS'es into the mix (want tactless, go back and look
at some of the responces I received when I asked about creating a process
client for Linux or Windows). They believe that it has the potential for
significant social impact across the globe. This is against the wishes of
quite a few on this list, who would rather see it remain their personal
play thing. We sincerely wish that we could get help from these other users,
but -they- are the ones who are failing to compromise in their desires.
They fail to see, and accept, that Plan 9 has flown the coop and it no
longer is in their 'control' (not that it ever really was mind you). They
fail to see the fundamental point to the whole idea of Open Source
technology. The street has its own uses for technology (to borrow from
Gibson). That in fact within 4-5 years it has the potential to
significantly change the landscape, not only in computers but society writ
large. Hangar 18 and Plan 9 represent an opportunity to short circuit a
significant amount of work by large corporations which will deny
individuals their right to manage their own lives (Lucent being one of
them, if it survives it's current troubles).

-That- is truly a lack of tact (and imagination) on their part.

I am faced with two choices. Comply and fail in my goals, or pursue my
goals and deal with the conflict. I choose the latter (see three choices
above).

I have the same problem with Linux users. I've been thrown out of one of
the Linux user groups in Austin because I dared to talk against the
'OS Religous' wars. Bigots abound (most people are, and never know it,
which is probably why they are bigots - see Decarte about questioning
things and having an open mind). I simply wanted to create a SIG that
was focused on computer applications and technology rather than a single
OS. Did I stop? No, I went to another user group (which is why Austin has
four Linux user groups). What happened? We made progress and the Plan 9
community (and Linux, and MS, and etc.) at large will soon reap the
benefits of those efforts (and tenacity). Am I asking you to do it my
way? No, in fact I am building a system that will prevent any one party
from being able to control or dictate the process (ie tit-for-tat). Are
we excluding anyone from participating? No. Are we limiting it to a
single OS? No. The -only- thing we -are- saying is you (3rd person again)
can't tell -us- how to do it either.

Now who is being hard headed and confrontational here?

To you (3rd person unless the shoe fits) it's an ego trip, to  others of
us it's a way of life. We see the transfer of technology to the individual
(as opposed to corporate or government managers) as the -only- way out of
the worlds problems. God Money Fascists will sell your soul for their
profit (see Jefferson comment about British selling bails of hay and
civil rights).

Let your dreams die hard.

As to me being rude to you (3rd person, English sucks!), I guarantee that
it was in responce to -you- being rude or inconsiderate to me first (even
if you don't think so, which is the whole point of manners. I'll leave
the elucidation of that point as an exercise). I never start a fight, I'll
damn well finish it if I have to. I'd rather not have to. I -always- start
out with 'Excuse me', 'Please', 'If you wouldn't mind'. I also -always-
give the other party the option of saying 'No'. And when they do, I drop
it. I'll continue that until I am abused (on my terms, same as you decide
when you are abused on -your- terms). At that point my usual responce is to
go around. I don't have that option here. So, we bash heads.

Ta ta.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[William Josephson]

On Sun, Sep 29, 2002 at 11:34:32PM -0500, Jim Choate wrote:
> On Mon, 30 Sep 2002, William Josephson wrote:
> > > What's wrong, afraid of a little competition?
> >
> > No, just tired of people with no tact.
>
> Agreed.

Then why are you always the focal point
of flame wars here?

Re: [9fans] Russian keyboard

[Jim Choate]

On Mon, 30 Sep 2002, William Josephson wrote:

> > What's wrong, afraid of a little competition?
>
> No, just tired of people with no tact.

Agreed.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[William Josephson]

On Sun, Sep 29, 2002 at 11:15:22PM -0500, Jim Choate wrote:
> On Sun, 29 Sep 2002, Dan Cross wrote:
> > > So you think using Plan 9 in real world clustering is off topic?
> >
> > No, I just think that advertising is best done somewhere else.
>
> Your welcome to your opinion.
>
> The best place to advertise Plan 9 projects is where Plan 9 users
> congregate.

Take a look at RFC 1855; in particular the last point
at the bottom of page three.

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

No, just tired of people with no tact.

Re: [9fans] Russian keyboard

[Jim Choate]

On Mon, 30 Sep 2002, Russ Cox wrote:

> > What's wrong, afraid of a little competition?
>
> This is exactly my point.  Why is it competition?

If it isn't then why are you complaining instead of helping?

You folks are the ones -making- it competitive. Your way or
the highway. I'm posting here -asking- for help and offering
to help others.

You should get your facts straight.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[Russ Cox]

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

This is exactly my point.  Why is it competition?

Russ

Re: [9fans] Russian keyboard

[Jim Choate]

On Sun, 29 Sep 2002, Dan Cross wrote:

> > So you think using Plan 9 in real world clustering is off topic?
>
> No, I just think that advertising is best done somewhere else.

Your welcome to your opinion.

The best place to advertise Plan 9 projects is where Plan 9 users
congregate.

What's wrong, afraid of a little competition?


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[Dan Cross]

> So you think using Plan 9 in real world clustering is off topic?

No, I just think that advertising is best done somewhere else.

> Interesting viewpoint.

Interpret it as you like.

> Just another example of why you guys are lost in the ozone.

Aren't you the guy who usually flies off the handle?

Funny how your ``clustering'' post came in a thread about keyboard
drivers, which you added nothing to.  I'm done posting about it.

	- Dan C.

Re: [9fans] Russian keyboard

[Jim Choate]

On Sun, 29 Sep 2002, Dan Cross wrote:

> > ps Just in case anyone is interested...[note the one edit from the
> >    earlier version I sent out, I'll update that version soonest.]
>
> I don't think that anyone *is* interested.  However, I for one would be
> interested in you *not* sending such things to 9fans anymore; they're
> off topic.

So you think using Plan 9 in real world clustering is off topic?
Interesting viewpoint.

Just another example of why you guys are lost in the ozone.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[Dan Cross]

> ps Just in case anyone is interested...[note the one edit from the
>    earlier version I sent out, I'll update that version soonest.]

I don't think that anyone *is* interested.  However, I for one would be
interested in you *not* sending such things to 9fans anymore; they're
off topic.

	- Dan C.

Re: [9fans] Russian keyboard

[Jim Choate]

Zao,

Ni hao ma? Wo hen hao.

On Thu, 26 Sep 2002, andrey mirtchovski wrote:

> On Thu, 26 Sep 2002, Jack Johnson wrote:
>
> > Would it be ugly-but-adequate to just have two, a default and an (easily
> > alterable) alternate?
> >
>
>
> there are people who routinely use more than two languages in their
> day-to-day operations.

Wo yong qi ge yuyan.

Da svidanya, mi amigo.

ps Just in case anyone is interested...[note the one edit from the
   earlier version I sent out, I'll update that version soonest.]


        Hangar 18 - Goodwill Linux Group Cluster Project #1
                           Sept. 29, 2002


Author:

Hangar 18
James F. Choate Jr.
jchoate@open-forge.org
ravage@ssz.com
512-451-7087


Precis:

The purpose of this document is to describe the current state of
discussion between Hangar 18 and the Goodwill Linux Group. It's
purpose is to bring together the various parties involved around
a commen set of goals and process. The hope is that we can take
the current known resources and have a working facility by the
end of 2002.

This is a document 'in process'. It is revised and distributed
by the senior membership of Hangar 18 at this time. We are
actively looking for others to participate and flesh out this
skeleton of a proposal. All active contributors can expect to
be included in the 'Author' section.


Purpose:

To build a public access tit-for-tat cluster facility. The facility would
consist of multiple machines which ran Plan 9, Inferno, Linux, etc. in a
heterogeneous clustering environment. Commercial use of this facility is
not covered in this document, but it is not in principle excluded.

Once this facility was up and operating it would act as a central contact
point to bring other participants and their resources into play to expand
the abilities of the facility. Ideally this means that we would have
clusters connecting globally through the use of both clear text and
cryptographically secure virtual private networks.

In addition to clustering it would be involved in the expansion of
wireless network technology. In general this would be guerrilla or
neighborhood access points.


Location:

The location would need to be able to support approximately 20 machines.
At 110VAC @ 5A this implies a total load of 1kW [Oops, make that about
10kW]. The location would also need to be able to seat at least 10 people
in addition to the space taken by the cluster machines and management
workstations. The implication is that the space required would be approx.
equivalent to 20ft. by 20ft. Access would need to be controlled 24/365. It
would also need to have a small space setup for construction and repair of
the machines. Exact layout and source for these resources is not covered
here. It is assumed that the majority of the material and effort would
be donated gratis from the community.


Infrastructure:

A reasonable infrastructure would imply a Internet connection of at least
256kb/s up to T1 speeds or greater. The higher the better since at least
one proposed application is parallel rendering.

The current proposed split of machines is:

4ea	Plan 9 process servers
1ea	Plan 9 file system server
4ea	Linux machines (exact cluster architecture not defined)
2ea	Management workstation
4ea	General workstations for training purposes
5ea	Undefined usage per the location requirement above

The exact configuration and product load of these machines is not specified
in this document.


Support:

The majority of the support and maintenance would be provided by the
Hangar 18 and Goodwill Linux group members. Non-member participant would be
acceptable. For this to be a workable facility responce would need to be
-near- commercial levels. This means at least 24hr (ie next day) responce
on issues and problems. It is proposed that this aspect be taken care of by
the facility provider and senior Hangar 18 members. Others are welcome to
volunteer on a skills and need basis.



 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] Russian keyboard

[Boyd Roberts]

andrey mirtchovski wrote:

>... and have some mechanism to, say, 'cat mymap > /dev/kbmap'
>then switching between any number of non-default keyboard and keyboard
>bindings would be trivial.
>
>i believe someone was writing a modification to /dev/kbmap to that effect.
>
The stuff that Charles Forsyth did and I modified did exactly that.  I
always thought that compiled in maps were were ugly and just added
unnecessary bloat as most of the time all those tables wouldn't be used.

Re: [9fans] Russian keyboard

[andrey mirtchovski]

On Thu, 26 Sep 2002, Jack Johnson wrote:

> Would it be ugly-but-adequate to just have two, a default and an (easily
> alterable) alternate?
>


there are people who routinely use more than two languages in their
day-to-day operations. instead, if we make the default
easily alterable and have some mechanism to, say, 'cat mymap > /dev/kbmap'
then switching between any number of non-default keyboards and keyboard
bindings would be trivial.

i believe someone was writing a modification to /dev/kbmap to that effect.

not sure if there are any results though.

andrey

Re: [9fans] Russian keyboard

[Jack Johnson]

George Bronnikov wrote:
> I propose that the default kernel contain either several
> (2-3) instances of us kbmap (so that one could tamper with the
> second or third), or (better, IMHO) one us kbmap and a way to add
> more.  Of course, to cover your case, one could compile several
> different kbmaps into the kernel.

Would it be ugly-but-adequate to just have two, a default and an (easily
alterable) alternate?

-Jack

Re: [9fans] Russian keyboard

[George Bronnikov]

On Thu, 26 Sep 2002, Fco.J.Ballesteros wrote:

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

Sure.  But the (purely hypothetical) scenario I have in mind is
when I find myself in a foreign environment (say on a campus in a
US university) where the precompiled kernel has no support for
alternative keyboards at all (why would it?).

I propose that the default kernel contain either several
(2-3) instances of us kbmap (so that one could tamper with the
second or third), or (better, IMHO) one us kbmap and a way to add
more.  Of course, to cover your case, one could compile several
different kbmaps into the kernel.

	Goga

Re: [9fans] Russian keyboard

[Fco.J.Ballesteros]

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

Re: [9fans] Russian keyboard

[George Bronnikov]

On Tue, 24 Sep 2002, Fco.J.Ballesteros wrote:

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

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.

	Goga

Re: [9fans] Russian keyboard

[Fco.J.Ballesteros]

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.

Re: [9fans] Russian keyboard

[Fco.J.Ballesteros]

:  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

Re: [9fans] Russian keyboard

[anothy]

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

Re: [9fans] Russian keyboard

[Dan Cross]

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.

	- Dan C.

Re: [9fans] Russian keyboard

[Andrey S. Kukhar]

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

Re: [9fans] Russian keyboard

[George Bronnikov]

On Mon, 23 Sep 2002, Fco.J.Ballesteros wrote:

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

Now I see.  It turns out the typical Spanish usage differs from
the typical Russian usage.

Spanish keyboard contains mostly the same characters as US, only
in different order; thus it matters which layout you have when
you type something at boot time (those are mostly Latin letters,
I reckon).  A Russian user, on the other hand, uses both the
standard US layout and his own, and does not need Russian
keyboard until the system is up and running.

On the other hand, /dev/kbmap is crucial from my point of view:
it means I can tune the environment even if I don't wholly
control it.  When I was in America, I had to configure an X
terminal at the university in order to type emails home; with
your default setup of a Plan 9 terminal that would mean
recompiling the kernel, which is IMO an overkill for such a minor
task.

	Goga

Re: [9fans] Russian keyboard

[Fco.J.Ballesteros]

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

Otherwise, things will be missing for the compilation.

Re: [9fans] Russian keyboard

[Fco.J.Ballesteros]

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

Re: [9fans] Russian keyboard

[Fco.J.Ballesteros]

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

[9fans] Russian keyboard

[George Bronnikov]

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