Help - Search - Members - Calendar
Full Version: Ir Keyboard Drivers - Alpha Release
OESF Forums > Distros, Development, and Model Specific Forums > Distro Support and Discussion > pdaXrom
Pages: 1, 2
kopsis
An "alpha" release of my new IR keyboard drivers for pdaXrom RC11 is now available! Supported keyboards are Belkin F8U1500-T and Pocketop. Possibly supported keyboards (the code is in there but I can't test it) are Targus and Palm IR keyboards.

This is a C7x0/C860 release only! Versions for other Zaurii will follow, but I want to make sure there's no serious breakage on the platform I can test on before I release for platforms I can't.

Disclaimer: this software has only been tested on one single Zaurus in the entire known universe. There are many things that could go wrong. If this software breaks your Zaurus, you get to keep all the pieces. Backup, backup, backup, backup!

Installation is pretty simple:

* Backup, backup, backup!

* Install the kernel-modules-input and zkbdd IPKs from my feed at http://kopsisengineering.com/rc11/Zaurus-7x0-860/feed/

* From an Aterm or the console do a "modprobe keybdev" and "modprobe uinput"

* From an Aterm or the console do an "lsmod" and make sure input, keybdev, and uinput modules are listed

* From an Aterm or the console run "zkbdd -h" to get the help page for launching the driver. The general form of the command is "zkbdd -t kbtype".

* Launch the driver (eg. "zkbdd -t pocketop &")

* Start typing on the keyboard smile.gif

* Post your results here -- good or bad
Laze
Loaded up as you wrote - seems to work okay so far on my 760. Will try on SL6000 now :-)

Update: Some minor problems with Caps-lock i think and sometimes i seems like it keep typing a key and locks normal keyboard input.

Btw. Using a pocketop IR.
scoutme
I'd like to have an IRKeyboard to test them smile.gif

I'm very happy to hear of people adding new device support (and not only porting) smile.gif
jmcneill
smile.gif I like it. Works well but does start key repeats too easily.

Thanks
trichmon
Works on a 6000. Very functional. Only real major problem for me is the | comes out as a $

Thanks so much for all the work!!

Todd
Hrw
Maybe time to co-work with upstream so we won't end with kbdd like it is with irk where exist many versions hacked to support misc keyboards but not all.
kopsis
jmcneill:

Key repeat is handled entirely by the console or the X server (depending on which environment you're in). In X you'd normally control repeat rate with "xset r rate X Y" where X is the delay for starting repeat and Y is the delay between repeats. Unfortunately it doesn't look like the X server in pdaXrom supports that extension. Perhaps Sash can suggest another way to control repeat rate in X? For the console, delay and rate are normally set by the "kbdrate" program. Doesn't look like we have that utility, so perhaps I'll look into building it for inclusion in the zkbdd ipk.

trichmon:

For your | = $ problem, could you let me know keyboard type and if it's happening in the console or in X (or both)?

Hrw:

I understand where you're coming from. It is worth pointing out that one of the reasons for the many flavors of IRK is that its design makes it a fairly complicated matter to add support for an additional keyboard. My zkbdd design does a number of things to specifically address that problem. Eventually I hope to get to the point where drivers can be written as "scripts" that "plug-in" to zkbdd at run-time (no compiling necessary).

As for kbdd, unfortunately kbdd suffers from a lack of good system design so unless the maintainers are open to a major code restructuring, a merge is unlikely. On top of that, it's still too early in development to consider a merge. My code is far too Zaurus specific. That's been a purposeful decision to make it easier for me to isolate and correct defects in the early releases. However, if real world testing reveals that I'm on the right track with my design, I'll eventually re-architect the code yet again with a two stage scancode conversion process (keyboard -> intermediate -> target). At that point the keyboard drivers would be "common" and only the backend final scancode conversion would be target specific.

When (and if) that happens, the kbdd folks may wish to migrate kbdd to my code base. If not then we'll have two competing projects and users can decide which one is superior. Forking in open source projects can be good when the fork takes the code in substantially different directions (as opposed to just being minor tweaks of the upstream project). Note that since I'm keeping the command line interface "compatible" with kbdd, GUI apps to control it (like GPE) shouldn't care which "driver" the users pick.
kopsis
If anyone tries zkbdd with a Targus or Palm wireless keyboard, please post your results here and specify which keyboard you tested with. I'd really like to know if the code for either of those keyboards is even close to working before I do a beta release for other platforms.

And in general, specifying your keyboard type when reporting any problems will be most helpful.

Many thanks to all the brave souls who are giving this alpha release a test drive! smile.gif
trichmon
Im useing a targus model Pa870 V3. I spent some more time and I have to add a couple more keys to the problem list. It seems he [,],\ give starnge results.

Stll very useable.

Todd
kopsis
Todd, thanks for the info! If you don't mind spending a few minutes debugging, could you please do the following:

* In an Aterm or the console, start zkbdd with the "test9600" driver (zkbdd -t test9600) ... launch as a foreground process - no '&'.

* For each key that is acting up, press and release the key. Each time you press a key you'll see a sequence of codes displayed. Record the sequence of scancodes that zkbdd displays (you'll need to include which key generated which codes) and send the info to me either via private message or via email to "kopsis shift-2 gmail dot com"
cal
I would love to help test. I have a C1000 and a Belkin F8U1500
kopsis
C1000/C3X00 packages are coming soon (hopefully next week). Those devices use a different kernel and I'm still researching to make sure my changes to the keybdev module aren't going to break anything.

