Re: how to enable usb host mode?
On ti, 2008-02-05 at 16:01 +, JW wrote: if you are talking about GTA01 then there is no host mode (I believe). Bzzt, there is, though it is unpowered (and therefore nonstandard as-is), requiring power to be fed from the side via eg. a three-pronged cable (or the device not to care about seeing power on the bus, which might be rare). -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gizmo for Skype-like functionality in Neo?
On ke, 2008-01-30 at 18:00 +0100, Michael Schmidt wrote: the serverless instant messenger http://retroshare.sf.net (Qt gui) will have soon as well VOIP and VIDEO Chat, and this is quite good for openmoko, as this is an encrypted one, so you are safe, that no third party is hearing your Voips. Seems like it does its own thing, which is bad for interop. I would suggest to people implementing a softphone for OpenMoko to use standard SIP, applying preferrably the GNU ccRTP library for voice streams. This implements the quite nice ZRTP protocol designed by Zimmerman of PGP fame. (I haven't noticed other free implementations of ZRTP; if such are however available, this killer advantage to ccRTP may of course diminish.) Relevantly, there may be a lot of potential synergy with the GNU Telephony Open Embedded subproject: In GNU Telephony Open Embedded, one goal is to provide softphone clients, such as linphone, sflphoned, and twinkle, modified specifically for GPE and OPIE (Free Qtopia). - http://www.gnutelephony.org/index.php/GNU_Telephony_Open_Embedded I'm sure many relevant people know all this already, but thought I'd toss it out again. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: noise while making a phone call: hardware or software?
On pe, 2008-01-04 at 12:50 +1000, Lorn Potter wrote: There _is_ a problem with the level of some of the mixer elements in the default gsmhandset.state, though, which seems to cause echo type of thing. Yeaah, anyone have a better state where the echo, spesifically to the remote end, would be at least reduced if not eliminated? I get a lot of comment on the strong echo from people I talk to, and am scared of the mixer. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FM radio reception on neo/openmoko and some other questions
On pe, 2007-11-09 at 16:35 +0530, rakshat hooja wrote: 1) Are there any working hacks for getting FM radio reception on the neo 1973? Even the $35 (total for the unlocked phone that will work with any network) Nokia phones have FM reception in india. This is a must have option for the Neo to sell in India. A weird market, India, then. And no, the Neo doesn't/won't have an FM receiver, as simple as that. (If you mean hacks as hardware, of course you can get something done but hard to make it clean, and hardware hacks don't really add to mainstream marketability.) 2) Will the GTA02 phone have the speaker phone option or is getting call sound on the speakers something that can be done by editing config files in openmoko? You can certainly stick the sound anywhere, but you'd need to do echo cancellation or some kind of push-to-talk. Possible, still. I don't really know how well the mic would pick up speech from a bit further away. Something to try out. If it doesn't, maybe for some needs it could be sufficient to use the headset mic and phone speaker, though a bit weird. 3) Is it theoretically possible to print by directly connecting the printer to the phone if the printer drivers are avaliable (at least text files) Yes, especially with the GTA02 (which can provide 100 mA USB power). The GTA01 is likely to require a power injector in between, so that the printer will realize it has something hooked into it. Also other USB 1.1 gadgets (that will settle for 100 mA or preferrably have internal power so the Neo's battery isn't drained) should work, if there are just Linux drivers for them (present on the system, of course, with supporting software). You should be able to offload a digital camera onto the Neo and/or through it to the net, for instance. 4) If someone writes a faxing application for openmoko should it not be possible to use the phone as a mobile fax sending and recieving unit? I'd be surprised if it wasn't, though I'm not 100% positive - faxing is of no interest to me personally so I've not verified it. Somebody chime in? -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gphone and 850, perspectives
On to, 2007-11-08 at 06:29 -0500, [EMAIL PROTECTED] wrote: In this case it is a very valid issue and definitely not a complaint or a whine. It can become one quickly if everyone keeps mulling it over without adding anything new. It basically tanks one of the largest consumer bases and it tanks my project in my company until I find something else. Sad about your project. Hope they can make that speculated 850/1800/1900 triband version a reality quick, but you can't of course assume that. Will GPS work without trouble, is it in any way affected by the bandwidth issue. 1) It's not a bandwidth issue. It's a frequency band issue. 2) GPS is not affected in any way. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gphone and 850, perspectives
On ke, 2007-11-07 at 10:31 -0500, [EMAIL PROTECTED] wrote: Sorry, I cannot get the original reference to why this is an issue for North American users. NA uses the unusual 850 MHz and 1900 MHz bands for GSM. The Neo, at least as it will be first available, will not support 850 MHz (but will 1900 MHz). This means that it can work in NA, _but_ will get worse coverage than GSM phones capable of also 850 MHz operation. According to my second-hand understanding of the situation, of the major US GSM providers, T-Mobile has more 1900 MHz coverage than ATT/Cingular, and that major cities may have decent amounts of it as opposed to rural areas. It's vague, but HTH. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM/GPRS at same time? (was: Re: does dialer supports multiple calls at a time??)
On ti, 2007-09-18 at 04:55 -0400, Steve wrote: I have a GPRS question, the wiki says (on the iphone comparison page) that it is class 12/cs4. That describes speed and number of channels. There's a third classification, A-C, which indicates whether it is capable of utilizing both voice/SMS and GPRS at the same time. Is the hardware capable of doing both at once? It's B, can't do both simultaneously. If it can't do both at once, does that mean that incoming voice calls will busy out? No, Class B devices do still get the signaling and can suspend the GPRS connection for the duration of the voice call. Since it was on the iphone page, does anyone know if the iphone can do both voice and data at the same time? Dunno, likely not. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPU driver/doc development
On ma, 2007-09-10 at 12:08 +0100, Jim McDonald wrote: Not wishing to be contrary for its own sake, but my answer to your (supposedly rhetorical) question would be 'the docs'. If we had a complete manual then that would be enough for other people to write the driver, whereas if we have a driver and no docs then it's going to be next to impossible for the community to add features or fix bugs in said driver and we're stuck with whatever functionality your incredibly small team finds time to implement. You're not being very realistic here. Complete manual would presumably take a lot of time in itself (what with the incredibly small team and all), all the while us having no drivers. Publishing the GTA-02 without much in the way of GPU drivers at all would then delay development of applications that take advantage of said GPU. If they can hack even rudimentary drivers for the GTA-02 release, on the other hand (something only they can do before that anyway), application development can then proceed smoothly from the get-go. 'course, there is a cutoff point where devoting more effort to documentation makes sense, and I am glad it is in the pipeline for the reasons you mention. That point is probably somewhere around where a basic GPU driver is working, and it's time to add more advanced features and tune performance. The definition of basic here is, of course, loose. I'd pencil it somewhere around where rotation, video acceleration and perchance some basic 3d rendering is going on, but I don't mean that to be a solid definition, rather leaving that up to the people who do the work. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Tor and China
On ma, 2007-09-10 at 13:42 +0200, Richard Bennett wrote: On Mon, 10 Sep 2007 13:06:02 +0200, Sander van Grieken [EMAIL PROTECTED] wrote: wifi+in china - use Tor Maybe better just not use email at all in that case: http://www.theregister.co.uk/2007/09/10/misuse_of_tor_led_to_embassy_password_breach/ ...or maybe, just maybe, better not to _misuse_ Tor and keep the connection encrypted (which is the sane thing to do anyway). Though quite aside from the article, it might be best to avoid using Tor or encryption in China, so non-use has its points, just not for your stated reason. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: gpsd and AGPS
On ti, 2007-09-04 at 09:01 +, Giles Jones wrote: Alexey Feldgendler [EMAIL PROTECTED] wrote : Am I getting it right that while GTA01 used to contain a GPS receiver, GTA02 doesn't have one? I think he was referring to the fact that he works for broadcom and it would be easier for him to advice if it did. GTA01 and GTA02 have a Global locate chipset. Sigh. Broadcom acquired Global Locate. However, for whichever reasons, GTA02 will have a different GPS chip. On the IRC channel, I heard that the new chip/vendor is more co-operative with free software, at least. Have I missed something by the way and has gllin for GTA01, OpenMoko 2007.2 been released yet? Since we have a Broadcom guy here, Ken, you know what the deal is with that? -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buying Openmoko GTA02 from Europe
On to, 2007-08-23 at 15:15 +0300, Ilja O. wrote: 2007/8/22, Jean-Eric Cuendet (ML) [EMAIL PROTECTED]: I've opened a website that will sell GTA02 devices when they are available, to other Europe countries. I'll buy quantities of devices from FIC and resell them from here, in Switzerland, middle of Europe. Hi. I'm really interested in obtaining (at least) one GTA02 device. But I live in Latvia. Are there any hopes that you'll ship here too? At least we all are in same Union. :-) Actually, Switzerland isn't in the EU. Which results in people still needing to bother with customs and stuff. (Should be better postagewise and stuff, of course.) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What's the real scope of hardware openness?
On ti, 2007-08-07 at 12:14 +0200, Luca Dionisi wrote: If I understand correctly, the real big problem, as for legal issues and technical issues, is the GSM protocol. Using WiFi for a similar goal should be fine, though. The problem is that you can reach much shorter distances without the help of someone else's spot. [...] Do I mistake again? Not really, though I think I should again remind you that the _reason_ you get good range for your power with GSM is _because_ the towers centrally controls the frequencies and timeslots that the handsets use for transmissions, and everybody plays by those rules. And also, wrt. mesh networking, you still don't really want to allow your phone, while it's mobile, to work as a bridge in the mesh; otherwise the battery would be dead in no time. But sure, advocate lots of open access points and perhaps putting the phone in mesh mode if it's hooked up to external power. And still there will be severe scalability issues, but what the hey, it's possible for _some_ N, right? :] -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA01 first impressions
I just got my Neo (yay)! First impressions: Flashing is frustratingly slow when you want to get tinkering ;) But really, the phone itself is a lot faster than I expected what with all the complaints; granted, optimizations may have crept in since then, but anyway I didn't feel it especially painful to use. Now, I'm used to the s60 N-gage, which may blind me to the lack of instant snappiness which _was_ present. ;] So it's not like it couldn't use improvement, just that it's not _that_ bad, IMAO. Of course, I haven't used it much yet, so my mileage may vary. I managed to even make a call. Well, three, but the first were quite silent. I loaded up the ALSA mobile phone profile settings and called again, this time from the libgsm-cli (though apparently the calls from GUI did also go through, just with the silence). This resulted in massive feedback, but some words were able to be transmitted. On IRC a developer who shall remain anonymous mentioned that oh yeah, he'd had a phone with the earpiece shot, so he put the audio out of the stereo speakers (_right_ next to the mic) instead, and that seems to have ended up in a root image... At least there should be easy to fix then ;) For now, got a prepaid SIM for my Neo playing, not replacing my usual phone _just_ yet. USB networking works out of the box (well, after flashing), which is nice. Oh, and the Freedom Mini Bluetooth keyboard did snap, with its spring-hinge, the Neo solidly enough. Neo's bluetooth seemed disabled when I tried to run hidd, and I left it at that for now (BT was recognized during bootup, though, so I don't think it's faulty, probably just needs enabling). Further tinkering will have to wait until tonight. Thanks to the team; it's been a rocky road (I'm sure I don't even know how rocky exactly), and longer than expected, but a significant milestone has been reached. And it don't seem half bad. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minor correction
On to, 2007-06-28 at 21:27 +0800, Sean Moss-Pultz wrote: Copy and paste was working too well last night. The Neo Base kit has one (1) MicroSD card. Only the Neo Advanced kit has two. I also suspect that you have another slight typo in the Base kit description (not in the Advanced). It boasts a Micro-USB cable, when I'd think it would be Mini (as it is in the Advanced). -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Yes, there's GPS (Re: What, no GPS?)
On to, 2007-06-28 at 01:29 -0500, BJ Quinn wrote: I can't help but notice that GPS is not on the list of scheduled upgrades in the recent announcement. Is that a confirmed no for GPS, or had it already been confirmed yes and I missed something or am I off altogether? It's not on the confirmed upgrades because GPS is already a part of the GTA01, and already in (the lucky few) peoples' hands. Anyway, thanks to Sean for the great news about FIC's level of commitment in this project. And of course the shipping date. I did hope earlier that the May 10th run would yield me a birthday toy, but I suppose a bit late wedding present will do nicely as well (getting married on a=rwx :). I'll surely get me one of these, and of 02 as well. Then my fiancée (well, wife) will have the 01, and we'll get to use all that excellent collaboration software that will magically appear during that time; maybe even some from us, one hopes. A scheduled EDGE upgrade would've made it just about perfect, but I shan't complain, there's lots here to work with already. Looking forward to a later 3g version though ;) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ 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?
On to, 2007-06-07 at 01:23 +0200, Michael 'Mickey' Lauer wrote: Tomasz Zielinski wrote: 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 would be a bit disappointed of the loss of flexibility and ease of portability, what with the reuse of desktop technologies and all. My concern would be alleviated by the fact that in the end one could run core apps and Mokoized apps directly on the frame buffer and still have an X server available for stuff that is not-so-thoroughly Mokoized (would have to have some extra integration wrt. window management...) All and all, I'd not be overly distressed, and it wouldn't really affect any buying decision or recommendation. I just have to wonder where the performance issues actually are; I'd _think_ that one should be able to manage a reasonably responsive GTK/X gui on it, given *cough* other similar devices... Plus, more work, more delays for switching from X over to Something Else. But I'm no expert on hardware of this grade and relevant software, so I'm just spewing intuition here. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ 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?
On ke, 2007-06-06 at 14:52 +0200, Tomasz Zielinski wrote: As we know, much less powered machines (like 7MHz Amiga with Workbench and even 1MHz C64 with Geos) had enough resources to provide rich and usable user interface. I mentioned PalmOS some time ago - it executed programs in-place so most apps started literally in half a second. Incidentally, have people with the hardware tried to run it with select essential programs and libraries loaded onto a tmpfs at bootup, where they'd AFAIK be executed in-place? Don't know, but seems that it might be a feasible way to speed app-launching and switching for select core stuff, bypassing jffs2 overhead. Of course, that would reserve some otherwise reclaimable RAM and if the kernel and jffs2 are smart about caching in these kinds of circumstances, may not make much of a difference. Just an idle thought. If with GTK/Matchbox we cannot achieve such rich, fluid and, erm..., fluid GUI as iPhone, maybe it's not too late to drop GTK Yes it is, by the way. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Openstreetmapping with Neo and others
On ke, 2007-05-30 at 10:48 -0400, Ian Darwin wrote: A simple app to add data for the OpenStreetMap project on OpenMoko will probably help a lot. Absolutely. And I'm sure several of these will come into being. If you want reuse, however, you should think about writing it in Java. Believe that there will be good Java ME implementations for OpenMoko. Purely from an OSM perspective a good free Java ME mapping app would indeed be killer, and you're probably right in suspecting that it would be usable on Moko as well before long. You're also probably right that there will be several; it's one of the very obvious things to do while GPS toying, and not too hard to get up to basic functionality, while having lots of possible frills to add on top of that. Attractive for a geek project ;) So, for OSM it would be good if a part of the interested mapper developers chose to do a Java ME mapper. One possible way to do so wouldn't require a separate project as such; given a mapper application coded in C and architected to separate the GUI from the core logic, a Java ME port could conceivably be maintained using Cibyl¹, the C-to-J2ME compiler. Apparently RoadMap has been ported to J2ME with it already, doesn't seem too good with OSM integration from quick glances though. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: GPS+sms apps
On ti, 2007-05-29 at 09:15 -0400, Crane, Matthew wrote: I guess SMS is generally more accessable and tends to be a lot cheaper, often free, in Toronto and most of Canada. I didn't know SMS are often free; here they cost a bundle, though a bit less if you take a bulk deal in your monthly fees. OTOH, here we have quite affordable no-limit GPRS(/EDGE/UMTS). Clearly it would be good for a locator service to be able to communicate via both methods, depending on what kind of a mobile plan the user has. As for availability, for a GPRS-preferred user of such a service you could pretty much assume that they are connected whenever the phone is on and has coverage, so not that different from SMS... -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: First impressions of Neo1973
On ma, 2007-05-14 at 07:21 -0500, Steven ** wrote: It also occurs to me that in an OK/Cancel dialog, OK is always on the left. So again, consistency would suggest leaving it that way. OpenMoko uses GTK, which per default uses the Mac-style OK on bottom right approach, which I find to be better argued for. So, incorrect. Also not all phones have answer/call on left and reject/end-call on right, though it is true that it seems to be the majority vote. I have seen phones where it is reversed, but don't recall the models. I have no strong opinions on the answer/call and reject/end-call ordering, but would like it if the GTK practice was adhered to. This _would_ logically place also answer/call on the right, of course... Perhaps for the answer/call buttons at least the order should be settable, default maybe the order most phones do it in. (And of course it is in the end settable anyway, but from a GUI ;) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Widgets: Openmoko/Chumby transproject?
On ke, 2007-04-25 at 08:23 -0600, Joe Pfeiffer wrote: Florent THIERY writes: If you're about Macromedia Flash (er, now Adobe), isn't it closed source? The neo has a closed source real time OS running the GSM part... OS? It's been said pretty consistently that it's a user-mode daemon. He's talking GSM, not GPS. The GSM chip indeed has its own proprietary OS. However, that's IMAO a special case and very different from any user-mode software on the SOC side. We want an open GNU/Linux system on this phone. It would be _nice_ to have an open GSM system as well, but not possible at this point. The GSM part is nicely encapsulated as an integrated peripheral providing a standard API. As such it's not of as much openness interest to the application developers and users as the base GNU/Linux OS with its application libraries is. Heck, apparently even Stallman only had a problem with the GPS plugin. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Richard Stallmans standpoint about openmoko
On ti, 2007-04-24 at 17:02 +0400, t3st3r wrote: As for me, I'm have to ask few unfair questions. These are not unfair, IMO. 1) Why there should be some closed-source daemon which does some unknown things?And why should I trust it, if I have no idea what it does? Actually, closed-source plugin to a daemon, but that's just a nitpick, and the issues remain the same. You can toss it if you don't trust it. I personally expect it to be reverse-engineered and replaced by a communal free plugin in relatively short order, considering that the data in an out of the plugin will be available to us. 2) As I understand, to fully use features of AGPS I should send some data to some server over network, without really having any idea what they will do with these data, if they will collect them for later use and if my privacy protected here or not. Correct. Don't know if the plugin will allow you to use your own server or other source of satellite tracking data not, as I'm not with Moko (and apparently there's some issues for them even getting their hands on working GPS drivers; hey, Moko people, how's that going, by the way?). However, turning the assist feature off should keep you private assuming no intentional backdoor, and mostly just cost you time to get the first fix. (I wonder if the Moko people will see the source or only the GL people, that would at least add some trust for me...) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On to, 2007-03-22 at 11:31 +0100, Sven Neuhaus wrote: One remaining question is if the user manually wants to lock the phone during use (usually with a PIN). We can't really unmount the microSD card because then the phonebook is unavailable and incoming calls can't tell who is calling (and thus how to treat the call). So I guess it remains mounted all the time, which considerably lowers security of course. Well, I wouldn't say considerably, if you lock it down so that it'll only be able to receive calls without the PIN (and a few false PINs will unmount the encrypted microSD, as you say; perhaps even just turn the phone off, accomplishing the same). You still leak a bit of information from incoming calls (caller ID, caller ringtone, etc), but I wouldn't call that considerable. Of course, a severe security bug in the lockdown program would in this case compromise the whole encrypted microSD; the code where such a thing can happen should be isolated and under extra scrutiny. Perhaps the phone should unmount the card after you enter the wrong PIN a few times, or enter a special PANIC-PIN. Yeah, a short panic code would be good too. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Features and promises
On ti, 2007-02-27 at 10:52 +0100, denis wrote:
Why can't they just tell us what the features will be? Is it so
difficult to be open? In my opinion it would bring much more credibility
for FIC.
Allow me to hazard a guess:
Most of this stuff is preliminary plans, and the guys don't like to make
promises they know they might now be able to keep. That's also why I
think Sean was being evasive about that other thing that everyone asks
about. If something goes wrong with the plans, as things go sometimes
and have gone in parts of this project already, and they can't deliver,
what would that do to their credibility? ('course, everyone is already
jumping at that other thing regardless, but apparently that's how it
goes...)
To repeat, this is all just guesswork; I don't have any inside
information. And I for one will be getting one of them p1 devices; get
in on the ground floor, people. If you feel you need to upgrade right
away, arrange a new home for the older one; I suspect you'll be able to
get a reasonable resale price for the old model as well (my p1 Neo will
go to my SO though when I upgrade ;). Spread the Moko, you know you want
to, since the more there are of these in _your_ social circles, the more
useful they will be to you, too :)
--
Mikko J Rauhala [EMAIL PROTECTED]
University of Helsinki
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Wifi option summary (Was: Re: OpenMoko Challenges)
On ma, 2007-02-12 at 01:54 -1000, Joshua Hoblitt wrote: Quick thought: Shouldn't wifi be possible via the use of a USB dongle? Yes yes, if you get it power from somewhere other than the Neo (such as an internal battery, USB power injector, or a (battery) powered hub). It's been discussed before. Speeds won't be great (USB 1.1 limiting), but should be doable. To summarize for those who haven't noticed, another possible option, if you really need wifi, might be the (also previously mentioned) upcoming Seagate DAVE disks; they have both BT and Wifi connectivity, and are supposed to be open systems, so perhaps it will be possible to make one into a self-powered BT/Wifi gateway (in addition to portable storage), at least if they run Linux. However, no definite word on the extent of their openness and adaptability exists at this point, just a possibility. And, as also said, you can get wireless internet via BT too, just that the Wifi AP installed base is out of reach. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Ogg Vorbis Chips for Neo3000? :-)
On ke, 2007-02-07 at 10:58 +, Dave Crossland wrote: Thought http://hardware.slashdot.org/hardware/07/02/06/1931244.shtml was interesting - it would be cool to have an OGG decoder onboard a future Neo for iPhone style music-player/phone hybrid functionality in the free software context :-) A nice piece of equipment, to be sure, and good to have those around. Still, I doubt it would be worth the cost and space to put it on an (n-gen) Neo; it has a powerful enough general purpose processor, and while the battery would likely last somewhat longer playing with that chip, a music decoder chip wouldn't add any new functionality. (Now, if they'd make a _Theora_ decoder chip... ;P ) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Text messaging on the OpenMoko platform
On ti, 2007-02-06 at 09:56 +, Sergio Bessa wrote: As most of you might know there are transports that make it possible to connect to MSN / ICQ [...] What if we could have Jabber support in OpenMoko and use some sort of transport/relay to connect to legacy protocols? Don't you think this would work? This way we only needed one protocol implementation. I for one think it's a good idea to concentrate on Jabber support on the OpenMoko itself. Jabber is open, versatile, extensible, already has options for gpg-usage for us heavy security nuts, etc. And I don't wish to put down the legacy protocol gateway support (the use of which should be made as easy as possible, of course). This would simplify the software needed phone-side. So, we'd need reliable servers with legacy gateway support. I wonder if FIC would consider providing an appropriate Jabber server to customers. This would enable pretty easy default setup phone-side (basically, if you'd use the FIC server, you'd just have to provide your preferred username and password; if you'd want legacy access you'd also of course have to give eg. your MSN account). Can be done without FIC, of course, but it would be nice to have some trusted server that agrees to be the default and provides the legacy transport support :) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Text messaging on the OpenMoko platform
On ti, 2007-02-06 at 12:24 +, Florent THIERY wrote: The best would be: - using a plain text protocol : irc would be great, but prevents further extension (webcam over ip or voip), so SIP might be better Yes, irc is notoriously inflexible. Thus my wish for Jabber. As for SIP, I don't think it's the best thing for this job... VOIP, sure, text messaging/file transfer/etc, iffy... - using a compressive transport layer (tunneling into ssh, with compression ?). TLS (and apparently its implementations in gnutls and openssl) support compressed transport (which makes sense, since if you don't compress before encryption, you don't compress). A good compression layer should in theory negate much of the XML overhead, at least if you keep mostly persistent connections. My opinion is, if we really want to turn the OpenMoko platform to it's maximum extend, we'll have to associate it with a server-side component (running all the time, such as a WRT or NSLU2 device), a multiprotocol IM gateway, a remote storage feature (sshfs?), an imap webserver, a web gateway... Everything tunneled into a secure-as-possible connection. You can do nice things with your own persistently available server, yes, but one shouldn't be necessary to mostly enjoy OpenMoko. You mentioned a web gateway; I assume you mean a web proxy that's tunable to eg. recompress images smaller (and crappier) and such to make gprs browsing a bit faster, and stuff like that - if you didn't, I do ;) -- Mikko Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
On pe, 2007-02-02 at 09:06 -0800, Tim Newsom wrote: If we have access to the mic and speakers while a call is in process, and we have the ability to record conversations etc... Where does the processor sit in that chain? Can we consume the voice, encrypt it and feed an encrypted datastream back out to the gsm module which would transmit it and another neo1973 user could receive the stream, process through decryption and play out? No. The GSM processor does its own audio de- and encoding, and its connection to the audio i/o is analog, as reported by LaF0rge on irc a while back (any misunderstanding is probably mine if present, though). We can get at the audio via the a/d converters, but not do anything really fancy directly. Thus, I refer you to my last mail; make a GSM data call (phone-to-phone if possible, if not, both dial out and arrange the call via some server), transmit encrypted Speex stream. There would still be a bit of latency, but you would get reserved bandwidth at least. This of course costs extra. Probably one of the principal reasons why GSM chips don't like you sending your own digital data over voice calls. :] -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Translators needed?
Incidentally, I've done free software translations into Finnish before, and I live with someone who has also, and happen to know quite a few other people with experience and interest in this area as well. I'm not sure at this point how much I can personally promise to do for Finnish translations, but I imagine that some, and perchance fork out some to said contacts. If other Finns here are interested in this type of thing, let's stay in touch. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Is python built-in
On ma, 2007-01-22 at 15:07 +0100, Robert Michel wrote: Salve Mikko! _Default_ software. The default stuff must fit in without a microSD. Oh I see much power with 64MB flash and I do expect a skripting language like python fit on the flash. But not every lib must be inside the flash, right? It's may possible to fit it in depending on other software, sure, and certainly not everything has to be on the on-board flash, just everything in the default install. Also, my particular piece of software I was thinking of currently depends on pygnome as well and not merely Python. :] I'll probably install python too, via BT-PAN or GPRS, but I don't expect it to be in there by default. Can I ask you why not via install it via USB (Network or USB flash stick) or from a microSD card (1GB starts at 16 Euro, 2GB at 46 Euro), why via GPRS? The method is of no consequence really, I merely mentioned it on the side because Jose said earlier Considering that Neo1973 doesn't have WiFi, I can't image clients downloading python-runtime by apt using GPRS ;-) (though I'm likely not a client he was talking about :). (Yes, we have affordable flat rate here.) USB-net, perhaps, if the default install will make USB-net easy. I have no motivation to tune USB networking. (With BT I will, however, tinker if FIC doesn't provide ready-made PAN support or somebody else doesn't beat me to it.) Big flash on a PCB is quite expensive, why not live with having libs, programms and data on the micro-SD? I don't see who was arguing against having libs, programs and data on the micro-SD. Nokias 770 has 128 MB flash but only 64 RAM - when I could choose I would take a Neo with 32 MB flash when it would have 256 MB RAM ;) Mmh, 64 MB RAM does seem a bit limiting, though it's an old generation already. (Ah well, I'm also not going for Nokia because of their love-hate-openness thing.) -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: X11 and/or Framebuffer
On ke, 2007-01-17 at 17:48 +0100, Harald Welte wrote: [EMAIL PROTECTED]:~$ xdpyinfo [...] XVideo This peaks my curiosity; do we get XVideo scaling on the graphics processor without stressing the CPU? Colorspace conversion? Thanks for the info. -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
