Discussion:
[9fans] German USB keyboard on Raspberry Pi
(too old to reply)
Holger Sebert
2013-04-20 16:31:02 UTC
Permalink
Hi,

I am running Richard Miller's port of Plan 9
on the Raspberry Pi. It's great!

However, I have a little trouble using my
German USB keyboard with it. The Umlauts (ä, ö, etc.)
work fine; however, the key with "<", ">" and "|"
does not work at all. It seems like the scan code
is not recognized by the USB driver.

Note: It may be that the key (as hardware) does
not exist on US keyboards:

Loading Image...

(It is the key at the bottom-left, next to Shift)

Any ideas?

Best regards,
Holger Sebert
Bakul Shah
2013-04-20 19:14:11 UTC
Permalink
Post by Holger Sebert
However, I have a little trouble using my
German USB keyboard with it.
See
http://plan9.bell-labs.com/wiki/plan9/setting_the_right_keyboard_map/
Holger Sebert
2013-04-20 20:08:00 UTC
Permalink
Post by Bakul Shah
Post by Holger Sebert
However, I have a little trouble using my
German USB keyboard with it.
See
http://plan9.bell-labs.com/wiki/plan9/setting_the_right_keyboard_map/
I have already done that and the Umlauts etc.
work fine, it is just the "<,>,|"-key that
does not work.

This phenomenon does not exist on a x86-based
installation of Plan 9, so it seems specific
to the Raspberry Pi.

Best,
Holger
Bakul Shah
2013-04-20 23:18:10 UTC
Permalink
Post by Holger Sebert
This phenomenon does not exist on a x86-based
installation of Plan 9, so it seems specific
to the Raspberry Pi.
Strange.... Is the x86 installation on real hardware or under
a VM? If the latter, the underlying OS may be doing the right
thing for you. In any case, you can try to find out what
scancodes are reported and create your own kbmap file.

% echo kbargs -dd > /dev/usbdctl
Remove and replug your keyboard and watch what happens when
you press your "< | >" key.

When I do this I get a constant stream of

kbd mod 0: kc 0 kc 0 kc 0 kc 0 kc 0 kc 0
kbd mod 0: kc 0 kc 0 kc 0 kc 0 kc 0 kc 0
kbd mod 0: kc 0 kc 0 kc 0 kc 0 kc 0 kc 0

which is probably due to my el-cheapo keyboard
but may be this will behave better for you.
Holger Sebert
2013-04-24 19:25:13 UTC
Permalink
Hi,
Post by Bakul Shah
Post by Holger Sebert
This phenomenon does not exist on a x86-based
installation of Plan 9, so it seems specific
to the Raspberry Pi.
Strange.... Is the x86 installation on real hardware or under
a VM? If the latter, the underlying OS may be doing the right
thing for you. In any case, you can try to find out what
scancodes are reported and create your own kbmap file.
% echo kbargs -dd > /dev/usbdctl
Remove and replug your keyboard and watch what happens when
you press your "< | >" key.
When I do this I get a constant stream of
kbd mod 0: kc 0 kc 0 kc 0 kc 0 kc 0 kc 0
kbd mod 0: kc 0 kc 0 kc 0 kc 0 kc 0 kc 0
kbd mod 0: kc 0 kc 0 kc 0 kc 0 kc 0 kc 0
which is probably due to my el-cheapo keyboard
but may be this will behave better for you.
I have tried it out: The driver says
"sc: e0 56" when pressing the "<"-key.
This is nice! However, I have no idea how
to put this (extended?) scan code into
the kbmap-file. The naive try:

0 0xe056 '<

resulted in "cat: write error copying lib/kbmap/de:
bad arg in system call".

Any idea?