I'm also testing a new feature that loads the KB driver code via scripts at run-time. If that works, users will actually be able to modify/add keyboard drivers without any development tools! smile.gif
trichmon
I would be happy to test. I will try to get it done this weekend.

Todd
urielka
i can beta test it for C1000 if you need smile.gif
i have a strange non-brand ir-keyboard works with pocketpc,palm and symbian
sds
David, my Targus PA870 has been hijacked, so I could now only test the belkinf8 which you also have.

But maybe my input still could be of use for you.

The belkinf8 is working very well so far in X and indeed does not mess up with the built-in keyboard.

I have only these rather small, but annoying issues:
* Somehow I am unable to type '~'. 'Shift-`' gives back '`'.
* I would like to be able to use the driver as non-root also, however:
CODE
[lax:0:/home/svetlin> zkbdd -t belkinf8
using driver: Belkin F8U1500 IR Keyboard Driver, version 0.1
failed to open uinput device: No such file or directory
init uinput failed

* How could the driver be nicely stopped? 'Kill -9' brings an infinite loop in aterm with no further input possible, so I need to kill the terminal window.

Still, a very good job! Much appreciated.
kopsis
QUOTE(sds @ Oct 15 2005, 09:05 AM)
* Somehow I am unable to type '~'. 'Shift-`' gives back '`'.

I'll look into that one.
QUOTE
* I would like to be able to use the driver as non-root also, however ...

Try the following (as root):
CODE
# chmod 666 /dev/misc/uinput

That should allow non-root users to open the uinput device.
QUOTE
* How could the driver be nicely stopped? 'Kill -9' brings an infinite loop in aterm with no further input possible, so I need to kill the terminal window.

Yeah, I ran into that last night. The trick is to kill zkbdd from the built-in keyboard (a standard "kill" should do it -- no need for "-9") otherwise it will die before sending the last "key up" message to the kernel and the kernel's keyboard logic will get a bit lost. I'm working on a way to fix this in the next release.
kopsis
Ok, time for you brave C1000/C3100 owners to get into the act smile.gif You lucked out on the kernel modules! It turns out Sharp builds "input" and "keybdev" into the 2.4.20 kernels. That worried me because I had to hack up "keybdev" on the 2.4.18 kernel to get it to cooperate. Luckily I found that Sharp already made almost the exact same changes in their own 2.4.20 version.

Installation on C1000/C3100 is pretty similar to what I posted earlier:

* Backup, backup, backup!

* Install the kernel-modules-input and zkbdd IPKs from my feed at http://kopsisengineering.com/rc11/Zaurus-C1000-C3100/feed/ (note that this is different than the feed for the 7x0-860 version).

* From an Aterm or the console do a "modprobe uinput" (no need to modprobe keybdev, it's in the kernel)

* From an Aterm or the console do an "lsmod" and make sure the uinput module is listed

* From an Aterm or the console run "zkbdd -h" to get the help page for launching the driver. The general form of the command is "zkbdd -t kbtype".

* Launch the driver (eg. "zkbdd -t pocketop &")

* Start typing on the keyboard

* Post your results here -- good or bad. Note that I can't test this myself so I'm relying on you folks to tell me if it works. When posting your results please include your Zaurus model and keyboard model so I can start checking combinations off my scorecard.

If all goes well, next week I'll release version 0.2 of Zkbdd. There will be no changes to the kernel modules, but the keyboard driver app gets a major rework.
cal
On a C1000 with a Belkinf8

failed to open uinput device: No such file or directory
init uinput failed

lsmod shows uinput loaded...



-t test 9600 gets the same error.
kopsis
Could you try an "ls -al /dev/misc/uinput" and let me know what you see?
Srono
Hi kopsis,

I am using Palm IR keyboard on SL6000(http://www.palm.com/us/products/accessories/peripherals/3169WW.html). However, zkbdd is not working for me.
+ lsmod shows that both uinput and keybdev were loaded.
+ nothing appears on the terminal when i type
+ i tried "zkbdd -d -t palm": i still can see the debug lines on screen smile.gif
+ i tried "zkbdd -t pocketop": i can type some character although the keymap is not correct for palm (of course biggrin.gif)
Can you help me how to fix it? Thanks alot wink.gif
kopsis
QUOTE(Srono @ Oct 16 2005, 02:04 AM)
Can you help me how to fix it? Thanks alot wink.gif
*

Actually, you can help me fix it smile.gif

I'm working on some instructions for creating keyboard drivers. If you follow the first part (Reverse Engineering your Keyboard) and send me the information, I can use that to debug the driver. I don't need you to go through every key just yet. For now if you get data on three or four keys that should be enough to get me started debugging.
cal
QUOTE(kopsis @ Oct 16 2005, 12:23 AM)
Could you try an "ls -al /dev/misc/uinput" and let me know what you see?
*


-edit Removed -

Ok I think I made a mistake... When you first made your post, I added the first feed to my ipkg.conf and updated. I noticed what I did and, changed the feed to the correct C1000-C3000 feed. I may not have updated again, and then installed the wrong version. I don't have a wireless conection at work, so I will try to fix all this when I get home today.
willgan
i have tried the driver with my C1000... with pockettop ir keyboard

I rebooted my machine...
modprobe uinput ... loaded ok... lsmod shows the driver loaded
running zkbdd gives this result

failed to open uinput device: No such file or directory
init uinput failed

There is no /dev/misc/uinput created...
kopsis
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
CODE
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput

That should get things working. If you want to run zkbdd as a non-root user you should also set the permissions on /dev/misc/uinput to something like 666.
cal
QUOTE(kopsis @ Oct 16 2005, 12:38 PM)
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
CODE
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput

That should get things working. If you want to run zkbdd as a non-root user you should also set the permissions on /dev/misc/uinput to something like 666.
*


I get a no file or directory error on mknod /dev/misc/uinput c 10 223
willgan
kopsis,

I've tested again on my C1000 and pocketop..

With the mknod step..
Confirm... work..

But only when i use -d... the keycode will come out... when i press keys at my pocketop...
Does it work with programs like abiword?
willgan
QUOTE(cal @ Oct 16 2005, 06:29 PM)
QUOTE(kopsis @ Oct 16 2005, 12:38 PM)
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
CODE
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput

That should get things working. If you want to run zkbdd as a non-root user you should also set the permissions on /dev/misc/uinput to something like 666.
*


I get a no file or directory error on mknod /dev/misc/uinput c 10 223
*



# mkdir /dev/misc
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput
cal
QUOTE(willgan @ Oct 16 2005, 02:39 PM)
QUOTE(cal @ Oct 16 2005, 06:29 PM)
QUOTE(kopsis @ Oct 16 2005, 12:38 PM)
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
CODE
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput

That should get things working. If you want to run zkbdd as a non-root user you should also set the permissions on /dev/misc/uinput to something like 666.
*


I get a no file or directory error on mknod /dev/misc/uinput c 10 223
*



# mkdir /dev/misc
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput
*




I actually tried that... I think I must have some left over messyness from earlier. I'm going to try again on a fresh RC12 install.
cal
Just tried on a clean RC12 install (C1000)... I can see the scan codes with the test9600 keyboard, but it doesn't seem to work anywhere else.
jfv
Willing, eager to alpha/beta test a Targus keyboard on a 5000D. Let me know when you have a version for it.

Felipe
sds
QUOTE(kopsis @ Oct 15 2005, 07:28 PM)
QUOTE(sds @ Oct 15 2005, 09:05 AM)
* Somehow I am unable to type '~'. 'Shift-`' gives back '`'.

I'll look into that one.

I take this back -- problem was with my keyboard sticky keys.

QUOTE
QUOTE
* I would like to be able to use the driver as non-root also, however ...

Try the following (as root):
CODE
# chmod 666 /dev/misc/uinput

That should allow non-root users to open the uinput device.

Thanks, this and chmod-ing /dev/tty/1 to 666 did it.
kopsis
Anyone care to donate a C1000? wink.gif Would sure make it easier to debug.

If not, perhaps one of you C1000/C3100 owners could run the following command for me:
CODE
# find /dev -ls | /home/root/dev_ls.txt

and then post the resulting dev_ls.txt file here? Thanks!
kopsis
cal:

I need two things from you to debug the problem you're having:

1) Model number of your Belkin keyboard (printed on the "hinge"). There are F8U1500 and F8U1500T models and I believe protocols are different. I suspect you have the non-T version. Code in Zkbdd currently supports only the 1500T (but I want to add non-T support).

2) test9600 outputs from a key-down event for the "A" key and a key-up event for the "A" key.
cal
QUOTE(kopsis @ Oct 17 2005, 08:49 AM)
cal:

I need two things from you to debug the problem you're having:

1) Model number of your Belkin keyboard (printed on the "hinge"). There are F8U1500 and F8U1500T models and I believe protocols are different. I suspect you have the non-T version. Code in Zkbdd currently supports only the 1500T (but I want to add non-T support).

