OESF Portables Forum
Model Specific Forums => Sharp Zaurus => Zaurus - pdaXrom => Topic started by: kopsis on October 12, 2005, 12:47:36 pm
-
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/ (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
* Post your results here -- good or bad
-
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.
-
I'd like to have an IRKeyboard to test them
I'm very happy to hear of people adding new device support (and not only porting)
-
I like it. Works well but does start key repeats too easily.
Thanks
-
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
-
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.
-
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.
-
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!
-
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
-
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"
-
I would love to help test. I have a C1000 and a Belkin F8U1500
-
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!
-
I would be happy to test. I will try to get it done this weekend.
Todd
-
i can beta test it for C1000 if you need
i have a strange non-brand ir-keyboard works with pocketpc,palm and symbian
-
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:
[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.
-
* Somehow I am unable to type '~'. 'Shift-`' gives back '`'.
I'll look into that one.
* I would like to be able to use the driver as non-root also, however ...
Try the following (as root):
# chmod 666 /dev/misc/uinputThat should allow non-root users to open the uinput device.
* 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.
-
Ok, time for you brave C1000/C3100 owners to get into the act 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/ (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.
-
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.
-
Could you try an "ls -al /dev/misc/uinput" and let me know what you see?
-
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
+ i tried "zkbdd -t pocketop": i can type some character although the keymap is not correct for palm (of course )
Can you help me how to fix it? Thanks alot
-
Can you help me how to fix it? Thanks alot
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=99547\")
Actually, you can help me fix it
I'm working on some [a href=\"http://kopsisengineering.com/kopsis/ZkbddAddingKeyboards]instructions for creating keyboard drivers[/url]. 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.
-
Could you try an "ls -al /dev/misc/uinput" and let me know what you see?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99539\"][{POST_SNAPBACK}][/a][/div]
-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.
-
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...
-
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinputThat 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.
-
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinputThat 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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99582\"][{POST_SNAPBACK}][/a][/div]
I get a no file or directory error on mknod /dev/misc/uinput c 10 223
-
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?
-
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinputThat 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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99582\"][{POST_SNAPBACK}][/a][/div]
I get a no file or directory error on mknod /dev/misc/uinput c 10 223
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99593\"][{POST_SNAPBACK}][/a][/div]
# mkdir /dev/misc
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput
-
Ok, looks like C1000/C3100 users need to open a terminal as "root" and do the following:
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinputThat 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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99582\"][{POST_SNAPBACK}][/a][/div]
I get a no file or directory error on mknod /dev/misc/uinput c 10 223
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99593\"][{POST_SNAPBACK}][/a][/div]
# mkdir /dev/misc
# mknod /dev/misc/uinput c 10 223
# ln -s /dev/misc/uinput /dev/uinput
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99596\"][{POST_SNAPBACK}][/a][/div]
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.
-
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.
-
Willing, eager to alpha/beta test a Targus keyboard on a 5000D. Let me know when you have a version for it.
Felipe
-
* 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.
* I would like to be able to use the driver as non-root also, however ...
Try the following (as root):
# chmod 666 /dev/misc/uinputThat should allow non-root users to open the uinput device.
Thanks, this and chmod-ing /dev/tty/1 to 666 did it.
-
Anyone care to donate a C1000? Would sure make it easier to debug.
If not, perhaps one of you C1000/C3100 owners could run the following command for me:
# find /dev -ls | /home/root/dev_ls.txtand then post the resulting dev_ls.txt file here? Thanks!
-
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:
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99712\"][{POST_SNAPBACK}][/a][/div]
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.
-
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.
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=99909\"][{POST_SNAPBACK}][/a][/div]
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!
-
I've PMed you some key codes for the Palm Universal Wireless Keyboard.
Thanks for your swell work on this!
-
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).
-
Any idea on how to fix the right click on the SL-6000?
-
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 :">
-
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 (http://kopsisengineering.com/kopsis/IrKeyboardDrivers) 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
-
Wow, Your weekend comes so fast (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 I hope that u understand whay i try to explain :">
Thanks alot !
-
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.
-
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:
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
0x00000000Ignore 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
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.
-
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.)
-
Thanks g33k! I knew moving the drivers from compiled-in code to editable scripts was a good idea
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).
-
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.
-
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.
-
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?
-
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.
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103142\"][{POST_SNAPBACK}][/a][/div]
Thanks for the review! That is just what I needed. Honestly, what I really want is to plug in a full size keyboard, but I'm not sure if I want to upgrade to a C3100 just yet or not.
Sounds like the Belkin is more what I need.
Someone is selling a whole bunch of them on Ebay now for $20 plus $8 shipping. (Though it doesn't look like he ships outside of the US/CAN). Just do a search for F8U1500 on Ebay and you will see them.
Hopefull the differnences between the T and non-T version can be worked out in the drivers.
-
Hi, I'm using SL-C860 & RC12.
I tried your driver with my Pocketop keyboard. Thank you for your great work ! It
encourages me to migrate to pdaXrom. Below are several problems that I
noticed. Sorry if similar problems have already been posted.
(1) With modifier key (Shift/Ctrl) pressed down, press & release any key (say,
'a'), and it works fine. but once you press 'a' again, it repeats forever until
you press a different key. I'm Emacs user so it is a little annoying .
(2) '^' cannot be input. I can type '6' but Punct modifier doesn't work.
(3) Caps Lock doesn't work by itself; I need to press Shift and Caps Lock down
at the same time to make it work. (Is it as intended?)
Thanks.
-
For what it's worth, my Belkin F8U1500-E works great with the 1500t driver
under rc10 on my 760... I assume it'll be just as good with rc12. Thanks a bunch!
-
Hi,
The problem mentioned above might be due to my operation problem, but anyway, being interested, I tried to download the source code to see whether I can do anything by myself. However, the link to the source code at http://kopsisengineering.com/kopsis/ZkbddDownload (http://kopsisengineering.com/kopsis/ZkbddDownload) is invalid. Can you please fix it or tell me where it is available?
-
Source code download link is fixed.
-
I am attempting to get zkbdd to work on my c3100. I have installed all 3 ipks from http://kopsisengineering.com/rc11/Zaurus-C1000-C3100/feed (http://kopsisengineering.com/rc11/Zaurus-C1000-C3100/feed)
I modprobe uinput and shows up in lsmod. Then when I start zkbdd from a terminal the following error comes up:
failed to open uinput device: No such file or directory
init uinput failed
I eventually will use a ThinkOutside ir keyboard, but first I just need to get zkbdd to work. This error comes up if I try the default keyboard, or with zkbdd -t palm_wireless, zkbdd -t targus, etc. All the lua files are confirmed to reside in /usr/share/zkbdd/drivers and are readable by root (who I am logged in as)
Does somebody know what file or directory it might be referring to?
I have a c3100 running pdaxrom rc12.
-
I modprobe uinput and shows up in lsmod. Then when I start zkbdd from a terminal the following error comes up:
failed to open uinput device: No such file or directory
init uinput failed
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=103785\")
The solution is a [a href=\"https://www.oesf.org/forums/index.php?showtopic=15484&view=findpost&p=99596]few posts back[/url].
-
My 6k on rc12 (with a hot plugging usb mouse) is once again a tiny laptop. The drivers are excellent! Thanks,
ADF
-
Just got a Belkin f8u1500t (Ebay). Very cool.
First annoyance though, if I hit CAPS Lock and then hit the backspace key, the Z suspends. I am guessing this has something to do with the fact that the backspace key has a sub-function of "off", but I thought that should realte to the Fn key and not the Caps Lock?
Anyway, I guess I can muck with the keymapping myself now, so I'll go take a look see.
Again, thanks Kopsis, this is awesome!
EDIT: Is there a way to map to the MAIL, HOME and MENU keys? I find the ACTIVITY and CONTACTS key in the list, but I can't find the other three.
Thanks.
-
Hi zaurus_usa, Kopsis,
I had the same problem as (1) mentioned by zaurus_usa, and looked at the code.
It seems last_keyup wasn't cleared and it was filtering keyup signal when the same key was *actually* repeated. I changed
/usr/share/zkbdd/drivers/pocketop.lua as follows (from line 146):
from:
-- filter final keyup signal
if key_down == 0 then
if key == last_keyup then
last_keyup = 0
return 0, key_down
end
last_keyup = key;
endto:
-- filter final keyup signal
if key_down == 0 then
if key == last_keyup then
last_keyup = 0
return 0, key_down
end
last_keyup = key;
elseif key == last_keyup
last_keyup = 0;
endand now it seems to be working correctly.
---
Katsu
-
Hi !
Test on a C860 with SK6688 wireless keyboard :
It works with anything driver but :
When typing a key the caractere still be tiped until I press another key ...
So :
aaaaaaaaaaaaaaaaaaaaaaaaaaazzzzzzzzzzzzzzzzzzzzzzzeeeeeeeeeeeeerrrrrrrrrr
I think you can understand me ;-)
-
When typing a key the caractere still be tiped until I press another key ...
So :
aaaaaaaaaaaaaaaaaaaaaaaaaaazzzzzzzzzzzzzzzzzzzzzzzeeeeeeeeeeeeerrrrrrrrrr
I think you can understand me ;-)
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=105137\")
I do understand the "stuck key" problem you describe. It is caused by the keyboard encoding keystrokes in a way that none of the existing drivers understand. You would need a driver specifically for the SK6688. Unfortunately I do not have the technical information needed to create that driver.
If you can follow [a href=\"http://kopsisengineering.com/kopsis/ZkbddAddingKeyboards]these instructions[/url] and send me the resulting information, I might be able to add an SK6688 driver to the next release (though it may take a few releases to get all the bugs out).
Alternatively, if anyone wants to send me an SK6688, I can easily learn how it works and get a working driver in the next release
-
I'have try to have scancode of the keyboard but I have a strange probleme.
A complete press up and down sequence give me about 20 scancode and never the same sequence with the same key ! Thats so funny because when I use a normal driver the correct key is pressed ! Normaly I thing that the scancode of a key can't change right ? So correct me when I have made anything wrong but I don't understand ...
-
I guess I am one of the few lucky ones, my Belkin keyboard is a model F8U1500 no "T" on the end. I have confirmed that the protocol it uses is moderately different from the T model. The map is the same but the noT model uses 2 bytes for each key down and key up. For example using zkbdd -d -t test9600 settings pressing the "a" key outputs 66 65 then letting up on the key produces 193 193
All the keys are similar in that that the key group is first then the key map#, and on key another key group is repeated twice.
I would like to modify the belkin_f8u1500t.lua file to work with the noT model. But first I need a little clarification on exactly how zkbdd uses the lua files. Looking at the source I am guessing that zkbdd calls on the function do_scancode (s) from the lua file. Is this function called for each byte or only once per keypress/release event?
Also since the extra guard bytes are not present (like in the withT model) I need details so I can get the logic correct. I have posted the map file I made for each key on the F8U1500 keyboard, just know that on the keyup event the code given in repeated each time.
Thanks for any input.
-
Will this run on the new version of pdaxrom yet?
-
What model of pocketop keyboards work?
-
The zkbdd driver seems to have stopped working for me on Belkin f8u1500t beginning with 1.1.0. Beta1.
This is both with the zkbdd ipk in the official feed and the one from Kopsis (both are presumably compiled from the same source).
The uinput module gets successfully loaded (keybdev should be in the kernel) and the driver starts successfully. No /dev/misc/uinput device gets created, but /dev/uinput exists. Interestingly, using the -d switch I can see the scancodes are being registered, but no actual symbols appear on the screen. This happens both in console and in aterm/X under the root account.
Is someone using successfully an IR keyboard with a version equal to, or newer, than Beta1?
-
The uinput module gets successfully loaded (keybdev should be in the kernel) and the driver starts successfully. No /dev/misc/uinput device gets created, but /dev/uinput exists. Interestingly, using the -d switch I can see the scancodes are being registered, but no actual symbols appear on the screen. This happens both in console and in aterm/X under the root account.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=117219\"][{POST_SNAPBACK}][/a][/div]
The only suggestion I can offer at the moment is try symlinking /dev/misk/uinput to the existing /dev/uinput and see if that helps. It's been a while since I've been able to look at any of this and I'm not sure when I'll be able to revisit it. The combination of a company VPN that needs proprietary Windows software (i.e. a laptop) to access and a smartphone that can handle all the Z's old PIM duties has left my poor old Z collecting dust for a few months now (and with it my Z devel projects). I hate it when I have so many projects all competing for so little free time
BTW - getting the scancodes in is easy ... that's just reading from a com port so I'm not surprised it still works. Getting the resulting keystrokes into the input queue is the hard part. That's where uinput comes in so clearly that's where the breakage is.
-
I have a Belkin working with 1.1.0 Beta 1 on a C860.
I hope I'm not stating the obvious here but unless I run
# modprobe keybdev
# modprobe uinput
it doesn't work and complains with uinput no such file or directory errror.
Hope that helps.
ltrm
-
Found somebody selling a F8U1500 (NOT T) cheap. From reading this discussion it sounds like the drivers don't work 100% for this specific keyboard yet. Is this correct? I have a SL-C1000.
-
Is someone using successfully an IR keyboard with a version equal to, or newer, than Beta1?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=117219\"][{POST_SNAPBACK}][/a][/div]
Just to add to the assurances. I have a f8u1500t and it works fine on my 760 with Beta1.
-
In the meantime I reflashed to 1.1.0Beta2 and I can indeed confirm that both Targus PA 870U V3 and Belkin f8u1500t work. The keymaps seem slightly off (can't type some chars like "." etc.), but will look later into this.
-
Hey there-
Zaurus: c860 running pdaxrom 1.1.0beta-1
Keyboard: micro-innovations universal wireless keyboard (design by Pocketop).
Installation:
ipkg install zkbdd (it was in the feed! woo!)
modprobe keybdev
modprobe uinput
Using the pocketop driver. Here are the few problems:
Problem #1: sticky keys
Problem #2: cannot type the ^ which is [punct][6]
In the test mode [punct][6] is registers and I remember reading in the thread about key mappings so I'm sure this is fixable.
Problem #3: After some time the keymapping goes a bit strange/nuts. Including both IR keyboard and clamshell keyboard. I think it is after a certain set of keystrokes and I'm guessing it is with one of the "special" keys (caps lock, shift, ctrl, punct, cmd, num, etc..) at which point I need to reboot the zaurus
Overall: The stickey keys are mostly a nuisance when typing in passwords. Rebooting is a bit of a nuisance too. But other than that works great. Thanks!
Also as far as starting and killing, i basically use these aliases in my .bashrc file and it works for me. Shouldn't be any implications of running the modprobes repeatedly should you be typing the "keyon" command repeatedly
alias keyon='modprobe keybdev; modprobe uinput; zkbdd -t pocketop &'
alias keyoff='killall zkbdd'
Thanks again
-
Are there any keyboard drivers for beta4 and the 2.6 kernel?
darmou
-
Does anyone know of a new source for the kernal-modules-input from Kopsis? His feed is down.
-
Oops. Looks like in the process of doing some website cleanup I accidentally nuked my rc11 feed. I think I have a backup tucked away on an offline machine. I'll try to get it back on the website this weekend.
On the off chance that the backup isn't recoverable, I encourage anyone who happens to have copies of the .ipks to PM me -- if I have to rebuild from source, it could be a while before I can get this restored.
-
kopsis: any plans to get zkbdd working under 2.6 kernel?
-
kopsis: any plans to get zkbdd working under 2.6 kernel?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=133539\"][{POST_SNAPBACK}][/a][/div]
Funny you should mention that. Things aren't looking good for my backup so I was just sitting wondering what to do about rebuilding. Unfortunately I have no idea which version of pdaXrom to target. Beta1 uses basically the Sharp kernels, Beta2 moved the C7X0 to some mystery 2.4.20 kernel. Beta3/Beta4 look to be 2.6 based but I have no idea about the specifics. And it sounds like there's a new beta in the works so kernels could change again.
I don't want to go through the time and trouble of building again for 2.4.x if that's likely to be a dead end. And the 2.6.x versions of pdaXrom aren't stable enough yet for me to spend time on. I could switch to OZ to maybe get a more stable 2.6.x, but I'll never find time to get over the build system learning curve. My hat's off to those of you who can keep up with the endless ROM shuffles ... I just don't have that kind of time these days :( I switched from a Linux desktop to a Mac early this year because I got tired of constant high maintenance updates and the associated system breakage. I'm sort of at the same point with the Zaurus.
I could rant on and on about what's wrong with the various ROMs, but I'll spare everyone the flame war that would be sure to follow. Suffices to say that until a ROM comes out that lets me update without a) trashing the way I had the last version set up, B) forcing me to reinstall a pile of applications, and c) forcing me to rebuild my own custom software because the kernel keeps changing, my Z will probably sit on the shelf.
As for Zkbdd, I don't know if I even will rebuild it at this point. My time may be better spent documenting how to build it and then leave it up to the various ROM maintainers to decide if they want to support it in their kernels and package the app for their feeds. Z development is just too much of a fragmented, aimless, poorly documented mess to entice me to commit much of my very sparse free time. That's a shame because it had so much potential.
-
Hey guys,
I have a Collie 5500 running OpenZaurus 3.5.4 (I know this is the wrong forum, but this is the only discussion I could find related to kbdd) and I have installed kbdd and uinput with success (obtained from the OZ3.5.4 feed, kbdd version .1) using the instructions in this thread (creating the /dev/misc/uinput dir and mknod). My only problem is this: When I run kbdd with the -d option, I can see press and release on my Belkin F8U1500 (NOT T) perfectly. When I simply run kbdd without the -d option, nothing happens upon keystoke. It seems the strokes are recognized, but just not turned into keyboard input.
Is there any way to solve this?
-
Update: Upon restart, kbdd wasn't functional until I did "mkdir /dev/misc/" and "mknod /dev/misc/uinput c 10 223" and "ln -s /dev/misc/uinput /dev/uinput". Is there a way to make these commands permenant?
At this point, keystroke were registered when the -d option was enabled. Then, when I ran without the -d option, keystrokes were displayed on screen! The only problem is they are absolutley incorrect, nothing is mapped properly (left is $, up is ", right is _, ect). Should I be changing maps out for the F8U1500 or something? Any help is appreciated.
An interesing irony: The T key works perfectly on my F8U1500 (NOT T). I read previously in the thread that the non T models are not supported, should I just get to painstakingly mapping my own maps using the instructions in this thread?
-
Update: I installed zkbdd version .2 and got the recognition of scan codes using the test9600 driver, but am unable to even get incorrect input via the f8u1500t driver. I had to edit the f8u1500t.lua file and add quotes around all statements including hex, it would give a syntax error otherwise.
I am up for writing a driver for the f8u1500 if I can get this working, I bought the damn keyboard and I will not let my 20 bucks go to waste.
Please give any input you could possibly offer, it would be sweet if this page http://kopsisengineering.com/kopsis/ZkbddAddingKeyboards (http://kopsisengineering.com/kopsis/ZkbddAddingKeyboards) was finished, I wouldn't have to ask any questions. Re-writing a driver is pretty confusing via the description gave earlier in this thread.
Thanks!
-
Update: I installed zkbdd version .2 and got the recognition of scan codes using the test9600 driver, but am unable to even get incorrect input via the f8u1500t driver. I had to edit the f8u1500t.lua file and add quotes around all statements including hex, it would give a syntax error otherwise.
Zkbdd was designed to use a patched version of the Lua interpreter that handles hex literals and bitwise operations. The zkbdd Lua scripts won't work with the standard OE version of Lua.
I'm actually in the process of getting all this going on OZ 3.5.4.1. I'm switching to using Lua 5.1 and a library for bitwise functions rather than patching the Lua core. Once that's done (and I've tweaked the scripts accordingly), it's just a matter of making the daemon look in the right spots for the uinput device and we should be good to go.
I'm going to be slammed the first half of this week but I may be able to get something going by towards the week's end. PM me your email address if you like and I'll send you ipks when the first beta is ready.
-
kopsis: If you need tosa/2.6 poodle/2.6 c7x0/2.6 testing then msg me and I will look.
-
Hi, good day.
I am using a 3100 with pdaXrom beta3 and the palm IRkeyboard 3169ww.
using zkbdd works fine!, but some key are wrong, I mean:
I read other posts and I took a look at /usr/share/zkbdd/drivers/palm_3169ww.lua, the file looks good, so I check the /usr/share/zkbdd/drivers/ztokens.lua and something seems tobe wrong there.
Becase, for example, when I press the "Shift right key" I got a ".", and if I press "period key" I got other character.
In the ztokens.lua file there is a kind of table that had relation of tokens and codes:
ZK_PERIOD = 64
...
ZK_SHIFTR = 103
but I changed it to: ZK_PERIODTMP = 64 ... ZK_PERIOD = 103
Only in that way I got a correct token link.
My doubt is, How was created th token table??
Where can I find the other symbols like "@", "&"??
Because they seems to be lost and I do not know how find them.
It looks like this:
IRkeyboard -> zkbdddriver -> palm_3169ww.lua -> ztokens (X seems to be wrong)-> Zaurus
Thanks a lot and Best Regards,
-
but I changed it to: ZK_PERIODTMP = 64 ... ZK_PERIOD = 103
Only in that way I got a correct token link.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=139401\"][{POST_SNAPBACK}][/a][/div]
Ok, the problem isn't in ztokens, it's in the scancode maps in the palm_3169ww.lua file. The way things work is that the palm_3169ww.lua file converts scancodes from the keyboard into a Zaurus keyboard scancode. When you hit "shift" on your kb, it's getting turned into ZK_PERIOD which is wrong. Changing ZK_PERIOD in ztokens just masks the problem and will break badly if you ever try to use a different keyboard.
What you need to do is edit palm_3169ww.lua and look at line 65. Note how the 7th entry on that line is "ZK_PERIOD". What that is telling zkbdd is that if it sees a 0x2e scancode, it should send the Zaurus the ZK_PERIOD scancode. Now, apparently on your keyboard it's "right shift" and not "period" that sends the 0x2e scancode. So you need to replace ZK_PERIOD on that line with ZK_SHIFTR. Similarly you need to find out what scancode your keyboard is sending when you press "period" and replace that entry in the "map_normal" list with ZK_PERIOD. You can see scancodes by running zkbdd in a terminal with the test9600 driver.
Once you get the hang of this, it becomes pretty easy to fix any misbehaving key without touching ztokens. Once you get it sorted out, send me a copy of your modified palm_3169ww.lua file and I'll incorporate it into the next release of zkbdd.
-
Hi, good day
Sorry for write to you until now, but I could not yesterday.
Last night I was working with the keyboard again trying to fix some keys.
I followed the advice of Kopsis, I leave the ztokens.lua as original and work just on the palm_3169ww.lua.
On normal way it almost works with all keys now, but there is something wrong with the use of "Shift" and "Caps" keys, it is funny because sometimes the Shift key works like Caps.
But the problem (I guess) is with the map_shift array of the tokens, for example, when I press a key (with shift or caps mode), I get an scancode, it is ok, but when I look for the scancode in the map_shift it is 0 !!.
and example is with the key of the "@" I got an scancode of 0x79, and looking at the array it is 0, but it is funny because just a line before there is the token ZK_AT, at the scancode 0x71, the same occur with other keys using shift or caps.
I guess that this has a relation with others comments about that when they press a key like " they got a number, it seems that in normal way the zkbdd use a kind of "keycode & filter" in binary add,
Could that means we can only use some tokens just in shift or caps ??
I feel a little blind because I would like to use some keys but I do not know what token name match with that character.
Any advice??
or a little explication about how this works??
Thanks in advance and best regards.
-
But the problem (I guess) is with the map_shift array of the tokens, for example, when I press a key (with shift or caps mode), I get an scancode, it is ok, but when I look for the scancode in the map_shift it is 0 !!.
Ok, the first thing I should point out is don't trust my maps I don't have a Palm keyboard so the maps in the driver came from me trying to reverse engineer the keymaps using the IRK driver source code and fuzzy photos of the keyboard scrounged from various websites.
and example is with the key of the "@" I got an scancode of 0x79, and looking at the array it is 0, but it is funny because just a line before there is the token ZK_AT, at the scancode 0x71, the same occur with other keys using shift or caps.
That just means that I screwed up Change the 0 to ZK_AT and change the ZK_AT to 0.
The way things work is if the driver sees a scancode with the shift key down, it looks up that scancode in the "map_shift" array. If there's a token there, the driver sends it. If there's a 0 there, the drivers sends "shift down, token from map_normal, shift up". The Zaurus is a little odd in that respect. For some characters is expects a shift token followed by the regular key token, for others (like "@") it has special dedicated tokens that must be sent without the shift key.
I feel a little blind because I would like to use some keys but I do not know what token name match with that character.
Basically the only tokens that need to be in the "map_shift" table are those that are already there. You may just need to move them around to get them matched to the right keys.
Note that the "function" maps are similar. If the function key is down, the driver looks up the scancode in the map_fn (or whatever I called it). If there's a token there, the driver sends it. But if there's a zero there, the driver sends nothing.
-
Hi, good day,
Last weekend I was working on palm_3169ww.lua config file, but I could not find the "@" symbol, I do not know which code is, I mean I know which key is pressed and the scancode got, but the problem is that no one ztoken seems works.
I tried using "xev" command and I got something like this:
Pressing "-" key from palmkeyboard with "zkbdd -d swtich" I got:
(which gives scancode(normal_map,0x29)-> ZK_PLUS -> token 59):
Pressing "-" key from palmkeyboard with "xev" I got:
state 0x2000, keycode 67 (keysym 0x2d, minus), same_screen YES,
XKeysymToKeycode return keycode: 63
XLookupString gives 1 byte: (2d) "-"
It works fine, but the problem is with other symbols, for me the most important is "@" that I cannot find I got this trying to get "@":
Pressing "@" key from palmkeyboard with "zkbdd -d swtich" I got:
(which gives scancode(normal_map,0x79)-> ZK_AT -> token 61):
Pressing "@" key from palmkeyboard with "xev" I got:
state 0x0, keycode 67 (keysym 0x0, NoSymbol), same_screen YES,
XKeysymToKeycode return keycode:
XLookupString gives 0 byte:
I do not what to do or how the ztoken filter works, I guess that ztokens are translated to other keycodes which Zaurus gets.
Besides its funny that some scancodes works different if you use then in the map_normal or in map_shift.
Any advice please??, How could I know the way to get "@" symbol??
Best Regards,
-
Hi. I rewrite key maps for targus and use zaur 760 with HP iPaq Bluetooth Keyboard (HighScreen). Work fine.
Have next trouble with:
1) '^' cannot be input.
2) Caps Lock doesn't work by itself; I need to press Shift and Caps Lock down
at the same time to make it work.
3) 'Delete' not worked
4) Symbol ',' printed as '/' (mapped in corgy key map)
need create different keymaps and load it ?
-
anybody has 2.4.18 kernel uinput module for tosa?
-
For what it's worth, my Belkin F8U1500-E works great with the 1500t driver
under rc10 on my 760... I assume it'll be just as good with rc12. Thanks a bunch!
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103705\"][{POST_SNAPBACK}][/a][/div]
How did you get the / or any punctuation to work with the F81500-e?
I'm confused on how to make changes to the lua file.
Thanks for any help.