Best,
Holger
Bakul Shah
2013-04-24 20:56:02 UTC
Permalink
Post by Holger Sebert
I have tried it out: The driver says
"sc: e0 56" when pressing the "<"-key.
This means a two char sequence: e0, 0x56 is stuffed into the
kernel device kbin. Ultimately thsi will map to the value in
kbtabesc1[0x56]. Now kbtabesc1 is table 2 in a kbmap so we are
looking for an entry that starts with
2 86 ... # 86 == 0x56
In /sys/lib/kbmap/de I see
2 86 0
This explains why you don't see anything. What you want to do
is to copy this file to, say, de2 and replace the above with
2 86 '<
And then put the following in $home/lib/profile
cat /sys/lib/kbmap/de2 > /dev/kbmap
Probably under 'case terminal'.

Repeat this analysis for other keys that don't work right. I
did a quick reading so may have missed something but hopefully
you can follow the code yourself now. You will have to look at
the following files

/sys/src/cmd/usb/kb/kb.c
/sys/src/9/port/devkb*.c
/sys/src/9/omap/kbd.c (what 9/bcm/kbd.c points to)
Post by Holger Sebert
This is nice! However, I have no idea how
to put this (extended?) scan code into
0 0xe056 '<
This won't work. The first item selects a scanmap (a 128
element array). The second item is an *index* into this
array. The third item is the Rune that goes in that slot.
See kbmap.c to find the mapping between table number and
a kbtab* array.
erik quanstrom
2013-04-25 20:41:10 UTC
Permalink
If not, how do I recompile and install the kbd-module on the
Raspberry Pi? I changed kbd.c for testing purposes and
executed "mk install" in the directory /sys/src/9/. Although
the build succeeded the changes did not seem to be incorporated.
unfortunately. you need to rebuild all of usb (or at least usbd), then your kernel
for the changes to always take effect.

- erik
Holger Sebert
2013-04-28 20:01:17 UTC
Permalink
Hi,

I did a quick hack on kbd.c and could make the "<,>,|" key
work. Awesome! Thank you all for your help.

In the 'bcm' directory some modules refer to 'omap' although
they apparently mean 'port', like this:

#include "../omap/random.c"

which should be

#include "../port/random.c"

Although it was easy to fix, I wonder where this inconsistency
in the source tree came from. Did I miss an update or something?

Furthermore, I noticed that the build system would build _all_
of the kernel each time I invoke 'mk', even though only little
or nothing has changed. Is this the way it is intended to be?

Best,
Holger
Post by erik quanstrom
If not, how do I recompile and install the kbd-module on the
Raspberry Pi? I changed kbd.c for testing purposes and
executed "mk install" in the directory /sys/src/9/. Although
the build succeeded the changes did not seem to be incorporated.
unfortunately. you need to rebuild all of usb (or at least usbd), then your kernel
for the changes to always take effect.
- erik
Bakul Shah
2013-04-28 21:07:02 UTC
Permalink
Post by Holger Sebert
Hi,
I did a quick hack on kbd.c and could make the "<,>,|" key
work. Awesome! Thank you all for your help.
What was the fix?
Post by Holger Sebert
In the 'bcm' directory some modules refer to 'omap' although
#include "../omap/random.c"
which should be
#include "../port/random.c"
Files from ../port are automatically picked up so you don't
need files in bcm that just include ../port/something.
Post by Holger Sebert
Furthermore, I noticed that the build system would build _all_
of the kernel each time I invoke 'mk', even though only little
or nothing has changed. Is this the way it is intended to be?
Looks like your source files have a modification time newer
than the current time (as seen on your machine). Either
manually set date/time on boot (if not connected to the net)
or set
TIMESYNCARGS=(-n pool.ntp.org)
in /rc/bin/termrc.local. Pick a public ntpserver near you
instead of pool.ntp.org.
Holger Sebert
2013-04-30 12:59:20 UTC
Permalink
Hi,
On 28 Apr 2013 22:01:17 +0200 "Holger Sebert"
Post by Holger Sebert
I did a quick hack on kbd.c and could make the "<,>,|" key
work. Awesome! Thank you all for your help.
What was the fix?
The relevant section from kbd.c is

if(kbscan->esc1){
c = kbtabesc1[c];
kbscan->esc1 = 0;
} else if(kbscan->esc2){
kbscan->esc2--;
return;
} else if /* ... */

