Just keeps dying. The Bluetooth dongle is listed in lsusb as Broadcom Corp. BCM2035 Bluetooth. Is replacing it with a different dongle the only solution? Seems to work fine otherwise....

Incidentally - it didn't seem to have this problem of dying (in the log file) initially. That was before I replaced the libBDcommon.so library and rebooted. After rebooting, then these device failures started....

I have a Nokia E65 and I have succesfully installed JavaMO following the instructions found on this thread and on wiki pages. I have a minor issue with the red button, the one that usually stops calls and should also stop media player. Whenever I press that button the JavaMO closes without throwing any error. It simply exits.Is this a known issue, or it's related to something wrong I could have done?

Second question. On the wiki page there is a nice picture of a Nokia E65 with JavaMO running with a UI1 skin (http://wiki.linuxmce.org/index.php/Image:Javamo-e65-ui1.jpg) . I was able to reproduce the same situation, i.e. I have UI1 on my E65. Using the cursor I'm also able to highlight the different buttons on the orbiter, but so far I've not found any way to "press" any button, i.e. once I select "Video" I can't go to the media listing. I've tried to press anything on my phone with no result.

Is the UI1 skin supposed to work normally also on Nokia E65, or is it just something still in development?In case it is supposed to work, can anyone give me a hint or point me in some direction in order to find out what the problem is?

Actually it's my picture I played with JavaMO in LinuxMCE 0710 Beta 4 I think. At that time it should be built from the sources. As I remember I was able to navigate. But I'm not sure how. Maybe just by pressing central button ('OK') or maybe I used digits to go in sub-menu.

this is mostly for sure a mapping problem with the keys. Run the keycodes application and post your keys. There is a translation method in the JavaMO main class. You could tweak that. The source compiles with standard make, you need to have a java sdk and the wireless toolkit from sun installed (tweak the paths in the makefile, wiki instructions available on the JavaMO page)

There is a bit of a backlog. The basic work for a nice JavaMO is already done. It needs better keypress handling (supporting different phones, repeated key handling). Pointer support for touchscreens is already implemented in the latest svn rev.

I'm pretty busy with Z-Wave at the moment, but sadly enough nobody feels like doing a bit of J2ME polishing...The Bluetooth_Dongle code would also need some research. We could prerender datagrids with todays resolutions of phones.

what is the financial work involved to get a certificate that the java phones would like?

-Thom

I'm sorry to revive a posting from April 2008, and am new to the , but reading through the remainder of the thread it seemed that this didn't get a definitive answer, and it's info we will want as we go through this to work on as many phones as possible around the world.

Option A: Adding your own certBasically, for a large % of the JavaME phones out on the market, you can't add your own cert to the root cert on the device, which means you have to sign with a certificate chained off the root cert baked onto the phone. Even in some of the devices where you can, it's inconsistent since some operators block it, others don't, others didn't bake the root certs on, etc (see http://www.spindriftpages.net/blog/dave/2006/06/18/midlet-jar-signing-a-tutorial-revised/... So the add-your-own-cert route doesn't really work consistently -- plus we'd get into distribution issues (you have to get the cert out to people, they have to put it into their certificate chain, etc.).

Option B: Getting someone with the root cert to sign it for youThis means getting the cell phone carriers to sign a midlet. Good luck. Some cell providers do make this somewhat simpler through their developer programs (Vodafone, Sprint, Orange) but you still have to pass through some hoops. Plus this only ends up working on their phones.

Option C: Java Verified certThis might be desirable if we (a) get the MIDlet to a point where it is completely stable and released and (b) we are willing to deal with the fact that any changes to the midlet invalidate the signature and (c) it involves paying someone to test the application and validate it works. It's not expensive (about USD$120 per midlet), and the suite checks that the MIDlet doesn't misbehave in very known conditions that cause MIDlets to misbehave (incoming calls, incoming SMS, reduced memory conditions, low battery,poor coverage, etc.). I'd be willing to pay for a couple of cycles of certification if it meant we would get a solid codebase. But this also means that once we get a signature, we have to get into a release-cycle mode of thinking. This option is not very consistent with the FOSS mindset in general -- but mobile devices are really not in the FOSS universe in any event. The benefit of doing this is that once you have the midlet signed with Java Verified, you know it will install with full permissions on any phone that has a Java Verified root cert.

The good newsThe good news, however, is that the vast majority of JavaME phones out there that support JSR 82 don't block Bluetooth access from untrusted midlets completely -- they usually are set to prompt only once in midlet execution permission, and a very large number of them let the user override this setting to let the midlet have permanent permission. This varies device-by-device. So it means we probably don't have to pursue this avenue. Most I've seen enable it without difficulty by default.

BTW -- I'm saying "we" here a lot. Hari -- you've done a great job with this. Please count me in for development assistance -- I've been working with Java ME developer communities for years and can weave my way around a MIDlet pretty well. I'll spend some time looking through the most recent code from svn and see if there are any common MIDlet gotchas we can foresee.

Please count me in for development assistance -- I've been working with Java ME developer communities for years and can weave my way around a MIDlet pretty well. I'll spend some time looking through the most recent code from svn and see if there are any common MIDlet gotchas we can foresee.

this is mostly for sure a mapping problem with the keys. Run the keycodes application and post your keys. There is a translation method in the JavaMO main class. You could tweak that. The source compiles with standard make, you need to have a java sdk and the wireless toolkit from sun installed (tweak the paths in the makefile, wiki instructions available on the JavaMO page)

There is a bit of a backlog. The basic work for a nice JavaMO is already done. It needs better keypress handling (supporting different phones, repeated key handling). Pointer support for touchscreens is already implemented in the latest svn rev.

I'm pretty busy with Z-Wave at the moment, but sadly enough nobody feels like doing a bit of J2ME polishing...The Bluetooth_Dongle code would also need some research. We could prerender datagrids with todays resolutions of phones.

best regards,Hari

I downloaded keycode application and ran it on my E65, but it fails to show the keycode of those keys that are giving troubles ...It looks like they are intercepted by phone and not passed to keycode.jar

I've googled around and it seems like there are not that much keycode - scancode applications, nor I found any keycode table for E65.The only thing I've found is something called jbak tools, that is a native S60 applications that among others offers a keycode function. Unfortunately I could not have it working on my phone (needs to be signed, but the open signed site won't sign it ... did not figure out why ...).

So I'm pretty clueless.

My fear is that if keycodes (that is a J2ME app) can't catch some keypress, so also JavaMO won't be able to catch them as well, and this may be due to some J2ME limitations.Therefore JavaMO would be pretty useless on that class of mobile phones.

It looks like they are intercepted by phone and not passed to keycode.jar

[...]

My fear is that if keycodes (that is a J2ME app) can't catch some keypress, so also JavaMO won't be able to catch them as well, and this may be due to some J2ME limitations.

This is no j2me limitation, it is the implementation on the nokia phones. SE ones pass nearly every key to java, the nokias don't. So you e.g. don't get keypresses for the red "hang up" key or the multimedia buttons.The original mobile orbiter variant was done for the symbian app on the phone. With c++ you can catch every key on the nokias.

Quote

Therefore JavaMO would be pretty useless on that class of mobile phones.

We need a slightly optimized variation/skin for those. Many phones feature a touchscreen, too. Maybe we can get more keys with python on the Nokias. Posde is working on that.

It looks like they are intercepted by phone and not passed to keycode.jar

[...]

My fear is that if keycodes (that is a J2ME app) can't catch some keypress, so also JavaMO won't be able to catch them as well, and this may be due to some J2ME limitations.

This is no j2me limitation, it is the implementation on the nokia phones. SE ones pass nearly every key to java, the nokias don't. So you e.g. don't get keypresses for the red "hang up" key or the multimedia buttons.The original mobile orbiter variant was done for the symbian app on the phone. With c++ you can catch every key on the nokias.

Glad to hear that I was wrong... and most of all that I'm not (yet) supposed to throw away my six month old E65 and my wife's brand new N82 ...

Quote

Quote

Therefore JavaMO would be pretty useless on that class of mobile phones.

We need a slightly optimized variation/skin for those. Many phones feature a touchscreen, too. Maybe we can get more keys with python on the Nokias. Posde is working on that.

br, Hari

I got the point.Probably it's really time to seriously try to make HADesigner working on my laptop ...