FSO project hosting (mailing lists, ...)
Quick update: I have gathered the old subscribers’ list and have invited (not autosubscribed) all former members. If you are not among the invited and have interest to participate on the future of the FSO middleware stack, then please feel very welcome to join f...@openphoenux.org Best regards, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Hi, Arguably those two paragraphs are already well satisfied by oFono. oFono probably now has the advantage in terms of maturity and deployment, is compilable by a standard C compiler, and has a recent version packaged in Debian. FSO is compilable with a standard C compiler as well. Every tarball release we did has been shipping C files. The following may sound pointlessly controversial, but I don't intend it that way; I think it may help the FSO developers to review and understand more precisely their objectives. Why is FSO still needed at all, given that oFono exists and appears to have the development mindshare and advantages noted above? Would your objectives be achieved more quickly or easily by switching to oFono and contributing any needed additions to that? Oh, FSO is so much more than oFono. If you want to compare, then compare oFono to fsogsmd alone. As for the comparison between those two, well, fsogsmd was first, has (IMO, of course) a better architecture, a better API, and supports other modems. And there's no agenda of a company behind – some people may view that as an advantage, rather than a disadvantage. I don't see why we should invest time in something we consider not being superior. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: server update
Very well summarized, thanks Timo! Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] [FOSDEM] Third call for sessions for the FOSDEM cross-distribution miniconference
Am 21.12.2011 um 13:37 schrieb Dr. H. Nikolaus Schaller: Looks as if they urgently need more talks. This is IMHO a chance for SHR, QtMoko, FSO to present the latest great progress to a wider audience! Yeah, there's just one thing that's annoying me... 15 minutes is pathetic. Ok, for FSO we could split that into two talks like one describing the idea and the architecture and the other one describing the state of the ports. Anyone volunteering to submit part 2 if I submit part 1? Cheers, :M: ___ App-Developers.de - Lauer, Teuber GbR Frankfurter Str. 181 - 63263 Neu-Isenburg - Germany Tel. +49 6102 8376 32 - Fax +49 6102 8376 33 Twitter: twitter.com/AppDevelopersDe ___ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to forward FreeRunner's audio ?
Am 21.06.2011 um 21:26 schrieb Gennady Kupava: I did it in other direction (freerunner as network headphones) and pulseaudio performance were excellent, only thing you need is to select right mixer, one without floating point calculations. Sounds interesting, could you provide more details, please? Only problem i faced after upgrade - it stopped working due to some arm segfault, don't know may be this already fixed. Newer versions of PA actually broke compatibility with armv4 completely as they're using some v5-only instructions in the optimized arm assembly code. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to forward FreeRunner's audio ?
Pulseaudio could indeed do what you're after, however we had to remove pulseaudio from the SHR distribution due to its abysmal performance on armv4. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Aurora
Hi Corey, On Monday, May 16, 2011 09:02:58 AM Michael 'Mickey' Lauer wrote: NOTE: Cross-posted to three mailing lists, please keep it that way, if you want to reply. Aurora is supposed to be something we call a featurephone client – featurephones being those things we used for telephony before smartphones were invented. Could you please elaborate a bit further for those of us who are unsure of the specific functional differences between a featurephone and a smartphone? For sure. Featurephone vs. Smartphone is resembling the difference of, lets say, a Sony Ericsson K700, and an iPhone. On the K700, the whole OS is designed around the telephony. While it has additional features, it doesn't allow you to install native applications (well, yes, there are some Java applets, but these don't count as they are not at all integrated into the system and they can't access the phone databases nor talk to each other) – it sells because of the quality of the telephony. On the iPhone, the whole OS is designed around the idea of a mobile computer that allows you to perform a vast variety of tasks. You can install a myriad of apps and only a very minor percentage of these apps have anything to do with telephony. The telephony is a feature among many others. In fact, telephony is pretty lousy on an iPhone, but that's ok, because it is not the feature that sells this device. Bottom line: feature phone is less flexible, comes with everything preinstalled, and is designed around the telephony. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Aurora
Am 17.05.2011 um 18:06 schrieb Martin Jansa: Bottom line: feature phone is less flexible, comes with everything preinstalled, and is designed around the telephony. There is nice description of feature phone and smartphone in Chapter 2 http://gnumonks.org/~laforge/papers/gsm_phone-anatomy-latest.pdf but I guess this doesn't help much to imagine featurephone client :) Yeah, Harald focuses on the BP vs. AP/BP separation, which is a hardware- centric view – while I tried to capture the 'spirit' ;) Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko and FSO
The changes done in v32 are still not really digested, I think. I see the challenge of moving to FSO, from a programmer's point of view, as very, well, challenging, and thus nice. But, from a user's point of view, what are the advantages? The future. Support for devices other than the Openmoko GTA, i.e. HTC, Motorola OpenEZX, Palm Pre, Nokia N900, but also forthcoming devices, such as the Goldelico GTA04, newer HP devices etc. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Audio.PullScenario() triggers unwanted idle state change
Hi Daniele, Greetings, sorry for the crosspost, but for this kind of post i guess it's better to post on every development list. I have a need to set idle state to PRELOCK as soon as a phone call ends. When the call ends, audio scenario is pulled, and soon after that idle state is forced to PRELOCK by my app. However, changing scenario seems to trigger idle state change to BUSY, so vanishing my attempt to force it to PRELOCK, or any other state. I could try to sleep for e.g. 2 seconds before forcing PRELOCK, but i don't think it's the right way to do this. For some reason writing an alsa scenario triggers activity on an input node which in turn is responsible for moving to the BUSY state. I wonder whether it's the headphone ctl? If so, we should attempt to skip that – or fix it in the kernel driver... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Audio.PullScenario() triggers unwanted idle state change
Am 09.12.2010 um 16:32 schrieb Daniele Ricci: Should I open a ticket on FSO for this? If we agree FSO being to blame, yes. I'm not sure yet though... :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone with spare debug board in Czech republic?
Send me your address and I'll get you a free one. (V2 only) :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Leaving the Openmoko community, new wiki-admin needed
Hi Marko, I have previously worked as the administrator of the Openmoko Wiki for the last year. Unfortunately I have to announce that I will stop my involvement in the Openmoko community and so a new admin is needed. Thanks for all the work you did! The reason for leaving is quite simple: I broke my FreeRunner last weekend at a party. Although I enjoyed my time with it I won't get another one. (Instead I'm getting an N900 and hoping for MeeGo or Debian + FSO to provide a free OS for this device soon) Excellent. Fortunately Nokia provided me with a development device, so I'm in possession of an N900 since monday. Lets see whether we can pull something off. In any case, if you have some spare time, I'd appreciate taking a look at the FSO wiki, which covers the feasibility of all kinds of anti-vendor-ports as well. Best regards and thanks again, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
Am 13.08.2010 um 03:45 schrieb Joshua Judson Rosen: Brian bn...@rochester.rr.com writes: On Thu, 12 Aug 2010 15:55:21 +0200 Dr. Michael Lauer mic...@vanille-media.de wrote: Unfortunately the freedom loving people are doomed to either work on anti-vendor-ports (such as HTC devices etc.) or live with one of the semi-free alternatives (Palm Pre, Nokia N900). Right now there is no device rivaling the FreeRunner's openness, nothing comes close. I wouldn't necessarily color all ports of FOSS as anti-vendor. In fact don't they demonstrate the versatility and adaptability of FOSS in relation to all hardware, especially hardware that isn't open? That's a good thing if the goal is to strive towards choice for consumers. Granted it's not the ideal situation but it is a step in the right direction. The term anti-vendor port initially struck me as a little odd, as well, but now I think that Mickey is using a fairly strict definition of anti-, meaning contrary to--with anti-vendor meaning contrary to the vendor or (more clearly) contrary to the wishes or actions of the vendor. Correct. This is exactly what I mean – the vendor is not going to help you and chances are it has taken measures to make your job really hard (such as using completely undocumented custom silicon, let alone e-fuses or nightmares alike). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Hackable:1] serial terminal program
Am 11.08.2010 um 18:38 schrieb Gay, John (GE Energy Services, Non-GE): I've been wanting to try using my freerunner as a serial terminal to debug servers via serial. I've got a USB-serial adapter that H:1 recognizes and assigns to /dev/ttyUSB0. My problem is, minicom won't run because the shell screen is to small. Mickeyterm fails to find a bunch of python modules and things via dbus. I've even tried cu -l /dev/ttyUSB0 but it says the line is busy. Anyone know of a serial terminal program that does work on H:1? I use mterm2. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
Hi Sriranjan, as far as i know, openmoko is no longer working on phones. Unfortunately the freedom loving people are doomed to either work on anti-vendor-ports (such as HTC devices etc.) or live with one of the semi-free alternatives (Palm Pre, Nokia N900). Right now there is no device rivaling the FreeRunner's openness, nothing comes close. I don't see that changing soon. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linux under one second
Am 30.04.2010 um 09:19 schrieb flecktor: i heard they made linux under 1 second. http://www.youtube.com/watch?v=wUWBkIquQaI is there any distrobution that will take that and made it available for the openmoko? First, the Openmoko devices are way slower than the presented device. Second, it depends on your definition of booting. What this demo does is reading a kernel from somewhere and launching into a one-process userland, most likely skipping any init processes. They don't initialize slow peripherals such as a modem nor show a launcher. Our Linux (as in kernel) boots in a handful of seconds as well. Right now most distributions use sysvinit, which is the reason why it takes a couple of more minutes after booting to show a desktop. Witha proper replacement, (such as my pet-project fso-boot), I'm sure we can get to 30 seconds until PIN dialog as well – which IMO would be quite amazing given the hardware. (FWIW, on my HTC Dream w/ Zhone2 it's 10 seconds until PIN dialog – no X though, just framebuffer). :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-t] typing sms over ssh
Am 23.04.2010 um 11:56 schrieb n...@el-hennig.de: Just a question : is there any way to launch phoneui-messages through ssh -X ? It keeps ignoring $DISPLAY and displays itself on FR screen... IIRC I was able to do that previously... maybe an alterantive would be using thone... http://code.google.com/p/thone/ Or mdbus2. If all you want to do is send an SMS, it's one line with mdbus2. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko], opie
Opie is based on Qt 2.x; 4.x is so different, almost nothing will work. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [[SHR all] Read this if Call screen and messages dont work - a.k.a.- fixing dissappearing call window, segfaults and name-to-number resolution
Am 16.03.2010 um 01:07 schrieb Sebastian Reichel: On Tue, Mar 16, 2010 at 01:01:28AM +0100, Bernd Prünster wrote: Rui Miguel Silva Seabra wrote: Em 15-03-2010 23:36, Bernd Prünster escreveu: mdbus2 -s org.freesmartphone.opimd \ /org/freesmartphone/PIM/Contacts \ org.freesmartphone.PIM.Fields.ListFields I get r...@om-gta02 ~ $ mdbus2 -s org.freesmartphone.opimd \ /org/freesmartphone/PIM/Contacts \ org.freesmartphone.PIM.Fields.ListFields Segmentation fault r...@om-gta02 ~ $ (updated yesterday). Rui then you need to issue the suggested commands (hopefully i am right.. my brain is a little slushy already) mdbus2 should not segfault in any case. Try to get a backtrace and report it to upstream. Yes, please! :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Comparing A5 and A7 sound settings
Well, former Openmoko CEO of marketing always said there is one state file to rule them all - does that hold no longer? Cheers, :M: Am 15.03.2010 um 06:45 schrieb Dr. H. Nikolaus Schaller h...@goldelico.com : Am 14.03.2010 um 23:42 schrieb Ben Wilson: Just my two cents. I think at this point distributions' defaults should be towards A7 users, since all new users are anyway A7 users and A5/A6 owners by now are surely aware of the ALSA setting problematics. Hi, If it really depends on the Ax model I think they should be somehow distinguished by /proc/cpuinfo so if different ALSA settings are needed, they should be selected automatically based on that. It would be a big help. Totally agree. It's a good idea, but how would it get the info about which Ax version the user has. Even if the A(x) manufactured version is detecable in software I doubt a home modified A(x) to A(x+1) is. It would really need to be user specified. Yes, there is no chance to detect it aitomatically. But there could be a nice Settings GUI: Base Model A5/A6/A7 Buzz-FixO YES O NO #1024-Fix O YES O NO Bass-FixO YES O NO Maybe, FSO could support the underlaying database? Nikolaus ___ 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
Applying for GSoC 2010
Hi folks, After our successful GSoC in 2007 and 2008 as Openmoko -- and us not being on board in 2009, I decided to try apply again as a mentoring organization this year. Please toss some ideas to http://wiki.freesmartphone.org/index.php/GSoC_Ideas I'll keep you posted on the results. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Applying for GSoC 2010
Am 11.03.2010 um 17:28 schrieb Jeffrey Ratcliffe: On Thu, Mar 11, 2010 at 05:23:15PM +0100, Dr. Michael Lauer wrote: After our successful GSoC in 2007 and 2008 as Openmoko -- and us not being on board in 2009, I decided to try apply again as a mentoring organization this year. Isn't tomorrow the closing date for submissions? Correct -- for mentoring organizations. Full timeline is @ http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/timeline :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] phonfsod/phoneuid: fso-deviced killed when calling
Am 22.02.2010 um 03:12 schrieb Sebastian Reichel: On Sun, Feb 21, 2010 at 09:29:49PM +0100, Michael 'Mickey' Lauer wrote: Am Sonntag, den 21.02.2010, 19:21 +0100 schrieb arne anka: investigating my core issue of the fr not suspending anymore after a call, i see now that fsodeviced dies the moment i hit either call (outgoing) or accept (incoming). since fso-deviced is dead, nothing, in terms of idle notification at least, happens anymore. A backtrace would be splendid. Could you install -dbg packages as well as gdb, change params to have apps emit a coredump and then get us a backtrace? Or just run fsodeviced directly under gdb and once it dies get us a backtrace. Cheers, :M: Hi, You fixed this already in [1]. fso-deviced in Debian is still from Janurary 2010, because of the added libnl2 depdendency [2] from libfso* in newer versions. I just uploaded a new fso-deviced package adding a -dbg package and the referenced patch. Ah, awesome. Thanks for your work! Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Experiment: better sound on remote end
It'd be helpful for the rest of the stack, if dictator would just use FSO's Push/Pull scenario methods instead. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
