kbmap for drawterm

kbmap for drawterm

[arisawa]

Hello,

key boards of my unix systems are mixture of ascii and japanese.
this is no problem if I am on vm because kbmap is already set for the plan9 terminals
and cpu servers reflect the setting.
however when I enter cpu server using drawterm I need to set /dev/kbmap
each time after entering cpu server, which is  annoying for me.
any idea to avoid this process?
for example to pass some info to cpu server.

Kenji Arisawa

Re: [9front] kbmap for drawterm

[cinap_lenrek]

it is not clear to me what your problem is. are you saying that
cpuing into the cpu server causes the keyboard layout to change
of the physical keyboard connected to the cpu server?

or that drawterm (which one?) gets whatever translated keys the
client operating system (windows, linux) it runs under gives it?

or are you saying that there is no predefined mechanism to set
the keyboard map of a machine?

maybe you set some stuff in your $home/lib/profile that i do
not know about?

please clarify.

--
cinap

Re: [9front] kbmap for drawterm

[arisawa]

Thanks for the response, cinap.

I have re-examined my problem.
all experiments below are drawterm to the same cpu server.

(a) from mac mini with japanese keyboard.
the drawterm is by russ. this case is ok. no problems.

(b) from mac book air and mac book pro both with japanes keyboard.
the drawterm is by cinap. this case has a problem.
the symptom is: key mapping is broken but totally ok.
the broken mapping is only four keys below:
single quote(') → double quotation(")
equal(=)		→ plus(+)
back quote(`)	→ tilde(~)
shift+0		→ right parenthesis())	# should be no effect
the photo of keyboard is at http://p9.nyx.link/jiskb.png

note1: kbmapping of drawterm on mac book by russ works correctly but his drawterms have fatal problem,
that is, key input "abc" results in output "aabbcc". this phenomena is only to my mac books.

note2: drawterm(by russ) on mac mini is old one, but drawterms(by russ) on mac books are recent one.

sorry cinap, my previous mail included some misleading explanations.
keyboard mapping works correctly(as JIS keyboard) as a whole except four keys.
I don’t know the suspicious origin of the problem.
looking the contents of /mnt/term/dev/kbmap (= /dev/kbmap), I convinced it ascii kbmap, but I don’t understand why that is harmless.

Kenji Arisawa

> 2016/06/01 2:35、cinap_lenrek@felloff.net のメール：
> 
> it is not clear to me what your problem is. are you saying that
> cpuing into the cpu server causes the keyboard layout to change
> of the physical keyboard connected to the cpu server?
> 
> or that drawterm (which one?) gets whatever translated keys the
> client operating system (windows, linux) it runs under gives it?
> 
> or are you saying that there is no predefined mechanism to set
> the keyboard map of a machine?
> 
> maybe you set some stuff in your $home/lib/profile that i do
> not know about?
> 
> please clarify.
> 
> --
> cinap

Re: [9front] kbmap for drawterm

[cinap_lenrek]

the kbmap file in /mnt/term/dev comes from kbdfs, which we
start on the server side thru rcpu to interpret keyup/keydown
and handle interrupt key [del].

it uses the keymap only to assign button codes to keys (for
example when we get "A", it will produce down event for
unshifted "a" rune when shift was also down). for normal
typing, we use the rune as we get it from drawterm directly,
without decomposition.

you can disable kbdfs with the -B flag. try this and see if it
has any difference.

you might add a debug print after the Nextmsg: label like:

/sys/src/cmd/aux/kbdfs/kbdfs.c:/^Nextmsg

fprint(2, "XXX %s\n", p);

--
cinap

Re: [9front] kbmap for drawterm

[arisawa]

thanks, I will try.

> 2016/06/01 16:55、cinap_lenrek@felloff.net のメール：
> 
> the kbmap file in /mnt/term/dev comes from kbdfs, which we
> start on the server side thru rcpu to interpret keyup/keydown
> and handle interrupt key [del].
> 
> it uses the keymap only to assign button codes to keys (for
> example when we get "A", it will produce down event for
> unshifted "a" rune when shift was also down). for normal
> typing, we use the rune as we get it from drawterm directly,
> without decomposition.
> 
> you can disable kbdfs with the -B flag. try this and see if it
> has any difference.
> 
> you might add a debug print after the Nextmsg: label like:
> 
> /sys/src/cmd/aux/kbdfs/kbdfs.c:/^Nextmsg
> 
> fprint(2, "XXX %s\n", p);
> 
> --
> cinap

Re: [9front] kbmap for drawterm

[arisawa]

thanks, cinap.
kbmap problem is resolved!

my kbdfs was old that was compiled at Mar 15.
I have updated today and found the problem is gone.
replacing new kbdfs by the old one reproduces the problem.
thanks again!

Kenji Arisawa


> 2016/06/01 16:55、cinap_lenrek@felloff.net のメール：
> 
> the kbmap file in /mnt/term/dev comes from kbdfs, which we
> start on the server side thru rcpu to interpret keyup/keydown
> and handle interrupt key [del].
> 
> it uses the keymap only to assign button codes to keys (for
> example when we get "A", it will produce down event for
> unshifted "a" rune when shift was also down). for normal
> typing, we use the rune as we get it from drawterm directly,
> without decomposition.
> 
> you can disable kbdfs with the -B flag. try this and see if it
> has any difference.
> 
> you might add a debug print after the Nextmsg: label like:
> 
> /sys/src/cmd/aux/kbdfs/kbdfs.c:/^Nextmsg
> 
> fprint(2, "XXX %s\n", p);
> 
> --
> cinap