Help - Search - Members - Calendar
Full Version: Sl6000 Keyboard
OESF Portables Forum > Everything Else > Archived Forums > Distros, Development, and Model Specific Forums > Model Specific Forums > Sharp Zaurus > 6000 - Tosa
guylhem
Hello

I've made good progress recently on the SL6000 keyboard problem. If people here are interested, I'd like to get feedback on what they'd like to see fixed.

Currently working on fn+shift and long/short keypresses. The rec key is now much faster, and I'm experimenting with bindings (ex : I made a qkonsole where a single key moves you from tab to tab)
adf
how is usb keyboard working?

I asked this elsewhere, I think, but is it possible to do low-leverl ir keyboard support?

Also, I have been seeing a "sticky fn" --keyboard mode changes seem to get "stuck"is that just me? It has been a problem moving stuff aound w/ qtopia shut down--I suddenly get stuck in fn mode, when I get out, I lose it. very hard to move a dir and it's contents without "- " for example
scheck.r
Sane here for the sticky Fn key out of qtopia but you can kill it by pressing the HOME front key. quite anoying I have to admit.

romain
guylhem
Hello

Concerning external (usb/bluetooth/whatever) keyboards, I am still having problems due to mapping, and I'm exploring various ways to fix that. No perfect solution yet, but since I purchased an axim keyboard and I *want* it to work *now* you can expect a solution pretty soon - it's called Motivation, you know :-)

Regarding internal ir, I honnestly see no reason why it should be done. IRK does a pretty good job, and unlike bluetooth ir and serial keyboard are following "various" standards. Moreover it could cause problems to ir beaming, ir remote control etc.

So basically if it would technically better to have that driver in the kernel, it'd be much more complex and sounds like a bad idea,

Regarding sticky fn in console mode, this is due to my past attempts to have an external keyboard working correctly. It should be fixed soon, along with the rest of external keyboard problems.

I still don't understand how qtopia manage holdkeys.tbl etc. to do keyboard mapping so I may have to do that at kernel level.
adf
IRK is great, unless you move to an X based system.

Edited.

oops ir keyboard suport is though lirc, you are right there is no need to change that.

ANy ideas on how the ir keyboard might be used outside qtopia, or inside x using lirc? Is there anyway to setup, say, a dev/input/irkbd? or something along those lines?
It isn't terribly important, but it seems like something that shouldn't be so tied to the gui.
guylhem
There's a python program somewhere that predated IRK. It's not dependant on GUI and uses VNC kbdsim. Only works on the pocketop though, but you may like it.
cwaig
QUOTE(guylhem @ Mar 25 2005, 02:45 AM)
There's a python program somewhere that predated IRK. It's not dependant on GUI and uses VNC kbdsim. Only works on the pocketop though, but you may like it.
*


Actually, the Python driver came after IRK....
adf
Ah, the man w/ the ir answers smile.gif

Any shot of lower level lirc working w/ the belkin kbd? If so, maybe any pointers?
though, I guess I'm gonna be using Qtopia/Xqt alot, I think I'd like to get working with oz/gpe 3.5.3 too.
guylhem
Just a quick word to let you guys know that my remapping efforts have been a total success. Now my 6000 uses the right keys (like every linux system as demonstrated by showkey) which makes working with an external keyboard a simple matter of plugging the keyboard (if you don't have bluetooth :-) externe.net/zaurus/flash/kernel2/zImage

Additional advantage : I mapped hold keys events to every button, so one can have more shortcuts. I'm also taking advantage of that new kernel hacking session to get replace sharp "press on /" awful hack by something more standard.

At the moment I am working on the qtopia keytable and a small bug concerning the comma and dot keys. It will be posted soon. Don't use the kernel meanwhile - you will get *no* keyboard under Qtopia if you do.
adf
excellent. That will make life easier, even if I only use ir and usb externals.
cwaig
QUOTE(adf @ Mar 25 2005, 06:34 PM)
Ah, the man w/ the ir answers smile.gif

Any shot of lower level lirc working w/ the belkin kbd? If so, maybe any pointers?
though, I guess I'm gonna be using Qtopia/Xqt alot,  I think I'd like to get working with oz/gpe 3.5.3 too.
*


You don't need lirc - in fact, it'd get in the way....

The Belkin is an irda keyboard, so all you need is to open up /dev/ttyS1 (the idra serial port), then feed the interpretted keypress's to the kbdsim module to get native X11 support...
guylhem
Some quick notes for those who may be tempted to try the kernel2 :

The new zimage includes the keyboard patches. you don't have anything special to do to use them. Try to plug in your usb keyboard in console mode and try to use both the external then the internal keyboard. Tell me how you like that :-) and if there is any bug. The only problem will be with the keypad. That's due to the sharp keycode reservation which requests far too many keys. I had to reuse keypads keycodes. I am preparing a documentation so that anyone can proof read my approach and maybe correct it (it only a matter of spending enough time to assign non conflicting keycodes between the internal and the external keyboard. since I don't have a keypad on my keyboard, I just didn't do it.

Anyway you shouldn't use the zimage for anything. it will cause **major** problems to qtopia since qtopia will expect the previous keymap ie. read "no key at all will work". Not even the power key. This zimage is only suitable for people who don't use qtopia. If you do use X or console mode it's fine.

Sorry I didn't have time to upload the source code yet. will do that asap. I also have to document everything I did.

If you want to try the kernel2, add the "kbrequest" line to your /etc/inittab and use my /sbin/qt script instead of the default one. This will prevent qtopia from starting. You can also safely remove the "launch" command from /etc/inittab that was used by sharp to display "press on /".

Please also put the binaries from this directory where they should go (ex: openvt in /bin, with a symlink to open)

Now flash the kernel2 and reboot. When it has finished booting, simply press "record" key for more than 3 seconds : it will automatically spawn a new console for you and prevent qtopia from starting. Press power/record to scroll up/down in the console. A long press on power will take you back to the previous console. A long press on Ok or Cancel will move you from console to console. That's very cool because no getty/lauch/anything will eat memory if you don't need textmode, while it will still be able to display as many textmode consoles as you want if you need some. (press on record for 3 sec - you will get a new one anytime !)

That's it. I have to do qtopia .tbl files to make the kernel2 works with qtopia too.
seed
i have a probleme with my keyboard the shift key on the right dont respond i just put openzaurus on my device and i want ot know if the probleme come form the rom and i someone get the same problem
thank
guylhem
QUOTE(seed @ Apr 2 2005, 10:02 AM)
i have a probleme with my keyboard the shift key on the right dont respond i just put openzaurus on my device and i want ot know if the probleme come form the rom and i someone get the same problem
thank
*


It can come for a .map that's used by loadkeys. Don't know if oz does that.
Are you using my kernel or openzaurus? If you are using oz I can't help you. I only know my kernel keyboard driver at the moment since I'm actively changing it.

I will soon upload a newer version that fixes even more keyboard problems (working on the qt part - holdkeys.tbl keycode.tbl keysymbols.tbl are not documented anywhere :-(( and make a single 57 Mb part as promised.
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-2018 Invision Power Services, Inc.