The logic that is implemented here implies that
sequences of the form "e0 xx" cannot be combined
with a modifier like Shift or AltGr.

Since "<,>,|" is the only key on my keyboard for
which this is relevant, I simply changed the first
line to

if(kbscan->esc1 && c != 0x58){
/*...*/


This way, the sequence "e0 58" is actually interpreted
as "58", so that Shift and AltGr again work.

Of course, this is not a clean solution at all. But at
least it does not change the semantics of the kbmap-file.
Post by Holger Sebert
In the 'bcm' directory some modules refer to 'omap' although
#include "../omap/random.c"
which should be
#include "../port/random.c"
Files from ../port are automatically picked up so you don't
need files in bcm that just include ../port/something.
Post by Holger Sebert
Furthermore, I noticed that the build system would build _all_
of the kernel each time I invoke 'mk', even though only little
or nothing has changed. Is this the way it is intended to be?
Looks like your source files have a modification time newer
than the current time (as seen on your machine). Either
manually set date/time on boot (if not connected to the net)
or set
TIMESYNCARGS=(-n pool.ntp.org)
in /rc/bin/termrc.local. Pick a public ntpserver near you
instead of pool.ntp.org.
Oh yes, did not think about the missing RTC on the Pi. Thanks
for the solution!

Best,
Holger
Richard Miller
2013-04-28 21:14:10 UTC
Permalink
Post by Holger Sebert
#include "../omap/random.c"
which should be
#include "../port/random.c"
Although it was easy to fix, I wonder where this inconsistency
in the source tree came from. Did I miss an update or something?
I think you did. /sys/src/9/bcm/random.c should have been deleted.
Post by Holger Sebert
Furthermore, I noticed that the build system would build _all_
of the kernel each time I invoke 'mk', even though only little
or nothing has changed. Is this the way it is intended to be?
Is your pi connected to the internet? If not, its time will be
reset to the kernel build time each time you reboot (a function
of the "fakertc" device, which was probably not a very good idea).
When time goes backwards, 'mk' isn't able to do the right thing.

You could build a kernel without the fakertc device; then you'll
be prompted for date and time when you reboot. Or connect to
the internet so the date can be set from ntp.
Holger Sebert
2013-04-30 13:05:36 UTC
Permalink
Hi,
Post by Richard Miller
Post by Holger Sebert
#include "../omap/random.c"
which should be
#include "../port/random.c"
Although it was easy to fix, I wonder where this inconsistency
in the source tree came from. Did I miss an update or something?
I think you did. /sys/src/9/bcm/random.c should have been deleted.
Should this have happened when I invoked 'pull'? Or is there a
separate update mechanism?
Post by Richard Miller
Post by Holger Sebert
Furthermore, I noticed that the build system would build _all_
of the kernel each time I invoke 'mk', even though only little
or nothing has changed. Is this the way it is intended to be?
Is your pi connected to the internet? If not, its time will be
reset to the kernel build time each time you reboot (a function
of the "fakertc" device, which was probably not a very good idea).
When time goes backwards, 'mk' isn't able to do the right thing.
You could build a kernel without the fakertc device; then you'll
be prompted for date and time when you reboot. Or connect to
the internet so the date can be set from ntp.
Yes, I forgot that the Raspberry Pi does not have an RTC; and I do
not connect it to the internet everytime I switch it on. Time for
me to get an RTC add-on! Thanks for your help!!

Best,
Holger
Richard Miller
2013-04-30 14:16:23 UTC
Permalink
Post by Holger Sebert
Post by Richard Miller
I think you did. /sys/src/9/bcm/random.c should have been deleted.
Should this have happened when I invoked 'pull'? Or is there a
separate update mechanism?
Yes, it should have been deleted by the first 'pull' after 1 April:

term% grep sys/src/9/bcm/random.c /dist/replica/client/plan9.log
1364809803 16381 d sys/src/9/bcm/random.c - 664 sys sys 1342801416 0
term% date 1364809803
Mon Apr 1 10:50:03 BST 2013
arisawa
2013-05-03 12:30:36 UTC
Permalink
Hello,

I have a similar problem with JIS keyboard.
some keys such as | ~ \ _ ¥ won't be input.
I suspect this is same origin.

Kenji Arisawa
Post by Holger Sebert
I did a quick hack on kbd.c and could make the "<,>,|" key
work. Awesome! Thank you all for your help.
Holger Sebert
2013-04-25 20:38:38 UTC
Permalink
Hi,
Post by Bakul Shah
Post by Holger Sebert
I have tried it out: The driver says
"sc: e0 56" when pressing the "<"-key.
This means a two char sequence: e0, 0x56 is stuffed into the
kernel device kbin. Ultimately thsi will map to the value in
kbtabesc1[0x56]. Now kbtabesc1 is table 2 in a kbmap so we are
looking for an entry that starts with
2 86 ... # 86 == 0x56
In /sys/lib/kbmap/de I see
2 86 0
This explains why you don't see anything. What you want to do
is to copy this file to, say, de2 and replace the above with
2 86 '<
And then put the following in $home/lib/profile
cat /sys/lib/kbmap/de2 > /dev/kbmap
Probably under 'case terminal'.
Thanks alot! This gets the '<'-key going.

I have tried to put the key-with-modifier (Shift and AltGr)
chars into the kbmap but with no result. "3 86 '>" and "4 86 '|"
get all ignored.

I looked into kbd.c and it seems the driver does not support
modified states of extended scan codes of the form "e0 ??".

A hack would probably be possible, but maybe I am overlooking
something?

If not, how do I recompile and install the kbd-module on the
Raspberry Pi? I changed kbd.c for testing purposes and
executed "mk install" in the directory /sys/src/9/. Although
the build succeeded the changes did not seem to be incorporated.

Sorry for drifting off topic here ...

Best,
Holger
Yaroslav
2013-04-26 07:07:55 UTC
Permalink
If not, how do I recompile and install the kbd-module on the
Raspberry Pi? I changed kbd.c for testing purposes and
executed "mk install" in the directory /sys/src/9/. Although
the build succeeded the changes did not seem to be incorporated.
mk install usually installs the kernel to /$objtype, but rpi boots
from dos partition of an SD card, therefore you also need to copy it
over there:
; dosmnt 1 /n/dos
; cp /arm/9pi /n/dos/
; unmount /n/dos # or simply close the window

--
- Yaroslav
erik quanstrom
2013-04-26 12:02:51 UTC
Permalink
Post by Yaroslav
If not, how do I recompile and install the kbd-module on the
Raspberry Pi? I changed kbd.c for testing purposes and
executed "mk install" in the directory /sys/src/9/. Although
the build succeeded the changes did not seem to be incorporated.
mk install usually installs the kernel to /$objtype, but rpi boots
from dos partition of an SD card, therefore you also need to copy it
; dosmnt 1 /n/dos
; cp /arm/9pi /n/dos/
; unmount /n/dos # or simply close the window
simply "9fat:" should work. no need to unmount.

- erik
Richard Miller
2013-04-26 12:34:13 UTC
Permalink
Post by erik quanstrom
simply "9fat:" should work.
Not on a normal 9pi SD card, which has a dos partition and no 9fat.
erik quanstrom
2013-04-26 12:36:39 UTC
Permalink
Post by erik quanstrom
simply "9fat:" should work.
Not on a normal 9pi SD card, which has a dos partition and no 9fat.
i missed this fix:

minooka; 9diff /rc/bin/9fat:
/n/sources/plan9/rc/bin/9fat::1,7 - /rc/bin/9fat::1,7
#!/bin/rc

rfork e
- part=`{ls /dev/fs/9fat /dev/sd*/9fat >[2]/dev/null}
+ part=`{ls /dev/fs/9fat /dev/sd*/9fat /dev/sd*/dos >[2]/dev/null}
if(~ $#part 0) {
echo 'no 9fat partition found' >[1=2]
exit no.9fat

- erik
Loading...