2) test9600 outputs from a key-down event for the "A" key and a key-up event for the "A" key.
*



You are correct, I do have 1500. I will get you the A code asap... I didn't bring my keyboard to work. Thanks for helping, and your hard work. You are doing a really great job.
g33k
I've just tried the palmOne Universal Wireless Keyboard (3169WW) with your drivers on my C860. None of the keys were functional at all. I tried all the stuff you suggested in the thread up to this point. When I load the driver with type test9600, I can see all the scancodes, so it appears that the driver is working fine but lacks mappings for this particular keyboard. Has anyone provided you with the codes for this keyboard yet? If not, I'd be glad to do it... it'd be neat to be able to use a "fullsize" keyboard.
kopsis
QUOTE(g33k @ Oct 18 2005, 03:05 PM)
Has anyone provided you with the codes for this keyboard yet? If not, I'd be glad to do it... it'd be neat to be able to use a "fullsize" keyboard.
*

I don't have codes for that keyboard yet. Note that it could be the maps or it could be the protocol. If you could initially give me codes for just a couple keys, it would tell me which of those two things is the problem. Thanks!
g33k
I've PMed you some key codes for the Palm Universal Wireless Keyboard.

Thanks for your swell work on this!
kopsis
Got it. Looks like the new Palm keyboards are way different than the old ones. But with g33k's help I should have the Palm 3169WW working in the next release (hopefully by the end of the week).
jimjimbobim
Any idea on how to fix the right click on the SL-6000?
Srono
Thank g33k and kopsis very much!! :X
Kopsis asked me to send some key also but i was so busy for the last few days :">
kopsis
Step right up folks and get your copy of zkbdd v0.2!

