Discussion:
[9fans] Raspberry Pi: keyboard layout
(too old to reply)
Murray Colpman
2012-12-03 00:45:29 UTC
Permalink
Hi all,

I'm an absolute beginner to Plan 9, I just installed it on my Raspberry
Pi for fun to have a see what it's all about. I understand this being a
very new build there are likely to be some issues, so do know that I'm
not holding my not-so-smooth experience against Plan 9 ;)

After a lot of wrangling with getting it compatible with my custom boot
menu (actually a very hacky Linux binary that shoves the necessary
config files into the Raspberry Pi boot partition and reboots, each OS
having to manually put the boot menu config files back in place on
boot), helped by some very nice people in #plan9 on Freenode, I now move
onto the other problems.

The biggest one for me, being a Dvorak user, is that I cannot get the
keyboard layouts working. I'm starting to form a vague idea in my head
about how Plan 9 is working, but I probably have a lot of things wrong,
so do bear with me.

When I run the kbmap program, attempting to set a map flashes up an
error about not being able to find /dev/kbmap. Looking at the manpages,
it seems that /dev/kbmap is supposed to be brought in with bind -a
'#kappa' /dev (with kappa obviously replaced with the actual kappa
letter). I did snarf the kappa from the manpage, and I also tried typing
it on the keyboard in various ways (compose, *, k for instance), so I
don't think that the issue is that I'm unable to type kappa correctly.
Anyway, when I run this bind command, I get "bind: #kappa: unknown
device in # filename" (again, kappa replaced with the actual kappa).


Any ideas?


Thanks a lot,
Murray Colpman.
Erik Quanstrom
2012-12-03 00:57:41 UTC
Permalink
I'd guess the kernel doesn't have that device built in.

- erik
Post by Murray Colpman
Hi all,
I'm an absolute beginner to Plan 9, I just installed it on my Raspberry
Pi for fun to have a see what it's all about. I understand this being a
very new build there are likely to be some issues, so do know that I'm
not holding my not-so-smooth experience against Plan 9 ;)
After a lot of wrangling with getting it compatible with my custom boot
menu (actually a very hacky Linux binary that shoves the necessary
config files into the Raspberry Pi boot partition and reboots, each OS
having to manually put the boot menu config files back in place on
boot), helped by some very nice people in #plan9 on Freenode, I now move
onto the other problems.
The biggest one for me, being a Dvorak user, is that I cannot get the
keyboard layouts working. I'm starting to form a vague idea in my head
about how Plan 9 is working, but I probably have a lot of things wrong,
so do bear with me.
When I run the kbmap program, attempting to set a map flashes up an
error about not being able to find /dev/kbmap. Looking at the manpages,
it seems that /dev/kbmap is supposed to be brought in with bind -a
'#kappa' /dev (with kappa obviously replaced with the actual kappa
letter). I did snarf the kappa from the manpage, and I also tried typing
it on the keyboard in various ways (compose, *, k for instance), so I
don't think that the issue is that I'm unable to type kappa correctly.
Anyway, when I run this bind command, I get "bind: #kappa: unknown
device in # filename" (again, kappa replaced with the actual kappa).
Any ideas?
Thanks a lot,
Murray Colpma
Murray Colpman
2012-12-03 01:05:30 UTC
Permalink
Thanks. Is it likely to be in some form of module, then (does Plan 9
have those?) that I have to manually load, or would I have to recompile
the whole kernel to get it?

In /sys/src/9/port/ there is a devkbmap.c so presumably I would want to
make sure that file gets compiled in. If I will need to recompile the
kernel, is /sys/src/9/port actually the source for the kernel that is
included in the distribution? How do I configure the kernel to include
this part?

