This phone have a special keyboard where each key represent two key depending if up push the left or rigth side of the button.Keycodes are represented like XXX;YYYwhere XXX represent leftside keystroke and yyy is right-side keystroke.

special buttons.Back button on left side of phone: -11Scroll button on left side: Up=-1; Down=-2

Camera button on right side: -25Email button on right side: Nomap

There seem to be a touch area activted on the screen when I run KeyCodes.jarI don´t know if it is something that is implemented within keycodes or if itis a phone feature.KeyCodes app display on all parts of screen except in the menu areas.So The "tap" functionality is inside keycodes app area somehow.Don´t know how to explain it better since english is not my native language.|-------------------|| OS menus etc. ||-------------------|| Keycodes.jar || || || || || ||-------------------|| | || | || -6 | -7 || | || | ||-------------------|| OS menus etc. ||-------------------|

I have also got the JavaMO built and installed. Again, thanks for the great work!

I tried this on a Sony Ericsson W580 and a K800i. As others have mentioned, there is some issues with key codes. I was able to navigate the orbiter menus using the numeric keys, but the 'Select' and 'Back' functions were missing (I tried all keys on the phone). So this kind of reduces it usefulness (for now) .Both phones were the same wrt. keys, which is expected since they both are somewhat similar SE phones.

But I would like to make a humble suggestion:Shouldn't key code mapping be a part of the device template?This allows for easier addition of new phones (with potentially different key mappings). In this scenario, the key codes would be sent as raw data from the JavaMO to the bluetooth dongle device, which would do the translation using the loaded device configuration.The JavaMO would be the same for all Java phones (at least in theory).Maybe the correct device template could be automatically selected based on the MAC address of the phone.

I realise that this would require some changes to existing software, but in my mind it would be a much more flexible approach. I suppose the existing orbiter software would have to be changed to send the raw keycodes, and the bluetooth device extended to load configuration and do the conversion of key code to LMCE orbiter actions.

Please have in mind that this is only a suggestion based on my limited understanding of how it works. If it is not possible, or very hard to do, just forget this message

i've done the basic routines but they are untested as I have no J2ME phone with touchscreen. You can get the compiled java app from the svn.charonmedia.org/svn/home/hari/javamo/output/.You prolly have to switch the UI variant from symbian to UI1.

I tried this on a Sony Ericsson W580 and a K800i. As others have mentioned, there is some issues with key codes. I was able to navigate the orbiter menus using the numeric keys, but the 'Select' and 'Back' functions were missing (I tried all keys on the phone). So this kind of reduces it usefulness (for now) .Both phones were the same wrt. keys, which is expected since they both are somewhat similar SE phones.

did you already post the results from the Keycodes run? I will implement all given keycodes with a phone ID over the next days.

Quote

But I would like to make a humble suggestion:Shouldn't key code mapping be a part of the device template?

yeah, good idea, but the actual Bluetooth_Dongle does not handle that. Let's see after a few more keycodes dumps how many variants of actual users we've got. After that I'll decide if it's worth the hassle to adapt the Bluetooth_Dongle (keep in mind that we have to be downwards compatible with the symbian mo).

did you already post the results from the Keycodes run? I will implement all given keycodes with a phone ID over the next days.

No, I didn't, but I suspect my key codes to be identical to what niz23 posted a while back. It also being from a similar Sony Ericsson phone.Do you detect key mappings based on a specific phone ID, or do you select it from a wider range, for instance a phone series like "SonyEricsson W-series", "Nokia N-series" etc.?

But I would like to make a humble suggestion:Shouldn't key code mapping be a part of the device template?

yeah, good idea, but the actual Bluetooth_Dongle does not handle that. Let's see after a few more keycodes dumps how many variants of actual users we've got. After that I'll decide if it's worth the hassle to adapt the Bluetooth_Dongle (keep in mind that we have to be downwards compatible with the symbian mo).

Yes, it was merely a suggestion of a more generic solution. As you say, it might not be needed if the number of phone key mappings are limited.

Ive copied to the core in /usr/pluto/lib the file libBDCommon.so from http://vt100.at/javamo/ . I rebooted the core. I sent from my laptop over bluetooth to my phone the .jar and .jad files and the manifest.mf file. I then loaded the app on my phone and it says 'waiting for connection'. My core picked up the phone and presents the usual phone adding menu. I select Symbian and it sends a file to my phone. I reject the file and the core says sending failed. I tell it not to send again. I then reboot the core. It generates some orbiter screens and then loads into its UI. The phone still says 'waiting for connection'. If i leave the app and enter back into it, it stills says 'waiting for connection'. Have i missed something or is javamo incomptabile with my phone?Thanks

I dont have a Bluetooth_Dongle_Launcher in the /var/log/pluto folder on the core. Could this be hinting at an underlying problem on my core? I do have 76_LaunchBluetooth_Dongle.sh.log in that folder though.

I dont have a Bluetooth_Dongle_Launcher in the /var/log/pluto folder on the core. Could this be hinting at an underlying problem on my core? I do have 76_LaunchBluetooth_Dongle.sh.log in that folder though.

Solved! Plugged in a different bluetooth dongle and it connected imediadatly. Seems like the previous dongle although worked in linux and could pick up devices could not connect to devices. Unlike this dongle