RE: Power on device after being powered down
Giles Jones wrote: Indeed, most people don't care about the technical reasons for it. It's to be expected that the power management when the device is switched on may be weak, but why does the battery drain so fast when it's switched off? My understanding is that it's a bug and/or the power management software isn't doing its job yet. Do we need to remove the battery to ensure the phone is definitely powered down? At the moment, yes. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Convince me NOT to cancel my order.
[EMAIL PROTECTED] wrote: Why can't I get quality, authoritative answers to these questions? Hi Alan. I'm not affiliated with FIC in any way, but I thought I'd give you my viewpoint, for what it's worth. You are probably getting the answers they *can* give. Whether that can is because they don't know, or because the business side of the company is not allowed to, we can't know for certain, but I suspect it's the former. Unless I'm some kind of idiot, why would I want buy a GTA01 phone if the GTA02 was to follow shortly? Because you can get it sooner? Because you want to support the project? As others have said, because you can't fully test code without the real hardware? If you are an end user and not interested in helping with the development, UI design, artwork, and/or testing of the system as it is developed, then you probably do want to wait. Why am I not being given the choice to RIGHT NOW to be placed at the FRONT of the GTA02 sales queue? Probably because they don't want to offer for sale a phone they don't have in production yet? Why am I putting up with all this frustration reading about others who -have- their phones and why should I not just cancel my order?? You are the only one who can answer this question. Yes, it can be frustrating to wait. Even with a mid 2500's order number we waited until the 2nd batch of phones. We've even ordered another expecting to have to wait until sometime in September. You're not dealing with Verizon or ATT... FIC doesn't have a ton of people dedicated to processing consumer orders, nor do they have a stack of phones in a warehouse ready to be shipped out. However, I can tell you that I've seen prototype phones from other, much larger, manufacturers that take every bit as long to make it to market from the stage an early integrator gets to see them. In short, if you value having the hardware as soon as *possible*, keep your order. If you just want a phone with as many features as you can get...wait. Of course, if you wait, then the *next* phone (whatever it is) will be on the horizon...and your question will still be valid...and you can keep waiting...forever. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Greenphone is not GPL (was RE: At the risk of being flamed : State of software)
[EMAIL PROTECTED] wrote: Licensing = As mentioned, Qtopia is avaliable under the GPL. Strictly speaking it is more open than GTK+ which is distributed under the LGPL (Lesser GPL). ... On the other hand, Qtopia is avaliable under the GPL (The full on GPL, not a GPL-like license, the GPL itself). Be careful that you look at exactly what is covered under that GPL licensing. In order to gain access to the phone stack for the Greenphone (a must for my purposes) you have to pay them almost $5K for a commercial license. See the top line of the table on this page: http://trolltech.com/products/qtopia/greenphone/greenphonesdk - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: price politics for hardware updates post-phase-1/2
Jan wrote: Somewhere I read that FIC will likely sell the phase 2 to phase 1 owners for something like $150 (instead of $300 - yes, I know that phase 2 will cost more likely around $450 instead of $300). Hi Jan, When FIC announced the Phase 1 phones, they told us that instead of paying full-price for the phase 1 and then getting a discount on phase 2 (and having to put a system in place for tracking who gets the discounts) they simply sold the Phase 1 phones at a discount. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: 3G SIMs?
Marco Barreno wrote: I have a question about SIM cards. If I have a 3G phone with its 3G SIM, will I be able to put that SIM in the Neo? My carrier is ATT in the US. Hi Marco, There have been some problems with ATT SIMs, some working, some not. See the Wiki here: http://wiki.openmoko.org/wiki/Carriers/ATT T-Mobile seems to have a better track record so far: http://wiki.openmoko.org/wiki/Carriers/TMobile - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Can't flash smaller root-fs through dfu-util?
Dr. H. Nikolaus Schaller wrote: After unsuccessfully flashing different root-filesystems, I finally found this note: If you upload rootfs image that is smaller that previous one it won't work - you need to attach to bootloader, erase NAND and then upload your rootfs first: cu -l /dev/ttyACM0 GTA01Bv3 # nand erase rootfs This *should* help but I am trying to understand why dfu-util can't do that? And what do I do if I have no serial interface? Does this mean I can't ever again flash a (smaller) rootfs? I have no info on the first question, but about the serial interface. The commands above actually run over USB. Simply boot the Neo into uBoot (hold the Aux button while powering on) and select the option to use the console over USB (Move selection using Aux, invoke the selection by pressing power). Then plug in the USB cable and run the cu command. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Using Qemu
Jimmy McMillan wrote: Matthew. I was having the same problems for a while, but I found that after I restarted the ubuntu VM, and started the qemu string (after it was build) it worked fine for me. You make also wanna do another svn fetch and start from scratch. Another thing I've found with QEMU in general is: take your time. Click and hold it for a second or two. If you do quick clicks that you're used to doing on the desktop, it will often not register at all in the emulator. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: US: T-Mobile plans
While I've not done so in the last few months, I have done a lot of work in J2ME games. T-Mobile has a definite walled-garden mentality on some aspects of web access. For the last couple of years (unless they've changed very recently) while they have allowed browsing of most internet sites, they have not allowed JAR files to be downloaded from non-approved sites. This could be gotten around with special SIMs if you have a developer relationship with T-Mobile. There might be fewer restrictions on the Mobile Internet vs. Mobile Web. - John Nkoli wrote: The only difference between T-Mobile Web and T-Mobile Internet on the phone is that T-Mobile Internet allows VPN while T-Mobile Web doesn't. You can access any arbitrary html or wap site on your phone with both plans. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: US: T-Mobile plans
No, it was definitely the SIM. Certain handsets with certain SIMs would not download off our server (They would download the JAD, but not the JAR)--and the JAR was being blocked, it wasn't a case of it downloading and then refusing to install because of a bad certificate. Changing the SIM would allow it to proceed. Also, log into Samsung's developer boards and you will find commentary that other developers were running into the same issue. - John Eric Johnson wrote: Are you sure this wasn't a certificate issue on your jar file. I had no trouble downloading J2ME apps last year using T-Mobile US and my own web site. For some of the handsets you needed to hack the root certificate in the phone or in the Sprint case download a developer certificate to the phone. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: qemu trouble...
Giles Jones wrote: On 25 Jul 2007, at 23:42, John Seghers wrote: ifconfig usb0 inet 192.168.0.200 netmask 255.255.255.0 ssh [EMAIL PROTECTED] Interesting that the IP you use for usb0 is 192.168.0.200, then ssh into 202. I thought this was a typo then considered that it was deliberate. Heh. Yeah, I was puzzled by that when I first read the web page that describes this. Basically, the ifconfig command is specifying the IP address for the Desktop's end of the USB connection. The QEMU side of the connection seems to be hardwired to 192.168.0.202. Fortunately, the local net here at work is set up on 192.168.10.x so that I didn't have to add routes to isolate the mini-subnet formed by the USB connection. So the ssh to .202 is making a connection between .200 -- .202 - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: email vs forum
Ortwin Regel wrote: The screen size argument also doesn't work too well as the Neo has 640*480 which is plenty and an official forum would obviously make sure to fit well into that resolution. I'm sure it will fit well...but will you actually be able to read it without a magnifying glass? - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: email vs forum
Giles Jones wrote: On 25 Jul 2007, at 23:09, John Seghers wrote: I'm sure it will fit well...but will you actually be able to read it without a magnifying glass? Having owned a VGA PDA with similar screen size I can say that the resolution helps with readability. Hopefully with adjustable font sizes people can tailor the resolution to match their eyesight. Hell, you could even have an eyesight test in the phone :) The resolution does help, and it should have some truly awesome font glyphs once you specify larger fonts...but that's just the problem when trying to read a forum formatted even for a VGA desktop... To have it formatted correctly, you have to use the pixel-to-height ratio that a desktop would use, which means you need the borgstrap Ian mentioned :) If you use large enough characters to read, it won't format well. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: qemu trouble...
Did you run modprobe gadgetfs default_uid=your uid before running QEMU? I get continual kernel ring messages (dmesg, also reported in syslog) of: dummy_udc dummy_udc: dequeued req deb73c40 from ep-c, len 4096, buf Additionally, there are three lines output from QEMU's stdout/err: s3c_udc_handle_packet: EP0 overrun pcf_write: automatic Fast-charge enabled s3c_udc_handle_packet: EP0 overrun However, if I go ahead and configure the USB interface and connect via ssh, it works: ifconfig usb0 inet 192.168.0.200 netmask 255.255.255.0 ssh [EMAIL PROTECTED] - John PS: I found that the error output someone else was quoting, Warning: could not find USB gadgetfs near the beginning of QEMU's run is due to not having mounted /dev/gadget. Tim Niemeyer wrote: Sent: Wednesday, July 25, 2007 6:29 AM To: community@lists.openmoko.org Subject: Re: qemu trouble... Hello I have also some problems with qemu. I have build everything with the MokoMakefile and it works really nice! ;-) But when i want to use the gadged system to ssh into my moko, i get some trouble... I figured out that i had to recompile my default Debian Etch Kernel an did it. Now it seems to be all like in the wiki describes: http://wiki.openmoko.org/wiki/OpenMoko_under_QEMU#Setting_up_USB_connectio n Has anyone an idea for me? Is something wrong? But when i then do the usb_add gadget:1 command the qemu repeats: ## # gadget_read: event error: 4 gadget_read: event error: 4 gadget_read: event error: 4 gadget_read: event error: 4 gadget_read: event error: 4 ## # In my Syslog i can see many entrys: ## # dummy_udc dummy_udc: binding gadget driver 'gadgetfs' gadgetfs: bound to dummy_udc driver dummy_hcd dummy_hcd: port status 0x00010101 has changes dummy_hcd dummy_hcd: port status 0x00010101 has changes dummy_hcd dummy_hcd: port status 0x00100503 has changes usb 6-1: new high speed USB device using dummy_hcd and address 5 gadgetfs: connected gadgetfs: disconnected dummy_hcd dummy_hcd: port status 0x00100503 has changes dummy_udc dummy_udc: set_address = 5 gadgetfs: connected dummy_udc dummy_udc: enabled ep-a (ep3in-intr) maxpacket 16 dummy_udc dummy_udc: disabled ep-a dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 usb 6-1: string descriptor 0 read error: -32 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 dummy_udc dummy_udc: stale req = dd372840 dummy_hcd dummy_hcd: ep ep0 halted, urb e912d5c0 usb 6-1: string descriptor 0 read error: -32 usb 6-1: configuration #1 chosen from 1 choice gadgetfs: configuration #1 ## # This seems to repeat till i kill qemu and see this in my syslog: ## # BUG: warning at drivers/usb/gadget/dummy_hcd.c:49 8/dummy_free_request() [f8cf156c] dummy_free_request+0x41/0x4e [dummy _hcd] [f8cf7413] gadgetfs_unbind+0x47/0x50 [gadgetfs ] [f8cf13a6] usb_gadget_unregister_driver+0x79/0 xd2 [dummy_hcd] [f8cf721f] dev_release+0x11/0x44 [gadgetfs] [c015ae41] __fput+0x8a/0x13f [c01589aa] filp_close+0x4e/0x54 [c011ead3] put_files_struct+0x65/0xa7 [c011fa43] do_exit+0x1d1/0x71b [c0120003] sys_exit_group+0x0/0xd [c0127a6d] get_signal_to_deliver+0x395/0x3bc [c01023a6] do_notify_resume+0x71/0x5d7 [c0126fc1] group_send_sig_info+0x4e/0x56 [c0117778] default_wake_function+0x0/0xc [c0124657] do_gettimeofday+0x31/0xce [c0131ffc] sys_futex+0xdc/0xf1 [c0102d0a] work_notifysig+0x13/0x19 dummy_hcd dummy_hcd: port status 0x00010100 has c hanges dummy_hcd dummy_hcd: port status 0x00010100 has c hanges usb 6-1: USB disconnect, address 5 ## # Thanks... Tim Niemeyer ___ OpenMoko
RE: Not the free phone
Dirk Bergstrom wrote: Ian Darwin wrote: The phrase free phone already means the opposite of what we want it to mean. It's done, finished, over. Move on. Ugh, Ian's right. That phrase has been violently co-opted by the carriers. Much as I like The free(d) phone, I don't think we can use that anywhere outside the geek community. Furthermore, unless you are in a free WiFi area and using a VOIP provider, you're still paying for service. Most of service plans cost the same whether you provide your own equipment or not... therefore equating the cost of service over the lifetime of the phone to the cost of the phone is not a valid comparison. However, something like It's your phone, use it your way is likely the better avenue. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
Tim Newsom wrote As I understand it, you would not even need to build a different svg file. You could use the same one and it could automatically scale because the engine would scale it.. It should be possible (in my mind) to take a layout for 320 x 240 and draw it perfectly at 648 x 480.. Scaling up vector graphics is certainly less likely to cause problems than scaling down. However, when you start talking about QVGA or smaller, every pixel counts and hand-tuned graphics are going to give a better presentation than generated graphics. However, even staying at the same DPI... what about a landscape vs. portrait orientation? Moving from 640 wide x 480 high to 480 wide x 640 high is going to need more than scaling. You are going to want to use the display differently. So yes, a different SVG file would likely be needed. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
Luit van Drongelen wrote: (most phones and PDAs are QVGA). Actually most phones sold today are 176 x 220, whereas most PDAs are QVGA. There's still a lot of phones today that are 128 x 160 and the Sidekick III is still 240 x 160. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Openness (was RE: Concern for usability and ergonomics)
Michele Manzato wrote: Don't get me wrong, I can guess (some of) the reasons behind the plain words. But then I wonder whether there is really any transparency in the development of Neo/OpenMoko? One of the things I've seen while lurking on the list is the propensity for people to want Neo to be *exactly* what they want for their particular niche market/use. Whether or not it has a camera. Whether the accelerometers in GTA02 are accurate enough for inertial nav. Etc... When you design hardware by (large) committee, you don't get good results. Case in point is the Space Shuttle. Its design is a very non-optimal compromise between NASA's requirements for a manned medium-lift reusable shuttle and the US Department of Defense's requirements. NASA would probably have used a lifting body design had the DOD not required the ability to divert a planned Edwards landing to White Sands or one of the other secondary landing spots *after* reentry. And that's only one of the many, many compromises that made the shuttle more expensive and less capable than it could have been even with 1970's technology. Openness and transparency does not equate to everyone having a say in what the final feature set of the hardware is. It does not mean everyone on this list gets a vote. Nor does it mean that we get minutes of every meeting about new designs or even frequent status reports. What it does mean, to me, is that when they decide the feature set for the -03, -04, etc. handsets, that we know once they have crunched the features and cost and form factor to a point where they think they have something to plan for. It means this project where we have access to the entire phone stack, and are able to modify the software to tailor the phone to our niche markets. It means not having to get permission from the manufacturer to build an app for the phone (Hello Apple!). It means having a direct line of communication to the people actually building the thing for technical answers. I've been writing games on cell phones for four years. I'm now creating a lower level of software to be integrated at the OEM layer. I've seen just how hard (or impossible) it is to get this kind of support from the rest of the industry. This project is a unique collaboration between a manufacturer and open source. Let them do what they need to do to make the manufacturing decisions for their company. And thank them for the access they are giving within an industry that is extremely closed. By all means give them feedback, tell them your desires, etc. But please don't complain at them when they let you know that the GTA02 isn't the end of the line. That they're working on follow-up models. That they didn't put your must-have feature in the next rev. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Open Moko Themes
Tim Newsom wrote: This is where XAML or XUL are particularly suited. The idea is that the UI will be mostly svg commands or in some cases images.. But rendered completely by the engine. On Tue, 12 Jun 2007 4:29, Peter A Trotter wrote: UI for these different screen resolutions and potentially form factors is going to be more then a case of image resizing. It will be whole different layouts. Peter brings up a very good point. As images get smaller--because of fewer pixels available, not smaller pixels--it becomes much less reasonable to use scaled artwork. Whether that is SVG rendered into the smaller pixels or bitmaps resized, when you get down to the sizes required for today's common screen sizes, you need hand-tuned artwork. Working in the games industry since 1981, I've seen many kinds of artists. Most of today's artists do not have the skills to work at the pixel level. They may be wizards in Maya or 3DS Max, but couldn't design a 16 x 16 icon if their life depended on it--much less an animation in that many pixels. Having the combination of ability and patience to push the pixels around is a rare thing--but one absolutely necessary for a polished interface on a 1/8th VGA device. When we're dealing with a 300dpi VGA screen, the on-the-fly rendering from XML/SVG may be great. But it's not a panacea. On the other hand, I think it would be great to be able to not only skin individual apps, but be able to combine elements from multiple apps into one presentation. For example, suppose you had a CRM (customer relations) database wherein you kept notes about your clients. It would be great if the last note from that were available on the incoming call screen along with their name. But that would require a customized incoming call screen that aggregated the output of the dialer and the CRM app. At JavaOne there was a presentation on JSR 258 about a skinning architecture, but it only seemed to address appearance of elements, not layout nor the ability to combine features. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openness (was RE: Concern for usability and ergonomics)
Jonathon Suggs wrote However, suggesting that people shouldn't be expressing their interests about features no matter how niche/picky/whatever is just plain wrong. I specifically said, in my summary paragraph: By all means give them feedback, tell them your desires, etc. But please don't complain at them when they let you know that the GTA02 isn't the end of the line. That they're working on follow-up models. That they didn't put your must-have feature in the next rev. Nothing in my comments suggested that people shouldn't give them suggestions. Just don't expect them all to make it into the phone or complain when they don't. There will always be complainers, that is just life...ignore them. It is, indeed, the complainers that I was commenting on. The one that I quoted was complaining that stuff was being hidden from us because FIC is working on new specs and hasn't shared them yet. However, my frustration (if you want to call it that) is the missed delivery date. They set a concrete date, missed it, and then just told us soon. I don't think that is very professional. Missed dates are not exceptional in this industry... - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Java
As one data point, I have managed to run phoneME Feature via qvfb inside OpenMoko inside Xephyr on Ubuntu. Tying together this thread with the UI thread, phoneME is one application that would benefit greatly from having a framebuffer interface available. It is designed to render to a frame buffer. There is a QTE build, but I have not gotten that to build yet. Ian Darwin wrote: ... Or, it might be better to do our own port of phoneME to OpenMoko. I don't know which approach is better in the long run. Has anybody that has GTA01 hardware tried running this? No hardware here, nor have I tried it in arm emulation--but they do have a Linux ARM build target and if qvfb can be built for Linux ARM, it should work. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: UI ideas/questions or can we animate things as smooth as iPhone?
Daniel sent his response directly instead of to the list by accident. I confirmed that with him so I'm leaving his entire reply and adding my points at the end... -Original Message- From: Silva, Daniel [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 10:40 AM To: John Seghers Subject: Re: UI ideas/questions or can we animate things as smooth as iPhone? - Original Message - From: John Seghers [EMAIL PROTECTED] To: 'OpenMoko' community@lists.openmoko.org Sent: Thursday, June 07, 2007 5:05 PM Subject: RE: UI ideas/questions or can we animate things as smooth as iPhone? I've been lurking, but this is something that I do have a bit of experience with--and definitely some opinions. Michael 'Mickey' Lauer wrote Tomasz Zielinski wrote: framework, designed for mobile devices and running quick framebuffer operations? GameBoy provided nice full-screen animations in 1989, eighteen years ago. I feel your pain. Trust me, it hurts me as well... The GameBoy Advance is an ARM7TDMI running at 32MHz. However, its screen size was only 240 x 160 (1/8 VGA) and it had a hardware-based sprite system as well as both bitmapped and character mapped graphics capabilities with hardware fine scrolling and multiple planes. IIRC, the GTA01 has a 266MHz processor--only a little more than 8x the GBA--and fully 8x the screen area with 16x the memory required for a bitmap. I'm 100% sure nobody will cry after pure-X11 applications we loose this way. Almost every GTK application would require rewriting/porting to fit OpenMoko capabilities, so it's not great loss too. Not to mention font and other DPI-aware issues. Interesting. Can I hear more supportive or counter arguments? What do the others think? I've been writing games since 1981, on Atari 5200, 8-bit NES, SFX, Genesis, Windows, and too many cell phones to keep track of. Please, please, please give us direct access to the frame buffer and a low level API to the Blitter in the GTA02. I don't know if you have to throw away X11 support to do so, but I do agree that you won't lose much if you do so. No you don't have to sack X11 to have access to the underlying hardware, you can interface with it through DRI ( Direct Rendering Infrastructure ), but that would kill the point of having X11, why having X11 if you access the hardware directly? And besides you would have to write a DRI driver to interface with OpenMoko hardware, since there's only a handfull of drivers available. I agree that loosing X11 per se wouldn't do much harm, but going the vanilla framebuffer way we would be loosing a lot. It would require ALOT of work to rebuild what has been done until now ( if they're really using X11+GTK ) just to go in that direction, when i believe the problem is not there. I believe people are missing few things, although i really didn't checked the code yet, i bet the code is still very umpolished and could and will be optimized. From what i've seen in the wiki, OpenMoko is still using KDrive ( trimmed down XServe implementation ) and a full glibc. Change that for something like DirectFB and uClib ( or diet libc ) and you already would start to see things shape up. Then there's loading times, for a solution like OpenMoko i wouldn't rely on dynamic linking and would go for static linking, remeber this is not a desktop system. http://www.directfb.org/docs/GTK_Embedded/summary.html If you/they must use dynamic linking i would recomment using something along the lines of prelink. A lot of statements have been made here about people flocking to the Neo *because* they can modify it. But remember that the geeks who will buy it because they can run their favorite X application, or bring up a Linux shell are the vast minority if you're looking at hundreds of thousands or millions of devices being sold. The vast majority of the purchasers are going to be people who buy it because it functions smoothly, makes great calls, and has lots of nifty eye candy. And, oh by the way, the can customize it to their heart's desire. But those customizations aren't going to be done at the Linux developer level. Those are going to be seamless plug-ins or self-installing apps that give them something they want on the phone. This also points to the need for a slick graphical app catalog/installer. Synaptic, apt-get, rpm...not going to cut it for the normal end user. There are loads and loads of cheap and really great functioning cell phones, OpenMoko/neo1973 could be the greatest phone in the world and still noe even make a small dent on the market. Sure there are people who will look for the best bang for the buck, but mus of them will just buy what's more trendy and/or has the most 'cool' factor. Just look the iPod and the more recent iPhone fenomena, neither one are the best on the class, but they have
Status of phoneME?
I'm embarking on a project where I need to work at the c/c++ level under J2ME and tie into the native phone stack as well. I'm trying to determine whether I should initially target OpenMoko or Qtopia's Greenphone initially. One of the decision points in this for me is the question of whether phoneME Feature has been ported to the platform. I was pointed here by information I got at the JavaOne conference and I've seen hints that such a port is in progress for OpenMoko and/or Greenphone, but it has been very hard to determine if such beasts actually exist. Can someone fill me in on the status of phoneME on either of these devices? - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