Thanks,
Murray Colpman.
Post by Erik Quanstrom
I'd guess the kernel doesn't have that device built in.
- erik
Post by Murray Colpman
Hi all,
I'm an absolute beginner to Plan 9, I just installed it on my Raspberry
Pi for fun to have a see what it's all about. I understand this being a
very new build there are likely to be some issues, so do know that I'm
not holding my not-so-smooth experience against Plan 9 ;)
After a lot of wrangling with getting it compatible with my custom boot
menu (actually a very hacky Linux binary that shoves the necessary
config files into the Raspberry Pi boot partition and reboots, each OS
having to manually put the boot menu config files back in place on
boot), helped by some very nice people in #plan9 on Freenode, I now move
onto the other problems.
The biggest one for me, being a Dvorak user, is that I cannot get the
keyboard layouts working. I'm starting to form a vague idea in my head
about how Plan 9 is working, but I probably have a lot of things wrong,
so do bear with me.
When I run the kbmap program, attempting to set a map flashes up an
error about not being able to find /dev/kbmap. Looking at the manpages,
it seems that /dev/kbmap is supposed to be brought in with bind -a
'#kappa' /dev (with kappa obviously replaced with the actual kappa
letter). I did snarf the kappa from the manpage, and I also tried typing
it on the keyboard in various ways (compose, *, k for instance), so I
don't think that the issue is that I'm unable to type kappa correctly.
Anyway, when I run this bind command, I get "bind: #kappa: unknown
device in # filename" (again, kappa replaced with the actual kappa).
Any ideas?
Thanks a lot,
Murray Colpman.
Bakul Shah
2012-12-03 01:08:58 UTC
Permalink
Post by Murray Colpman
When I run the kbmap program, attempting to set a map flashes up an
error about not being able to find /dev/kbmap. Looking at the manpages,
it seems that /dev/kbmap is supposed to be brought in with bind -a
'#kappa' /dev (with kappa obviously replaced with the actual kappa
letter). I did snarf the kappa from the manpage, and I also tried typing
it on the keyboard in various ways (compose, *, k for instance), so I
don't think that the issue is that I'm unable to type kappa correctly.
Anyway, when I run this bind command, I get "bind: #kappa: unknown
device in # filename" (again, kappa replaced with the actual kappa).
You need to compile the driver in. Add
kbmap
to the dev section in config file /sys/src/9/bcm/pi. mk and
then copy 9pi to the dos partition.

dossrv -f /dev/sdM0/dos
mount -c /sv/dos /n/dos
cp /sys/src/9/bcm/9pi /n/dos/9pi
fshalt
Murray Colpman
2012-12-03 01:33:03 UTC
Permalink
Post by Bakul Shah
Post by Murray Colpman
When I run the kbmap program, attempting to set a map flashes up an
error about not being able to find /dev/kbmap. Looking at the manpages,
it seems that /dev/kbmap is supposed to be brought in with bind -a
'#kappa' /dev (with kappa obviously replaced with the actual kappa
letter). I did snarf the kappa from the manpage, and I also tried typing
it on the keyboard in various ways (compose, *, k for instance), so I
don't think that the issue is that I'm unable to type kappa correctly.
Anyway, when I run this bind command, I get "bind: #kappa: unknown
device in # filename" (again, kappa replaced with the actual kappa).
You need to compile the driver in. Add
kbmap
to the dev section in config file /sys/src/9/bcm/pi. mk and
then copy 9pi to the dos partition.
dossrv -f /dev/sdM0/dos
mount -c /sv/dos /n/dos
cp /sys/src/9/bcm/9pi /n/dos/9pi
fshalt
Thank you very much for the instructions!

Just tried it, kbmap now works perfectly, and I have now set the
keyboard map in my lib/profile. It all works :D - now I just have to
hack together a UK Dvorak - the map files look easy enough to fiddle
with. I'll do this tomorrow as I should really be sleeping now, though.

Thanks a lot!
Murray Colpman.
Christopher Wilson
2012-12-03 02:10:32 UTC
Permalink
I seem to remember that there is already a dvorak key map somewhere in Plan
9. I was able to just use it.
Post by Murray Colpman
On Mon, 03 Dec 2012 00:45:29 GMT Murray Colpman <
Post by Murray Colpman
When I run the kbmap program, attempting to set a map flashes up an
error about not being able to find /dev/kbmap. Looking at the manpages,
it seems that /dev/kbmap is supposed to be brought in with bind -a
'#kappa' /dev (with kappa obviously replaced with the actual kappa
letter). I did snarf the kappa from the manpage, and I also tried typing
it on the keyboard in various ways (compose, *, k for instance), so I
don't think that the issue is that I'm unable to type kappa correctly.
Anyway, when I run this bind command, I get "bind: #kappa: unknown
device in # filename" (again, kappa replaced with the actual kappa).
You need to compile the driver in. Add
kbmap
to the dev section in config file /sys/src/9/bcm/pi. mk and
then copy 9pi to the dos partition.
dossrv -f /dev/sdM0/dos
mount -c /sv/dos /n/dos
cp /sys/src/9/bcm/9pi /n/dos/9pi
fshalt
Thank you very much for the instructions!
Just tried it, kbmap now works perfectly, and I have now set the
keyboard map in my lib/profile. It all works :D - now I just have to
hack together a UK Dvorak - the map files look easy enough to fiddle
with. I'll do this tomorrow as I should really be sleeping now, though.
Thanks a lot!
Murray Colpman.
Richard Miller
2012-12-03 09:42:35 UTC
Permalink
Sorry, I'll add kbmap to the standard config file.
Christian Neukirchen
2012-12-03 16:23:55 UTC
Permalink
Post by Richard Miller
Sorry, I'll add kbmap to the standard config file.
Do you plan to provide a pull-able version of your tree?
--
Christian Neukirchen <***@gmail.com> http://chneukirchen.org
Richard Miller
2012-12-03 16:48:52 UTC
Permalink
Post by Christian Neukirchen
Do you plan to provide a pull-able version of your tree?
The bcm2835 kernel may go into the standard distribution eventually
(as /sys/src/9/bcm). Replica/pull is a bit problematic at present
because the arm binaries aren't being built on sources, and the
default /dist/replica/network will pull in all the 386 binaries
which you might not want.