This release features a major architectural shift from hard-coded drivers to driver "scripts". That means you can change the driver code and/or add new drivers without ever "building" any binaries. I don't have much documentation on how to actually do that yet, but assuming that this version works well for people, documentation will follow. If you want to take a peek at the driver scripts you'll find them in /usr/share/zkbdd/drivers after you install the new IPK.

In addition to the architectural changes, I've added (with g33k's generous assistance) an "untested" driver script for the Palm 3169WW Universal Wireless keyboard. I've also added a default config file (/etc/zkbdd.conf) which you can edit to reflect your keyboard type and then you'll be able to run zkbdd with no parameters.

Note that some keyboard types have changed (eg. belkinf8 is now belking_f8u1500t) -- do a "zkbdd -h" for a list of new driver names.

Also note that only the zkbdd package is updated. The kernel modules are still at the 0.1 release so just continue using the version you have installed. I still need a C1000 owner to volunteer to provide me some info so I can get the kernel module packages updated.

Last but not least, I've started putting together a Zkbdd project site with links, instructions, release notes, etc. It's a little light right now -- suggestions are welcome.

Good luck and as always, I encourage you to share your results smile.gif
Srono
Wow, Your weekend comes so fast tongue.gif (just kidding) Thanks for the good news and the new update!
I tried the new driver with my palm 3169ww. Here is the result:
+ The config file work well.
+ I run zkbdd after 2 modprobe command. The built-in keyboard still worked fine after that. Then i used my ir-keyboard, something very weird happened:
- the keymap seemed to be working as it can detect the correct key i typed in.
- but when i pressed one button, for example: g, it was ok if i did not release the button. When i released, it automatically entered ggggggggggggggggggggggggg (nonstop) until i pressed another key h. Then i released h -> hhhhhhhhhhhhh
- After that, even when i pressed any button in the built-in keyboard, for example g -> h, it returned gggggg (stop) hhhhh (stop)
- After i kill zkbdd -> everything worked normally.

