Usb Keyboard Mapping

[derekp]

Just recently upgrade to a c3100, and have been playing around with getting standard usb keyboards working.  Well, I looked through all the posts regarding fixing the key mapping, and the general conclusion seems to be to use keyhelper to remap keys in userspace.
Well, I've put together a slightly better approach.  My goals were the following:
1) Make sure it's not qt-only
2) Allow an external keyboard to be mapped properly, without messing up the internal keyboard mapping
3) Do number 2) without having to switch between maps.
4) Get any dead usb keyboard keys working.

Here's what I found.
The one dead key I was woried about (backslash \ pipe) wasn't mapped in usbkbd.o, so I fixed that in the kernel source, and recompiled the usbkbd.o module.
Second thing, there weren't too many other keys that were mapped wrong on the usb keyboard that conflicted with internal keys (I checked the scan codes for all keys on both keyboards using showkey).  So for those, I fixed the key maps in /opt/QtPalmtop/keycode.tbl.
Now, the main keys that conflicted were the number keys.  So, for example, I couldn't remap shift-2 to be an "@" symbol, otherwise the internal keyboard would have the wrong map.  So for these keys, I ended up hacking away at usbkbd.c in the kernel source again, and ended up assigning the top number keys to the same scancodes used by the right-hand keypad, then edited entries in keycode.tbl to match.
The result is a replacement keycode.tbl and a usbkbd.o kernel module that allows the use of both the internal keyboard, and a usb keyboard without having to swap keymaps around, and no need for keyhelper.  The values that I used in keycode.tbl can be used to build the equivilent files for both X11 and console (for console key mapping, you'd have to use loadkeys I think).  I haven't got that far yet.

Anyhow, when I've been using this setup for a few days, and it seems to be working well.  If anyone is interested, then as soon as I get my other server up (it's got a bad CPU fan), I'll grab the patches for usbkbd.c and keycode.tbl, and post them here, along with an ipk.

edit: To use the attached files, unzip the attachment, then put usbkbd.o in /lib/modules/2.4.20/kernel/drivers/usb/usbkbd.o  and put keycode.tbl in /opt/QtPalmtop/etc/keycode.tbl (of coures, backup the existing ones first).

[Antikx]

Sounds like you did a good job. I look forward to trying it, instead of my sloppy hack.

[Armagon]

Just recently upgrade to a c3100, and have been playing around with getting standard usb keyboards working.  Well, I looked through all the posts regarding fixing the key mapping, and the general conclusion seems to be to use keyhelper to remap keys in userspace.
Well, I've put together a slightly better approach.  My goals were the following:
1) Make sure it's not qt-only
2) Allow an external keyboard to be mapped properly, without messing up the internal keyboard mapping
3) Do number 2) without having to switch between maps.
4) Get any dead usb keyboard keys working.

Here's what I found.
The one dead key I was woried about (backslash \ pipe) wasn't mapped in usbkbd.o, so I fixed that in the kernel source, and recompiled the usbkbd.o module.
Second thing, there weren't too many other keys that were mapped wrong on the usb keyboard that conflicted with internal keys (I checked the scan codes for all keys on both keyboards using showkey).  So for those, I fixed the key maps in /opt/QtPalmtop/keycode.tbl.
Now, the main keys that conflicted were the number keys.  So, for example, I couldn't remap shift-2 to be an "@" symbol, otherwise the internal keyboard would have the wrong map.  So for these keys, I ended up hacking away at usbkbd.c in the kernel source again, and ended up assigning the top number keys to the same scancodes used by the right-hand keypad, then edited entries in keycode.tbl to match.
The result is a replacement keycode.tbl and a usbkbd.o kernel module that allows the use of both the internal keyboard, and a usb keyboard without having to swap keymaps around, and no need for keyhelper.  The values that I used in keycode.tbl can be used to build the equivilent files for both X11 and console (for console key mapping, you'd have to use loadkeys I think).  I haven't got that far yet.

Anyhow, when I've been using this setup for a few days, and it seems to be working well.  If anyone is interested, then as soon as I get my other server up (it's got a bad CPU fan), I'll grab the patches for usbkbd.c and keycode.tbl, and post them here, along with an ipk.

