Wiimote, I2C Neo
From: http://www.windmeadow.com/node/42 Data can be read from a wii nunchuck directly into an Arduino, using TWI (aka I2C). In other terms: we could potentially use any Wiimote accessory on a Neo... A nunchunk has a 3 axis accelerometer, joystick and buttons, for instance (for a mere 20$). What are the upcoming wii accessories? :) On another subject, any updates about neo's I2C/expansion pack wish ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: cellphone-sized X86 PC motherboard potential OpenMoko platform?
On Sunday 10 June 2007 22:50, Dr. H. Nikolaus Schaller wrote: And IMHO there is only a very weak relation between a processor's instruction set and its power consumption. Not direct, but several strong points can arise from using a specific instruction set (presuming compatibility is one of the reasons you are making such a choice). The obvious are Thumb(2), the less obvious are the FPU/SSE/etc stuff. Much of the x86 code that the to-be developer wishes to be compatible with has been written with the preconception of a fairly powerful FPU (skype, voice processing, multimedia). Now, you could emulate these (as do many of the existing low-power x86 solutions, this is not exactly new, there are older generation x86 chips that need very little power), but it would be crippling performance. In the end, if you want to keep a comparable x86 performance without going to a several GHz clock, you would pretty much end up with a regular x86 processor optimized for consumption, which is what much of the VIA C series are. They try to be x86 consuming less power, and not being an ARM competitor which speaks x86, which many expect here. ___ 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?
Following the there's much more than GFX effects in a usable UI, here's an interesting blog post: http://www.codinghorror.com/blog/archives/000883.html It's not about embedded devices GUI, rather about desktop apps vs. web apps. However, mutatis mutandis, it drives another nail in the same coffin: application UIs thought in terms of classic desktop widgets lag way behind in terms of usability. Moreover, I believe there are ways to leverage the search-based API which makes google apps so ergonomic into embedded devices, provided that we can find a proper input method. Of course this input method wouldn't be Win32/OSX/GTK/KDE-like widgets, nor some clunky keyboard replacement. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiimote, I2C Neo
The Wii remotes use standard bluetooth. See http://www.wiili.org/index.php/Wiimote_driver for some info on connecting to a Linux box. If you a have better source, please share. So, if you're just looking for the accelerometer, there's no need to splice wires. Plus, the GTA02 will have two 3D accelerometers according to the latest presentations by FIC. I guess if what you really want is the joystick, you'd want the nunchuck part. But obviously that data is sent via bluetooth as well. Of course, the remote costs $40 instead of just $20 for the nunchuck. What applications are you thinking about for this? -Steven On 6/11/07, Florent THIERY [EMAIL PROTECTED] wrote: From: http://www.windmeadow.com/node/42 Data can be read from a wii nunchuck directly into an Arduino, using TWI (aka I2C). In other terms: we could potentially use any Wiimote accessory on a Neo... A nunchunk has a 3 axis accelerometer, joystick and buttons, for instance (for a mere 20$). What are the upcoming wii accessories? :) On another subject, any updates about neo's I2C/expansion pack wish ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiimote, I2C Neo
I guess if what you really want is the joystick ... Or any upcoming Wii accessories (who knows what will come from these prolific brains ^^ ?); i guess a text input accessory will have to come sooner or later. Yet, as you pointed out, here i'm interested by the joystick + buttons you'd want the nunchuck part. But obviously that data is sent via bluetooth as well. Of course, the remote costs $40 instead of just $20 for the nunchuck. Exactly; but using the wiimote as gateway for it's accessories will: * suck battery (wiimote neo) -- bluetooth's fault * require more pockets :p What applications are you thinking about for this? I have no cparticular application in mind (apart the added input methods -- 3D GPS navigation and games comes to mind ) ; in fact, what i think is really great is that Nintendo uses I2C for accessories. Which means, no need for OpenMoko to spread lots of accessories: just go to your videogames retailer (huge existing distribution network), pick up your favourite Nintendo accessory, and plug it in your I2C expansion pack (adapter required). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiimote, I2C Neo
Florent THIERY wrote: In other terms: we could potentially use any Wiimote accessory on a Neo... A nunchunk has a 3 axis accelerometer, joystick and buttons, for instance (for a mere 20$). What are the upcoming wii accessories? :) or how about going the other way, using the upcoming neo variant as a wiimote replacement? ;) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Web-based GUI technology for OpenMoko
Here's a little look-and-feel example that could be done with an opensource AJAX framework [javascript required]: http://demo.qooxdoo.org/current/showcase This may allow easier separation between apps and GUIs. Of course, as usual we have no idea how well such an app would perform (little gratuitous prediction: very bad), benchmarking is needed but ... who knows ? This is going along with the ongoings gdk webkit port and gsmd XmlHttpRequest interface (was topic: embedded webserver). What do you think ? Is it REALLY unrealistic ? Could anybody try the url on it's Nokia N770 (lots of happy owners here, right?) and rough feedback the responsiveness ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web-based GUI technology for OpenMoko
Yeah... we're thinking that we were going to totally separate the model and domain processing from the view/controller part of the application. That way we could have a couple different HTML interfaces as well as a SVG/ECMAScript interface. I'm not terribly familiar with XAML or XUL, but I understand that most (if not all) of the Firefox / Mozilla / Navigator interface was written in XUL. This is one of the benefits to this approach, IMHO. Separating the interface allows us to experiment with a number of different interface technologies. And the only thing the experimenters need to know is the semantics and syntax of the XML interface. -Cheers! -Matt H. On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote: If we are heading in the direction of web interfaces, I think we should look at XAML or XUL or something similar. From what I can tell, they will be adding silverlight support to mono, so using XAML will be possible. This also separates the code for functionality from the interface and can allow skinning of the entire application interface set. This will abstract you from every widget set. Each action could be exported and called from the UI without needing to worry about all that. At least, that's my take on it currently. --Tim On Mon, 11 Jun 2007 8:44, Florent THIERY wrote: Here's a little look-and-feel example that could be done with an opensource AJAX framework [javascript required]: http://demo.qooxdoo.org/current/showcase This may allow easier separation between apps and GUIs. Of course, as usual we have no idea how well such an app would perform (little gratuitous prediction: very bad), benchmarking is needed but ... who knows ? This is going along with the ongoings gdk webkit port and gsmd XmlHttpRequest interface (was topic: embedded webserver). What do you think ? Is it REALLY unrealistic ? Could anybody try the url on it's Nokia N770 (lots of happy owners here, right?) and rough feedback the responsiveness ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concern for usability and ergonomics
[I'm CC'ing the community list because there's lots of points here that go well beyond hardware.] On Jun 11, 2007, at 6:36 AM, Miguel A. Torres wrote: Hi, Like many of you, I'm following the project with great enthusiasm. This will surely demonstrate companies in the sector that open source is not only a possibility, but probably the only real path to follow in the long term. While the philosophy of the project is wonderful, the actual product that will reach customers - the neo1973 - is less than impressive. Not because of hardware specs, GTA-02 seems impressive already by packing almost everything except for a camera (which I personally believe should be included). My concern goes for the most basic aspect of any consumer product: usability and ergonomics. I'm absolutely astonished on how this fundamental aspect has been largely overlooked by everyone. For example, the phone main interface is a touchscreen, yet the case of the phone wasn't designed to hold a stylus. While I'm aware that at this stage the phone is largely intended for development only, I think it is time to re-consider this important aspect of the project. I can assure you two things. 1) We cannot change this now with GTA02. 2) We have more hardware in the works that will definitely address these concerns. We all share them. More concisely: * Integrated keyboard and directional pads are not mere luxuries, but necessities. They allow for safe one hand operation while reducing touchscreen stress. Touchscreens are fragile (get scratched easily, develop calibration issues over time, etc) and direct finger use requires constant cleaning. * To think globally. Asian languages use ideograms so it's reasonable that asian users find limited use for an integrated keyboard, but western users are the opposite. All administrative and technical commands (say, C++ code, Internet URLs, etc.) are written in latin characters and benefit greatly from easy typing. * It is possible to include all in the same package. Palm's Treo line has been including full keyboard, directional pad and touchscreen in a very compact package for years. * Over all, the philosophy should be to give the user options, allowing freedom to choice. Treo is an excellent design in terms of usability. It's been designed with real people in mind. For example, it provides hardware volume buttons and a switch to turn the phone mute. I totally agree with your points. Please keep in mind that this was our first design. And that we are using an ID design that simply wasn't made for what this project has become. It was originally designed for a completely different usage scenario. Believe me when I say that we are working on new stuff that will address these issues. I have been quiet for the past few months because of some major internal re-allocations and new events. Within about a month we should be more or less finished and emerge with far more focus and resources. Until then, please accept my sincere apology for not being able to keep up with all your comments and questions. Internally all my time and energy is being used now. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiimote, I2C Neo
Not unless the Neo has a camera. Don't forget that the Wii remote has one. -Steven On 6/11/07, kenneth marken [EMAIL PROTECTED] wrote: Florent THIERY wrote: In other terms: we could potentially use any Wiimote accessory on a Neo... A nunchunk has a 3 axis accelerometer, joystick and buttons, for instance (for a mere 20$). What are the upcoming wii accessories? :) or how about going the other way, using the upcoming neo variant as a wiimote replacement? ;) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concern for usability and ergonomics
Krzysztof Kajkowski schrieb: 2007/6/11, Sean Moss-Pultz [EMAIL PROTECTED]: Believe me when I say that we are working on new stuff that will address these issues. I have been quiet for the past few months because of some major internal re-allocations and new events. Within about a month we should be more or less finished and emerge with far more focus and resources. Until then, please accept my sincere apology for not being able to keep up with all your comments and questions. Internally all my time and energy is being used now. So, I guess this means there will be no release of GTA-01 (at least in one month) or the amount of devices will be reduced... Is it correct? cayco ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community That is something I would like to know as well. The statement ist not really clear and seems to be very misterious. I don't know. Regards, Denis ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
standard API for linux phones?
the register has a piece about a draft of a standard API for linux phones, concerning basics such as interaction with the address book, texting, ui and voice-calling. future revisons to increase the coverage http://www.theregister.co.uk/2007/06/11/lips_mobile_linux/ and from TFA http://www.lipsforum.org/ does anyone here have any further knowledge about this, beyond the blurb on the site? is it worth adhering to, or a thinly-veiled atttempt for one company (it's backed by orange) to foist propietary/their own standards on everyone else? does it compare at all to what the linux mobile group (backed by samsung, motorola and others) are trying to achieve? and of course, has it been considered for openmoko/the neo? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: standard API for linux phones?
Long overdue and if it is a standard then lets all jump onboard and work with it from inside rather than throwing rocks from the outside. Cheers, Dean -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Robin Paulson Sent: Monday, 11 June 2007 7:16 PM To: community Subject: standard API for linux phones? the register has a piece about a draft of a standard API for linux phones, concerning basics such as interaction with the address book, texting, ui and voice-calling. future revisons to increase the coverage http://www.theregister.co.uk/2007/06/11/lips_mobile_linux/ and from TFA http://www.lipsforum.org/ does anyone here have any further knowledge about this, beyond the blurb on the site? is it worth adhering to, or a thinly-veiled atttempt for one company (it's backed by orange) to foist propietary/their own standards on everyone else? does it compare at all to what the linux mobile group (backed by samsung, motorola and others) are trying to achieve? and of course, has it been considered for openmoko/the neo? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: standard API for linux phones?
From what I read, the LIPS group is creating an 'open' standard. The impression I got from that was the other phone standards group was 'closed' whatever that means. If we are going to back a group, maybe FIC should join it and help in the development process of the standard. None of the members are small (as far as I can tell), and it does at least have the backing of some operators.. Either way, we will need to either submit a standard at some point or follow one so that others can interop with us.. Right? --Tim On Mon, 11 Jun 2007 16:55, Dean Collins wrote: Long overdue and if it is a standard then lets all jump onboard and work with it from inside rather than throwing rocks from the outside. Cheers, Dean -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Robin Paulson Sent: Monday, 11 June 2007 7:16 PM To: community Subject: standard API for linux phones? the register has a piece about a draft of a standard API for linux phones, concerning basics such as interaction with the address book, texting, ui and voice-calling. future revisons to increase the coverage http://www.theregister.co.uk/2007/06/11/lips_mobile_linux/ and from TFA http://www.lipsforum.org/ does anyone here have any further knowledge about this, beyond the blurb on the site? is it worth adhering to, or a thinly-veiled atttempt for one company (it's backed by orange) to foist propietary/their own standards on everyone else? does it compare at all to what the linux mobile group (backed by samsung, motorola and others) are trying to achieve? and of course, has it been considered for openmoko/the neo? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Open Moko Themes
I know that there are going to be themes for the OpenMoko interface, but I'm just wondering if there is anyone who has started working on alternate themes? I think I'd like to take a crack at it, and I was curious if anyone has had any start yet. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web-based GUI technology for OpenMoko
Also, Apple's announcement today about iPhone development using AJAX and exposing internal phone functions as web services to the iPhone's safari browser is tipping everything in the same direction. Cheers Adrian On 6/11/07, Matthew S. Hamrick [EMAIL PROTECTED] wrote: Yeah... we're thinking that we were going to totally separate the model and domain processing from the view/controller part of the application. That way we could have a couple different HTML interfaces as well as a SVG/ECMAScript interface. I'm not terribly familiar with XAML or XUL, but I understand that most (if not all) of the Firefox / Mozilla / Navigator interface was written in XUL. This is one of the benefits to this approach, IMHO. Separating the interface allows us to experiment with a number of different interface technologies. And the only thing the experimenters need to know is the semantics and syntax of the XML interface. -Cheers! -Matt H. On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote: If we are heading in the direction of web interfaces, I think we should look at XAML or XUL or something similar. From what I can tell, they will be adding silverlight support to mono, so using XAML will be possible. This also separates the code for functionality from the interface and can allow skinning of the entire application interface set. This will abstract you from every widget set. Each action could be exported and called from the UI without needing to worry about all that. At least, that's my take on it currently. --Tim On Mon, 11 Jun 2007 8:44, Florent THIERY wrote: Here's a little look-and-feel example that could be done with an opensource AJAX framework [javascript required]: http://demo.qooxdoo.org/current/showcase This may allow easier separation between apps and GUIs. Of course, as usual we have no idea how well such an app would perform (little gratuitous prediction: very bad), benchmarking is needed but ... who knows ? This is going along with the ongoings gdk webkit port and gsmd XmlHttpRequest interface (was topic: embedded webserver). What do you think ? Is it REALLY unrealistic ? Could anybody try the url on it's Nokia N770 (lots of happy owners here, right?) and rough feedback the responsiveness ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: standard API for linux phones?
Tim Newsom [EMAIL PROTECTED] writes: From what I read, the LIPS group is creating an 'open' standard. The impression I got from that was the other phone standards group was closed' whatever that means. It just struck me that the phone book contact info is pretty close to what one wants for a GPS waypoint (Name: Bob's Deli Phone: xxx-xxx- Address: 1 Main Street, Anytown, USA 6 Lat: 37.0 Lon: -121.0 Comment: Great Bagels and Lox). It would be really good if API was flexible to server for both of the Neo/Openmoko needs. -wolfgang -- Wolfgang S. Rupprechthttp://www.wsrcc.com/wolfgang/ IPv6 on Fedora 7 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web-based GUI technology for OpenMoko
Wow. once again Apple justifies our lead. On Jun 11, 2007, at 5:54 PM, adrian cockcroft wrote: Also, Apple's announcement today about iPhone development using AJAX and exposing internal phone functions as web services to the iPhone's safari browser is tipping everything in the same direction. Cheers Adrian On 6/11/07, Matthew S. Hamrick [EMAIL PROTECTED] wrote: Yeah... we're thinking that we were going to totally separate the model and domain processing from the view/controller part of the application. That way we could have a couple different HTML interfaces as well as a SVG/ECMAScript interface. I'm not terribly familiar with XAML or XUL, but I understand that most (if not all) of the Firefox / Mozilla / Navigator interface was written in XUL. This is one of the benefits to this approach, IMHO. Separating the interface allows us to experiment with a number of different interface technologies. And the only thing the experimenters need to know is the semantics and syntax of the XML interface. -Cheers! -Matt H. On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote: If we are heading in the direction of web interfaces, I think we should look at XAML or XUL or something similar. From what I can tell, they will be adding silverlight support to mono, so using XAML will be possible. This also separates the code for functionality from the interface and can allow skinning of the entire application interface set. This will abstract you from every widget set. Each action could be exported and called from the UI without needing to worry about all that. At least, that's my take on it currently. --Tim On Mon, 11 Jun 2007 8:44, Florent THIERY wrote: Here's a little look-and-feel example that could be done with an opensource AJAX framework [javascript required]: http://demo.qooxdoo.org/current/showcase This may allow easier separation between apps and GUIs. Of course, as usual we have no idea how well such an app would perform (little gratuitous prediction: very bad), benchmarking is needed but ... who knows ? This is going along with the ongoings gdk webkit port and gsmd XmlHttpRequest interface (was topic: embedded webserver). What do you think ? Is it REALLY unrealistic ? Could anybody try the url on it's Nokia N770 (lots of happy owners here, right?) and rough feedback the responsiveness ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web-based GUI technology for OpenMoko
Interesting... Web services... I wonder if that makes it possible to export the web service off the phone To a program running somewhere else... Or if its limited to some local channel. And, anyway.. That only means you would have to wrap it in another, fully exportable, web service for such integration. --Tim On Mon, 11 Jun 2007 20:51, Matthew S. Hamrick wrote: Wow. once again Apple justifies our lead. On Jun 11, 2007, at 5:54 PM, adrian cockcroft wrote: Also, Apple's announcement today about iPhone development using AJAX and exposing internal phone functions as web services to the iPhone's safari browser is tipping everything in the same direction. Cheers Adrian On 6/11/07, Matthew S. Hamrick [EMAIL PROTECTED] wrote: Yeah... we're thinking that we were going to totally separate the model and domain processing from the view/controller part of the application. That way we could have a couple different HTML interfaces as well as a SVG/ECMAScript interface. I'm not terribly familiar with XAML or XUL, but I understand that most (if not all) of the Firefox / Mozilla / Navigator interface was written in XUL. This is one of the benefits to this approach, IMHO. Separating the interface allows us to experiment with a number of different interface technologies. And the only thing the experimenters need to know is the semantics and syntax of the XML interface. -Cheers! -Matt H. On Jun 11, 2007, at 9:18 AM, Tim Newsom wrote: If we are heading in the direction of web interfaces, I think we should look at XAML or XUL or something similar. From what I can tell, they will be adding silverlight support to mono, so using XAML will be possible. This also separates the code for functionality from the interface and can allow skinning of the entire application interface set. This will abstract you from every widget set. Each action could be exported and called from the UI without needing to worry about all that. At least, that's my take on it currently. --Tim On Mon, 11 Jun 2007 8:44, Florent THIERY wrote: Here's a little look-and-feel example that could be done with an opensource AJAX framework [javascript required]: http://demo.qooxdoo.org/current/showcase This may allow easier separation between apps and GUIs. Of course, as usual we have no idea how well such an app would perform (little gratuitous prediction: very bad), benchmarking is needed but ... who knows ? This is going along with the ongoings gdk webkit port and gsmd XmlHttpRequest interface (was topic: embedded webserver). What do you think ? Is it REALLY unrealistic ? Could anybody try the url on it's Nokia N770 (lots of happy owners here, right?) and rough feedback the responsiveness ? Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: standard API for linux phones?
I'm not sure if this is useful. It sounds a bit more like a marketing group. You have to pay a fee to join. On Mon, 11 Jun 2007, Dean Collins wrote: Long overdue and if it is a standard then lets all jump onboard and work with it from inside rather than throwing rocks from the outside. Cheers, Dean -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Robin Paulson Sent: Monday, 11 June 2007 7:16 PM To: community Subject: standard API for linux phones? the register has a piece about a draft of a standard API for linux phones, concerning basics such as interaction with the address book, texting, ui and voice-calling. future revisons to increase the coverage http://www.theregister.co.uk/2007/06/11/lips_mobile_linux/ and from TFA http://www.lipsforum.org/ does anyone here have any further knowledge about this, beyond the blurb on the site? is it worth adhering to, or a thinly-veiled atttempt for one company (it's backed by orange) to foist propietary/their own standards on everyone else? does it compare at all to what the linux mobile group (backed by samsung, motorola and others) are trying to achieve? and of course, has it been considered for openmoko/the neo? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concern for usability and ergonomics
On Monday 11 June 2007 19:00:42 Sean Moss-Pultz wrote: I totally agree with your points. Please keep in mind that this was our first design. And that we are using an ID design that simply wasn't made for what this project has become. It was originally designed for a completely different usage scenario. Will you be able to give basic information (like form factor) on those new devices at the time GTA-01 will ship? That would certainly be hopeful for many of us... pgpdDPGPuP0r4.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