Can i do something to debug and send u the result ? I'm waiting for g33k to try also tongue.gif I hope that u understand whay i try to explain :">
Thanks alot !
g33k
I'm sorry to say that this isn't working very well for me. I'm using the palm_3169ww driver (of course).

Some keys don't seem to do anything:

2
w
a
s
z

Some do the wrong thing:

1 registers as 2
TAB registers as q
q registers as w
<, registers /
SPACE registers ^@ (which I assume is a non-printable character, rather than those literal characters)
RSHIFT registers as "
LSHIFT registers as z
CTRL registers as a
ALTGR registers as *

Since I provided the codes for this keyboard, I fear this is my fault. I'm going to see if I can figure out how the keycodes are stored and double-check them.

The primary problem, though, is that once a keypress is registered, unless I press another (working) key almost immediately, the keypress is duplicated endlessly. It's as if I'm holding down the key and key repeat is set very fast. I assume this is because the key release event isn't getting to the OS for whatever reason. I ran the driver in debug mode and it was displaying both keydown and keyup events, so the driver is clearly receiving and processing them.
kopsis
So if any of you brave 3169WW owners want to take a shot at debugging, here's some background info ...

If you run in debug mode (the -d switch), each key press/release will produce output like this:
CODE
lookup_scancode(map_normal, 0x5e)
keycode: 0x01
press 01
0x00000002
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
lookup_scancode(map_normal, 0x5e)
keycode: 0x01
release 01
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000