edit: To use the attached files, unzip the attachment, then put usbkbd.o in /lib/modules/2.4.20/kernel/drivers/usb/usbkbd.o  and put keycode.tbl in /opt/QtPalmtop/etc/keycode.tbl (of coures, backup the existing ones first).
[div align=\"right\"][a href=\"index.php?act=findpost&pid=120947\"][{POST_SNAPBACK}][/a][/div]

That's wonderful!  I was just wondering about doing the same thing, but was hoping it could be handled at a higher level.

I presume your fix works for the Sharp and Cacko ROMs?  Does anyone know what would need to be done to do a similar thing for pdaXrom?  It is forked off of Cacko, and using the same kernel ... if I understand correctly.  I see that it does indeed have a /lib/modules/2.4.20/kernel/drivers/usb/usbkbd.o -- I'll have to try swapping it when I have some time.  There is (not surprizingly) not an /opt/QtPalmtop directory, so I don't know what is analogous to the keycode.tbl (the kernel.map or xmodmap file?)

This is wonderful news, though.  Great work!

Armagon

[tml]

Hi,

Is this for an english standard keyboard only? Is there a way to easily get this to work with a, e.g., German keyboard? I guess this would involve editing keycode.tbl, which would probably ruin the layout of the internal keyboard, wouldn't it.

Up to now I switch between two keyhelper profiles. Being able to avoid this would be really great. Getting rid of the dead key too.

Thomas.

[derekp]

I presume your fix works for the Sharp and Cacko ROMs?  Does anyone know what would need to be done to do a similar thing for pdaXrom?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=120978\"][{POST_SNAPBACK}][/a][/div]

It should work on any Qtopia-based roms.  For X11-based roms, X11 uses a program called xmodmap to load / change key mappings, which is effective for that particular X windows session.  These are usually saved in an xmodmaprc file or similar.  To modify this file, you'd have to match up the scan codes from keycode.tbl with the equivilant entries in xmodmaprc.  However, there is also another layer of indirection, in that raw scancodes (for example, as specified in usbkbd.c) are mapped to different X11 keycodes that xmodmap uses.  I haven't loaded up pdaXrom, but I do have X/qt installed, so I'm going to attack that next.
BTW, my modified usbkbd.c breaks from tradition, in that since I was running low on scancodes, and didn't want conflicts between the internal and usb keyboards, I use the same scancodes for the top number row as used on the numpad.  So the consequence of this is that if you have an X program that treats the numpad different from the top row of numbers, then those programs will break.  Of course, I can't think of any examples off the top of my head.
I'll update this later on when I get some working xmodmap enteries, unless someone else can beat me to it.  I'd like to put together a script to automaticaly convert a keycode.tbl file into an xmodmaprc file, but they use different symbol names (not to mention different scancode mappings).  Maybe that'll will be my next weekend project, once I figure out how to query the X server for raw scancode to X scancode maps.

[Meanie]

I presume your fix works for the Sharp and Cacko ROMs?  Does anyone know what would need to be done to do a similar thing for pdaXrom?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

It should work on any Qtopia-based roms.  For X11-based roms, X11 uses a program called xmodmap to load / change key mappings, which is effective for that particular X windows session.  These are usually saved in an xmodmaprc file or similar.  To modify this file, you'd have to match up the scan codes from keycode.tbl with the equivilant entries in xmodmaprc.  However, there is also another layer of indirection, in that raw scancodes (for example, as specified in usbkbd.c) are mapped to different X11 keycodes that xmodmap uses.  I haven't loaded up pdaXrom, but I do have X/qt installed, so I'm going to attack that next.
BTW, my modified usbkbd.c breaks from tradition, in that since I was running low on scancodes, and didn't want conflicts between the internal and usb keyboards, I use the same scancodes for the top number row as used on the numpad.  So the consequence of this is that if you have an X program that treats the numpad different from the top row of numbers, then those programs will break.  Of course, I can't think of any examples off the top of my head.
I'll update this later on when I get some working xmodmap enteries, unless someone else can beat me to it.  I'd like to put together a script to automaticaly convert a keycode.tbl file into an xmodmaprc file, but they use different symbol names (not to mention different scancode mappings).  Maybe that'll will be my next weekend project, once I figure out how to query the X server for raw scancode to X scancode maps.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=120985\"][{POST_SNAPBACK}][/a][/div]

you can use xev to determine scancodes in X. i have some samples located here for X/Qt if you need something to play with [a href=\"http://zaurus.daemons.gr/menaie/mirror/jumbo/]http://zaurus.daemons.gr/menaie/mirror/jumbo/[/url]
i also found that the default mappings are different between pdaXrom and X/Qt
http://zaurus.daemons.gr/menaie/pdaxrom/c3...odmaprc.default

[derekp]

you can use xev to determine scancodes in X.

Actually, xev does the same under X that showkey does in a Linux console.  Problem is, it is interactive, requiring manual inspection of each key.  What I'd like is to run a command to dump the mapping of kernel scancodes to X keycode numbers.  I think this compiled into the X11 keyboard driver, I'll have to dig through some source code to figure it out.
Also, after doing some digging, it turns out that a modified usbkbd.o driver may not be needed, since the same thing can be accomplished by using setkeycodes.
Here's what I've figured out so far:
The keyboard generates a raw scancode, from 0 - 255, for each key.  The kernel has a map that maps these raw codes into kernel scancodes (this is what you see in the large array in usbkbd.c in the kernel source).  These can also be set / displayed by running setkeycodes / getkeycodes.
Secondly, the mapped kernel scancode (or keycode) is assigned meaning by one of several methods, depending on what is using the keyboard.  This layer is responsible for interpreting not only the keys, but also key combinations (shift, alt, ctrl, etc.)
 -- for Console-based programs, this layer of mapping is handled by loadkeys / dumpkeys.
 -- for Qt Embedded apps (i.e., Qtopia), it is handled by /opt/QtPalmtop/etc/keycode.tbl
 -- under X11, this is set (or displayed) using xmodmap.  The settings are stored in the running X server's environment, so any changes need to be re-applied when X is restarted.  This is ually done by having a startup script (such as .xinitrc) call xmodmap, pointing to a file such as xmodmaprc.
The difference with X11 is it doesn't look at the kerrnel scancode/keycode, but instead it has it's own mapping of raw scancodes to X11 keycodes (I think -- I guess I could test this by changing some of the kernel scancodes, and seeing if that affects X11 apps).

[Armagon]

Keep up the great work, derekp.

Give xmodmap -pk a try.  It seems to print out a table similar to what you are asking for.  (There are also other xmodmap arguments that may be useful.)

Darn, I was hoping that we weren't limited to 256 scancodes.  I guess when the system was designed, no one conceived of using multiple keyboards at once [and even then, you'd think 256 keys would be gobs!]

I am also wondering [and I haven't even tried this, so I don't really know what I'm talking about] what happens when you are doing desktop sharing to or from your Zaurus -- if the keys from the client's keyboard will be mapped sensibly.  [But, that is probably not an issue to tackle for right now -- it'd be wonderful to get the USB keyboard working seamlessly!]

Again, way to go man!
Armagon

[ChrisR]

Hi derekp,

while trying to get my USB keyboard to work, I found your module. When I first copied the files over, everything worked great. I used my standard Logitech Cordless Desktop keyboard with my Z. But after a reboot, the mapping was just like before. I checked the files over and over, but it were the ones from you. I don't understand what's going on. If you please could point me in the right direction for solving this issue?
I'm using Cacko 1.23 on a C1000.

Greetz
Chris