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
Re: Is python built-in
On ma, 2007-01-22 at 14:10 +0100, Robert Michel wrote: > On Mon, 22 Jan 2007, Tomasz Zielinski wrote: > > I seriously doubt it. I found python RPM and it has about 10 MB > > *compressed*. All default Neo1973 software (including kernel and libs) > > must fit in 64MB flash storage... > > Why? it have a mountable microSD card (1,2, maybe 4 and more GB)- > the 128MB RAM is the counting limitation, not the flash ;) _Default_ software. The default stuff must fit in without a microSD. I'll probably install python too, via BT-PAN or GPRS, but I don't expect it to be in there by default. (Have to adapt my python ghextris for the Moko, after all ;) -- 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: 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: Voice over GPRS?
On pe, 2007-02-02 at 11:37 -0500, ROB wrote: > 1kb/s isn't going to get you too much audio. Try encoding an mp3 at > 1kb/s to see how audible that would be. I think you'd be looking at > something more along the lines of 32-64kb/s to get anything that you > could understand. mp3 isn't designed for that, though even speex's minimum is 2kb/s (probably you want to use more). Anyway, Robert was talking about 1kB/s, which is quite fine already. But the main point that GPRS is not for VOIP really stands; short voice messages, sure, an ongoing dialogue, no. Of course, you can make a GSM data call (I presume) and thus reserve bandwidth from the network; some latency issues would remain, but you could probably get a reasonable VOIP connection going on that with low-bandwidth Speex; would likely cost you but perhaps be an affordable option for intl. calls. (Also, _this_ is how you can accomplish a proper encrypted phone call using the GSM network with Neo, if you're into security and don't mind it costing a bit. Doubleplusgood if you can make a data call from cell to cell direct without both sides having to initiate their own data calls; not sure about that, GPRS suffices for my uses so haven't looked at data call capabilities.) -- Mikko J 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: 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: 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: Free maps after all?
On to, 2007-02-08 at 13:39 +0100, Gabriel Ambuehl wrote: > http://go.theregister.com/feed/http://www.reghardware.co.uk/2007/02/08/nokia_frees_smart2go/ Before I see the license, I'll assume that the maps are free to use only with their restricted gratis application (which may or may not be an enforceable restriction depending on jurisdiction). I have no doubt though that if the maps are in some readable format, they will be used with other programs too... But OSM is still an important project even in areas that these maps cover, I wager. Of course, Nokia is welcome to surprise me with a liberal map license ;) -- Mikko J Rauhala <[EMAIL PROTECTED]> University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko Challenges
On ma, 2007-02-12 at 11:59 +0100, Pedro Aguilar wrote: > I understand the problems that could happen when developing embedded > devices, so I appreciate that you're sincere and provide us the source > code as a good (although not ideal) starting point. I don't usually post "me, too"s, but I feel I have to join in in this public support of the hard decisions Sean and the team has had to make. I know will be checking out the source code; good of you to publish that now (well, soon) even if it's in-progress and hardware will take a while longer. I do also appreciate that adding Bluetooth back in wasn't trivial, but it does make the first edition much more useful (esp. local wireless internet, in lieu of wifi), so thanks for reacting to those requests. Now, just keep up the good work in freeing our phones :) -- Mikko J Rauhala <[EMAIL PROTECTED]> University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://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: OpenGL on the Neo1973??
On Mon, 2007-02-12 at 19:06 -0800, Paul Bonser wrote: > Porting SDL to the Neo1973 would probably be a good option since it > uses a relatively thin wrapper around native calls. IIRC, the FIC guys have already experimented with SDL. I seem to recall an IRC conversation where someone mentioned having to come up with a way to switch back from full-screen SDL, since the usually recommended alt-enter is, well, not available in default packaging :] It might've been also just someone's idle speculation, but if my memory servers, it was somebody who actually had done work on that or at least was familiar with work done on that :] > If somebody wanted to do an OpenGL ES implementation for it, that > would probably also be good, though at 233Mhz, it's not going to have > much power spare for rendering, and plus, the SDL port would be much > more useful all around. Indeed on all counts. -- Mikko J Rauhala <[EMAIL PROTECTED]> University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://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
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
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: 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: 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: 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
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: 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
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: 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: community Digest, Vol 34, Issue 38
On pe, 2007-07-06 at 07:56 -0400, Michael Sersen wrote: > Does anyone know if there will be a discount on the 2nd gen models, > for those who buy the 1st round? Personally, I'd shell out the cash > now if I knew I'd get a breakdown when the consumer model hits the > streets. *sigh* As Sean clearly said in his previous announcement (which is on-line at http://openmoko.com/ ), "We've decided that instead of setting up a complicated return or tracking system to remember who gets a discount for GTA02, we going to give you _all_ a discount on GTA01." So no, you won't get a discount on the GTA02. However, the GTA01 is $300 instead of the previously announced $350. -- 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: What's the real scope of hardware openness?
On ma, 2007-08-06 at 13:26 +0200, Luca Dionisi wrote: > I have a likely silly question. Not that silly, though the context is wrong. Doesn't have that much to do with hardware openness. > I mean, what if each phone in a neighborwood could be used as > a "radio-bridge" in order for a caller to find a path to a callee > without having to rely on a network operator and pay for it? The calls would be less reliable with lower quality of service, the problems increasing with the number of simultaneous callers, plus their phones would eat up power like crazy. > I thought that the absence of this feature was a limitation > imposed on the user from the phone builders. So when I saw the > FIC initiative I thought that this kind of openness could lead > to the possibility of such a scenario. With GTA02, you should be able to do Wifi mesh networking and route VOIP calls through that, if you like. Just that, well, see above. (With GTA01, all you have is Bluetooth, and while it's suitable for a lot of stuff, let's just not.) What you can't do is use the GSM frequencies for this kind of thing, first because you don't have access to the GSM chip firmware, and second because transmitting on the GSM spectrum without timeslot allocations from the cell tower will cause you to interfere with people's calls, some of them emergency ones. Plus the illegality of it all. -- 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 ma, 2007-08-06 at 14:50 +0200, Luca Dionisi wrote: > On 8/6/07, Mikko J Rauhala <[EMAIL PROTECTED]> wrote: > > What you can't do is use the GSM frequencies for this kind of thing, > > first because you don't have access to the GSM chip firmware, ... > > Well, then it IS a matter of hardware openness too. The point is that you must be a 1) criminal 2) sociopath to even want to do this thing with the GSM radio in particular, even if you could. The wifi on GTA02 on the other hand will be capable of this sort of thing (legally and ethically), therefore not really a hardware openness issue, IMAO. Just that there would still be the practical problems indicated by me and others. Don't get me wrong though, the Neo is not optimally open, and there are also non-evil things that the GSM firmware being closed restricts us from doing. I don't particularly like it, but it's a reality of today. We'll just have to mold where the future takes us, and the Moko. -- 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
Re: Adding an overview page to openmoko.{com,org}
On ti, 2006-11-21 at 10:46 -0800, Chad wrote: > Reading between the lines here - it sounds like there's some issue > keeping BT from working correctly - if the issues are only in the > software stack and can be worked around later, I'd personally rather > have the hardware included even if it's only partially working at > launch and fixed a few months on. With apologies for keeping the "we want Bluetooth" thread alive, I'd nevertheless like to commend this suggestion if this is, in fact, the case. Eg. if the phone software might not be taking full advantage of a Bluetooth interface early on, it's still a win to have it on board; and maybe some of the buyers would also fill in some gaps in high-level BT functionality. That said, and having done some thinking, I'm leaning towards buying the phone regardless. -- Mikko J Rauhala <[EMAIL PROTECTED]> University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/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: 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
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: 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
Re: Bi-weekly OpenMoko community update
On ti, 2007-10-16 at 12:52 +0200, Michael 'Mickey' Lauer wrote: > Lars Hallberg wrote: > > Butt... For the old GTA01, that have the old chip, and that will not be > > used in the future, it is completely sufficient with a binary driver > > accessible thru the same interface as the GTA02 phones > > Probably not the same interface, since gllin insists on this > /tmp/nmeaP whereas more recent gps daemons spit out the information > via dbus. One would imagine the common abstraction being such a daemon, and gllin acting as a mere frontend to it. Other than some extra memory consumption (which isn't quite the trivial matter on this device, to be sure), shouldn't be problematic, or? -- 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 AT&T/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: 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: 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: 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: 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: 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