Ignore the 0x0000... lines. What you're interested in is the "lookup_scancode(map_normal, 0x5e)" lines. That shows the scancode that is being looked up and the map that is being used. Now if you look in the file "/usr/share/zkbdd/drivers/palm_3169ww.lua" (it's just a text file) you'll see a map with a matching name ("map_normal" in this case). The map is a sequence of values with the first one corresponding to 0x01, the second to 0x02, the 32nd to 0x20, etc. So take the hex number from the "lookup_scancode" message and locate that position in the table (hint: the second line of the table starts with 0x08, third with 0x10, fourth with 0x18, etc.). What you see in that spot is the symbolic code that the driver is going to send the Z.

So in the case of a key that doesn't do anything such as "a", locate it's spot in the table and you'll likely see the value "0". Change it to "ZK_A". Now find the other ZK_A in the table (there will be one) and change it to "0". Kill the driver, restart in normal mode, and press the "a" key. If you did everything right, it should work now. Repeat for the other broken keys.

Of course you're also welcome to just record all those scancode values and the keys that produce them and send them to me and I'll update the maps accordingly ... but sometimes it's fun fixing stuff yourself smile.gif

Another very important thing to look for -- every "press xx" line needs to be followed by a matching "release xx" line in the next sequence. If that's not happening then my protocol handling is broken. Shoot me a copy of your debug output in that case so I can dig into it.
g33k
It turned out that the boolean value being assigned to key_down in your scancode interpreting routine was inverted - the driver saw the keypress as a keyup, and vice versa. Seeing a keyup, then a keydown for each keypress was causing autorepeat to kick in after a moment, as the keys never seemed to be released. I was very pleased to have been able to fix that!

There were also some codes in the wrong spots in the normal_map. I fixed some easy ones; most of the keys work now. There seem to be some issues with the modifier keys; I'll look at them next.

The updated driver file is attached. (Just remove the .tar from the filename; it's not really a tar.)
kopsis
Thanks g33k! I knew moving the drivers from compiled-in code to editable scripts was a good idea smile.gif

As for modifiers, only the shift keys get special treatment -- the others (CTRL, ALT, etc.) are passed through to the Z unmodified. When shift is down it causes lookups to go to "map_shift" instead of "map_normal". If there's a value there, it's passed on as is and the shift keypress itself is dropped. If the value is null, a second lookup from "map_normal" is done and that code is sent along with the shift key press/release.

I'm a vi user not an Emacs person so I haven't really tried any three+ key combinations. If things like CTRL+ALT+key or SHIFT+CTRL+key are giving you problems, let me know (that will required diving into the driver core to debug).
clofland
Two questions:

1. Status? Are these working reliably on RC12 now?

2. Is it just me, or has the Pocketop web site's "ordering" section been down for a long time now? Any suggestions on where to get a Pocketop IR keyboard? Or suggestions on other keyboards that you think are better, cheaper or more available that also works well with pdaXrom?

Thanks.
kopsis
I've been so busy with "real work" that I haven't even had a chance to load up RC12. However, I don't know of any reason why the RC11 versions wouldn't work with RC12. Things are going to be crazy through December then hopefully I'll have a bit of free time to catch up on my projects.
clofland
One other question. Pocketop has an "original" keyboard and a CT4700. Does anyone know if there is any difference between them as far as compatibility?
sds
I used to have the original Pocketop gotten new and unopened from eBay but I am using a Belkin f8u1500t now.

The belkin_f8u1500t driver works the same under RC12 as under RC11.
The "original" Pocketop keyboard is the one tested for pdaXrom, I don't know about the other.

Pocketop keyboards are the highest build and visual quality, most compact and with best tactile feedback.
However, they are too cramped and small for long typing sessions and the location of some important for programming keys is counterintuitive.

In short, if you will type mostly text docs/emails up to 1-2 hours a session then get a Pocketop.
For longer typing and/or programming/shell work get a Belkin or a similar bigger keyboard.

Many thanks to Dave for his nice work.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.