I think pull will need to be a bit more parameterised so you can
choose which binaries to update. It's not just $objtype, because
a server might want to hold binaries for different clients. It
would help if replica/applylog had a -x (exclude) parameter.
Christian Neukirchen
2012-12-04 14:10:01 UTC
Permalink
Post by Richard Miller
Post by Christian Neukirchen
Do you plan to provide a pull-able version of your tree?
The bcm2835 kernel may go into the standard distribution eventually
(as /sys/src/9/bcm). Replica/pull is a bit problematic at present
because the arm binaries aren't being built on sources, and the
default /dist/replica/network will pull in all the 386 binaries
which you might not want.
The SD card is big enough, so I don't worry about that.
I understand that I have to build the stuff myself, then.
Post by Richard Miller
I think pull will need to be a bit more parameterised so you can
choose which binaries to update. It's not just $objtype, because
a server might want to hold binaries for different clients. It
would help if replica/applylog had a -x (exclude) parameter.
--
Christian Neukirchen <***@gmail.com> http://chneukirchen.org
Murray Colpman
2012-12-03 16:44:08 UTC
Permalink
Post by Richard Miller
Sorry, I'll add kbmap to the standard config file.
Thanks a lot! Very nice work with the image, by the way. Do you have
some sort of site where I would be able to find out when you upload new
images? Or do you post to this list? All I could find are pages by
others linking to the image on your space on the Bell Labs site.
Richard Miller
2012-12-03 17:00:45 UTC
Permalink
Post by Murray Colpman
Do you have
some sort of site where I would be able to find out when you upload new
images?
Nothing formal - you can check the modified date of the image file in
/n/sources/contrib/miller to see if it's changed. The official install
and update mechanism for Plan 9 at present is a bit x86 dependent.
Eventually I hope arm systems in general will become more integrated.
Chris Wilson
2012-12-03 19:38:09 UTC
Permalink
Post by Richard Miller
Post by Murray Colpman
Do you have
some sort of site where I would be able to find out when you upload new
images?
Nothing formal - you can check the modified date of the image file in
/n/sources/contrib/miller to see if it's changed. The official install
and update mechanism for Plan 9 at present is a bit x86 dependent.
Eventually I hope arm systems in general will become more integrated.
If there is anything that myself, fairly noobish that I am, can do to help,
let me know. Great work on the Pi image! I've been loving it.

--
chris
Bakul Shah
2012-12-04 01:52:50 UTC
Permalink
Post by Chris Wilson
Post by Richard Miller
Post by Murray Colpman
Do you have
some sort of site where I would be able to find out when you upload new
images?
Nothing formal - you can check the modified date of the image file in
/n/sources/contrib/miller to see if it's changed. The official install
and update mechanism for Plan 9 at present is a bit x86 dependent.
Eventually I hope arm systems in general will become more integrated.
If there is anything that myself, fairly noobish that I am, can do to help,
let me know. Great work on the Pi image! I've been loving it.
Not sure this is for newbies but...

contrib/* doesn't distinguish between archs. One suggestion
is to enhance contrib/*. Probably best for the contrib author
to do this (or provide directions) but I am thinking something
along these lines:

- when installing or pulling changes, build things locally if
$objtype specific binaries don't exist in the package. And
don't pull binaries for other archs (unless explicitly asked
for).

- when creating or pushing changes, try to push binaries for
all the archs locallly (cross) compiled.

- when listing don't show packages known to be broken for
$objtype arch. Probably best to add config/broken and
config/fixed.
erik quanstrom
2012-12-04 02:41:17 UTC
Permalink
Post by Bakul Shah
contrib/* doesn't distinguish between archs. One suggestion
is to enhance contrib/*. Probably best for the contrib author
to do this (or provide directions) but I am thinking something
- when installing or pulling changes, build things locally if
$objtype specific binaries don't exist in the package. And
don't pull binaries for other archs (unless explicitly asked
for).
- when creating or pushing changes, try to push binaries for
all the archs locallly (cross) compiled.
- when listing don't show packages known to be broken for
$objtype arch. Probably best to add config/broken and
config/fixed.
sure, that works. i'd almost rather have an install script
that does the building for you. but for now i've updated
all my contrib packages to include 386/amd64/arm.

- erik
Loading...