Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Sun, 23 Sep 2012 07:58:18 AM Radek Polak wrote: On Saturday, September 22, 2012 10:44:54 PM Neil Jerram wrote: Ah, thanks, I understand your question now: what version of fsogsmd does QtMoko build with, and isn't that now rather out of date? But I'm afraid I don't know the answers. I was using FSO from git at the time when i was implementing FSO backend. I am quite sure FSO from wheezy will work unless FSO api changed. However for now it makes no sence to use any dbus modem middleware as default. QtMoko's modem library is very stable and works IMO very good. I dont see any benefits in using FSO or oFono right now. But still if you want to use FSO or oFono the support is in every QtMoko installation - just change export QTOPIA_PHONE=oFono or export QTOPIA_PHONE=Fso in /opt/qtmoko/qpe.env and QtMoko will use the dbus backend for telephony. Regards Radek This is getting off topic now :) I came into this discussion because I want to check the version of the gsm firmware, to see if it needs to be upgraded. The wiki has a page on doing this via FSO with dbus [1]. Is there a different method available ? The reason I wanted to do this is to see if there is a bug dealing with NITZ that may have been resolved, but I am not sure at what level in the stack it is. According to [2] the AT+CTZU command is supported. To do this I need to talk to the modem, but nothing is being returned ? I have tried chat [3] and cu [4] without success. Trying cu, I typed AT and get no response. Is this a Calypso firmware bug as described by Alex [5] ? [1] http://wiki.openmoko.org/wiki/GSM/Flashing [2] http://wiki.openmoko.org/wiki/Hardware:AT_Commands [3] http://lists.openmoko.org/pipermail/community/2012-September/067496.html [4] http://wiki.openmoko.org/wiki/Neo_1973_and_Neo_FreeRunner_gsm_modem [5] http://lists.openmoko.org/pipermail/community/2012-September/067509.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Adam Ward cay...@internode.on.net writes: On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote: On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: As far as I know Qtmoko can use FSO but does not as default. Yes this is correct. My plan was to use FSO for GTA04. But when i got my GTA04, there was no work for this device done in FSO, so i rather added gta04 modem plugin based on qtopiaphonemodem framework and this now default. New GTA02 user here, I see the code in neocontrol.cpp pulls the library from http://activationrecord.net/radekp/pub/ I am guessing that at the time it was current. The debian package is now current, so I would expect it to be used instead ? I can't tell what you mean here. Which library / package? Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Sat, 22 Sep 2012 10:01:23 AM Neil Jerram wrote: Adam Ward cay...@internode.on.net writes: On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote: On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: As far as I know Qtmoko can use FSO but does not as default. Yes this is correct. My plan was to use FSO for GTA04. But when i got my GTA04, there was no work for this device done in FSO, so i rather added gta04 modem plugin based on qtopiaphonemodem framework and this now default. New GTA02 user here, I see the code in neocontrol.cpp pulls the library from http://activationrecord.net/radekp/pub/ I am guessing that at the time it was current. The debian package is now current, so I would expect it to be used instead ? I can't tell what you mean here. Which library / package? Neil I am looking at http://packages.debian.org/sid/armel/fso-gsmd/filelist which contains libfsogsm Looking again, I see the newer versions are in sid and wheezy which radek might not be building qtmoko with. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Adam Ward cay...@internode.on.net writes: On Sat, 22 Sep 2012 10:01:23 AM Neil Jerram wrote: Adam Ward cay...@internode.on.net writes: On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote: On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: As far as I know Qtmoko can use FSO but does not as default. Yes this is correct. My plan was to use FSO for GTA04. But when i got my GTA04, there was no work for this device done in FSO, so i rather added gta04 modem plugin based on qtopiaphonemodem framework and this now default. New GTA02 user here, I see the code in neocontrol.cpp pulls the library from http://activationrecord.net/radekp/pub/ I am guessing that at the time it was current. The debian package is now current, so I would expect it to be used instead ? I can't tell what you mean here. Which library / package? Neil I am looking at http://packages.debian.org/sid/armel/fso-gsmd/filelist which contains libfsogsm Looking again, I see the newer versions are in sid and wheezy which radek might not be building qtmoko with. Ah, thanks, I understand your question now: what version of fsogsmd does QtMoko build with, and isn't that now rather out of date? But I'm afraid I don't know the answers. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Saturday, September 22, 2012 10:44:54 PM Neil Jerram wrote: Ah, thanks, I understand your question now: what version of fsogsmd does QtMoko build with, and isn't that now rather out of date? But I'm afraid I don't know the answers. I was using FSO from git at the time when i was implementing FSO backend. I am quite sure FSO from wheezy will work unless FSO api changed. However for now it makes no sence to use any dbus modem middleware as default. QtMoko's modem library is very stable and works IMO very good. I dont see any benefits in using FSO or oFono right now. But still if you want to use FSO or oFono the support is in every QtMoko installation - just change export QTOPIA_PHONE=oFono or export QTOPIA_PHONE=Fso in /opt/qtmoko/qpe.env and QtMoko will use the dbus backend for telephony. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Mon, 23 Jul 2012 10:29:38 AM Radek Polak wrote: On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: As far as I know Qtmoko can use FSO but does not as default. Yes this is correct. My plan was to use FSO for GTA04. But when i got my GTA04, there was no work for this device done in FSO, so i rather added gta04 modem plugin based on qtopiaphonemodem framework and this now default. New GTA02 user here, I see the code in neocontrol.cpp pulls the library from http://activationrecord.net/radekp/pub/ I am guessing that at the time it was current. The debian package is now current, so I would expect it to be used instead ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Denis 'GNUtoo' Carikli gnu...@no-log.org writes: On Tue, 2012-07-31 at 23:13 +0200, Neil Jerram wrote: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead However I was told that adding support for AGPS and GTA02 UBX would not be straingtforward in gpsd. AGPS is very usefull to save/restore the AGPS data offline in order to speedup the fix. All that works on ogps. Hmm. I should probably concede here because I don't know any of the details or history. Technically, however, I'm surprised if there was no feasible way of doing this with gpsd. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Fri, 2012-08-03 at 16:47 +0200, Neil Jerram wrote: Denis 'GNUtoo' Carikli gnu...@no-log.org writes: On Tue, 2012-07-31 at 23:13 +0200, Neil Jerram wrote: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead However I was told that adding support for AGPS and GTA02 UBX would not be straingtforward in gpsd. AGPS is very usefull to save/restore the AGPS data offline in order to speedup the fix. All that works on ogps. Hmm. I should probably concede here because I don't know any of the details or history. Technically, however, I'm surprised if there was no feasible way of doing this with gpsd. yes there is, I'm trying to use the hooks right now(I already fixed the permissions for doing that). Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On 08/03/2012 05:15 PM, Denis 'GNUtoo' Carikli wrote: On Fri, 2012-08-03 at 16:47 +0200, Neil Jerram wrote: Denis 'GNUtoo' Carikli gnu...@no-log.org writes: On Tue, 2012-07-31 at 23:13 +0200, Neil Jerram wrote: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead However I was told that adding support for AGPS and GTA02 UBX would not be straingtforward in gpsd. AGPS is very usefull to save/restore the AGPS data offline in order to speedup the fix. All that works on ogps. Hmm. I should probably concede here because I don't know any of the details or history. Technically, however, I'm surprised if there was no feasible way of doing this with gpsd. yes there is, I'm trying to use the hooks right now(I already fixed the permissions for doing that). Would you be so kind and point out how to hack A-GPS with gpsd or where to start. I have spend some time and found no way to do this with gpsd. Extra software was always needed. Especialy for heuristics which tells to GPS the current time and position and its precision. Jirka P. Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Enrico Zini enr...@enricozini.org writes: This said, oFono does have one very compelling feature: on my N900, it works reliably. Far better than any version of FSO that I ever managed to put on my FreeRunner ever did. If you think that Nokia's N900 firmware is using oFono, you're wrong. Or do you mean something else? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Tue, 2012-07-31 at 23:13 +0200, Neil Jerram wrote: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead However I was told that adding support for AGPS and GTA02 UBX would not be straingtforward in gpsd. AGPS is very usefull to save/restore the AGPS data offline in order to speedup the fix. All that works on ogps. Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Enrico Zini enr...@enricozini.org writes: What I think is needed now are components that give existing distributions capabilities they didn't have before. Then to see what people develop on top of them. +1 But to be appealing to developers who are new to the system (which basically means, all of them), such componends need to be: few, simple, reliable, stable, easy to deploy, and if not documented, at least coming with some working example code. Should I mention they should also be compilable with the *stable* release of the compiler they need? In the past, and for years, I would even have needed to mention that. I want to believe that at least that has already changed :) 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. 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? Regards, Neil ___ 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: [Shr-Devel] About the future of the freesmartphone.org middleware
Dr. Michael Lauer mic...@vanille-media.de writes: 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. Ah sorry, my mistake. (I thought FSO was written in Vala now.) 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. I agree that there is a difference in scale, but would draw the opposite conclusion. Probably one of the factors in oFono's success is that it concentrates on doing one thing well. I'm not sure any of the non-GSM FSO components have proved themselves yet. I could be seeing things wrong, but to pull out a couple of examples: - GPS: it seems clear now that it was a mistake to pull that under the FSO umbrella, and that mobile devices should just use standard gpsd instead - the Usage API, which I understand to be motivated mostly by power management, is being rendered unnecessary in many cases by the powering on/off being handled automatically in the kernel. 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. But might it be less work overall to address those inferiorities in oFono? Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Am 24.07.2012 11:27, schrieb Thomas Munker: Hi, i thought the ui is saving the volume values where it should (using opreference interface), but fso doesn't pick them up. There's an old bugreport in shr-track [0], that suggests it's fso's fault. Maybe this should be clarified. I've found a new bugreport too... [1] And it's been for some years in the fso-track, too: [2] Ok, will look into this bug reports. With the network-registration, i get alwas an error that this feature is not implemented for my modem. Maybe shr uses to old feeds of fso, i don't know. Hm, you're right. I got it wrong cause looking at the wrong place in the source code :) Sorry for that. I will implement this really soon. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Thanks a lot, you'r the greatest :) Am 24.07.2012 18:17, schrieb Simon Busch: Am 24.07.2012 11:27, schrieb Thomas Munker: Hi, i thought the ui is saving the volume values where it should (using opreference interface), but fso doesn't pick them up. There's an old bugreport in shr-track [0], that suggests it's fso's fault. Maybe this should be clarified. I've found a new bugreport too... [1] And it's been for some years in the fso-track, too: [2] Ok, will look into this bug reports. With the network-registration, i get alwas an error that this feature is not implemented for my modem. Maybe shr uses to old feeds of fso, i don't know. Hm, you're right. I got it wrong cause looking at the wrong place in the source code :) Sorry for that. I will implement this really soon. regards, Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Sunday, July 22, 2012 02:08:39 PM Simon Busch wrote: As far as I know Qtmoko can use FSO but does not as default. Yes this is correct. My plan was to use FSO for GTA04. But when i got my GTA04, there was no work for this device done in FSO, so i rather added gta04 modem plugin based on qtopiaphonemodem framework and this now default. Btw qtmoko has very nice api for different telephony backends - it can currently use also oFono, google talk and voip as backends. It's very easy to use and it's very well documented [1]. Regards Radek [1] http://radekp.github.com/qtmoko/api/qtelephonyservice.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Am 21.07.2012 21:44, schrieb Thamos: Hi all. I've never seen someone using the conference-feature. I think selecting the provider is more important. (this one really annoys me, since i am near an border and simply can't phone until i get out auf alien range, if the phone switched one time, even reboot doesn't help...). I also miss the possibility to choose loudness of the ringtone reasonably. Most other phones are even able to choose a ringtone based of the caller! Ok, this are two things. The first one regarding switching a different provider should be already possible with the org.freesmartphone.GSM.Network API. Just take a look at the API documentation at [0]. You have to differentiate here. FSO efforts are not about the user experience on the UI side. It's just a middleware enables you to implement such things like loudness handling of the ringtone in your user experience. If you are talking about SHR in detail here just request your feature to the SHR developers. regards, Simon [0]: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.Network.html;hb=HEAD#RegisterWithProvider -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Am 22.07.2012 02:24, schrieb Kai Lüke: Hello, I think these all together will be fine. The only thing I have in my mind beside these is something I ever wanted to try but never did: redirecting sound (e.g. a sound file with pause melody or answerphone) to the call input. It depends a lot on the phone you're using if this is possible and it's nothing I really see in the FSO middleware in the next time as there are other feature which are quite more essential. But if you have time and a good idea how to integrate this please speak up. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Am 22.07.2012 03:39, schrieb Pierre Pronchery: Hi Simon, lists, On 21/07/2012 20:45, Simon Busch wrote: as a lot of you may have noticed we did two releases in the past months of the FSO stack. Both were related to bring stability and consistence to the stack. Now I want to talk with you about the future of the stack. [...] Good to hear, thanks for the heads up. For fsogsmd there are the following things on my list: [...] 5. Multi device support: While working in HFP HF support in fsogsmd I discovered that things would be easier if we can control more than one modem with the same daemon at the same time. Think about phone with support for more than one SIM card. Work has already started for this in the morphis/multi-device branch of the cornucopia repository. I fully agree to this, and I have started work to support this in DeforaOS Phone. More specifically, my goal is to be able to support (and integrate) an AT-based modem together with VoIP account(s), Instant Messaging and so on. To help me with this task I am using libpurple (from Pidgin) and sofia-sip (for SIP, obviously). Ok, we're talking here about two different things. My effort for multi device support in fsogsmd is a a step before what you describe. It's not about using VoIP and a AT based modem together. Think about situations where you have more than one modem (and really a modem) to control like in a phone with more than one SIM card or on a laptop where you have a phone connected via HFP HF and a UMTS stick for your data connection. Controlling VoIP and a modem together with the same API is definitely nothing we should do in fsogsmd itself but in telepathy or a fsophoned. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Simon Busch morp...@gravedo.de writes: I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? All of the details you've described sound to me like excellent and compelling things to work on. But your wider problem is that you're working in a vacuum, because there's no reasonably widely used phone distribution that uses FSO and that is also regularly and safely updated. That means you have no users for your incremental improvements. Obviously there's SHR, but from what I see on the mailing lists it seems to me that the development edge of SHR is a complete basket case: constantly broken and regressing in very basic functionality. I think you either need to change SHR's approach, or to find/create another compelling distribution (perhaps around Aurora) that uses FSO; otherwise all your planned improvements won't help anyone. I'm sorry to be so negative and unconstructive here, but it seems clear to me that SHR is your elephant in the room, and I don't think you should ignore that. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Am 22.07.2012 12:03, schrieb Neil Jerram: All of the details you've described sound to me like excellent and compelling things to work on. But your wider problem is that you're working in a vacuum, because there's no reasonably widely used phone distribution that uses FSO and that is also regularly and safely updated. That means you have no users for your incremental improvements. Obviously there's SHR, but from what I see on the mailing lists it seems to me that the development edge of SHR is a complete basket case: constantly broken and regressing in very basic functionality. I think you either need to change SHR's approach, or to find/create another compelling distribution (perhaps around Aurora) that uses FSO; otherwise all your planned improvements won't help anyone. I'm sorry to be so negative and unconstructive here, but it seems clear to me that SHR is your elephant in the room, and I don't think you should ignore that. You find excellent words to describe the current state our efforts to have a completely open sourced mobile telephony stack. There is no real development on the upper layers. I tried to get into this for a long time (remember mickeyl and I started aurora back in 2011) but came to the point that I don't have the time to do the real big thing anymore. It's frustrating to have nothing you can really use with the software you wrote. But finally I came to the point that I have fun developing just FSO and get everything into shape so others can pick up. I indicated already some months ago that I don't want to focus on a specific device anymore but just FSO and get it available in a good and stable state where possible. So if anyone has fun to pick up my work with FSO on a higher level just do. I will continue to develop the middleware in my spare free time and hope it's going into the right direction. Any btw. it must no be everytime suitable for a device like a phone. I started implementing HFP HF as I like the idea to have my phone lying next to my laptop while working a get a indication when a phone call comes in on my laptop where I can then answer the call directly without putting my fingers on the phone. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Am Sonntag, 22. Juli 2012, 12:03:38 schrieb Neil Jerram: But your wider problem is that you're working in a vacuum, because there's no reasonably widely used phone distribution that uses FSO and that is also regularly and safely updated. That means you have no users for your incremental improvements. I think that's not true. There are users outside distributions using FSO for own applications, like me. Big thanks to Simon (and Mickey) Rico signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
On Sun, Jul 22, 2012 at 3:33 PM, Neil Jerram n...@ossau.homelinux.netwrote: Simon Busch morp...@gravedo.de writes: I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? All of the details you've described sound to me like excellent and compelling things to work on. But your wider problem is that you're working in a vacuum, because there's no reasonably widely used phone distribution that uses FSO and that is also regularly and safely updated. That means you have no users for your incremental improvements. Does QTMoko not use FSO now? If yet then Radek has a pretty usable upper layer out there now where end users can try out the improvements in FSO. Rakshat ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] About the future of the freesmartphone.org middleware
Am 22.07.2012 13:52, schrieb rakshat hooja: On Sun, Jul 22, 2012 at 3:33 PM, Neil Jerram n...@ossau.homelinux.netwrote: Simon Busch morp...@gravedo.de writes: I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? All of the details you've described sound to me like excellent and compelling things to work on. But your wider problem is that you're working in a vacuum, because there's no reasonably widely used phone distribution that uses FSO and that is also regularly and safely updated. That means you have no users for your incremental improvements. Does QTMoko not use FSO now? If yet then Radek has a pretty usable upper layer out there now where end users can try out the improvements in FSO. As far as I know Qtmoko can use FSO but does not as default. regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
About the future of the freesmartphone.org middleware
Hey everybody, as a lot of you may have noticed we did two releases in the past months of the FSO stack. Both were related to bring stability and consistence to the stack. Now I want to talk with you about the future of the stack. In the past we were only concentrating on getting new hardware supported and lost our real focus on creating a middleware suitable for embedded/specific-purpose devices. This is where I want to go back to and get into development again. In the last weeks I looked over several parts we have in our stack and tried to find out where we can improve and get into development of new features again. A lot of you have stability in mind as you want to use something with FSO on your daily phone. Thats the second peace which should be part of the core development focus of the Freesmartphone.org middleware. Getting new features is fast said but I have several things on my list where I want to improve FSO in the next weeks and months. Everything is focused on the core stack which is formed by our framework libraries and the three daemons fsodeviced, fsogsmd and fsousaged. We have other daemons like fsotdld as well but that will be not on my focus. If someone wants to step up with further development of these just go on and get in contact. But please don't get me wrong: I will support all other daemons like fsoaudiod and fsotdld in the next releases too but just not doing any development related work for them. For fsogsmd there are the following things on my list: 1. Get the last peaces of not implemented things in like conference or emergency calls 2. Several API cleanups 3. Get several bugs fixed 4. Do integration testing with a remote controlled phonesim so we can simulate incoming calls etc. This will also included integration testing with a remote controlled fsogsmd on another device 5. Multi device support: While working in HFP HF support in fsogsmd I discovered that things would be easier if we can control more than one modem with the same daemon at the same time. Think about phone with support for more than one SIM card. Work has already started for this in the morphis/multi-device branch of the cornucopia repository. 6. Cleanup of the modem status handling: right now the modem status and SIM/network status are too much tight together. We have cleanly separate them. 7. Internally we don't separate a modem from a AT based modem; that needs to be fixed 8. A lock-down mechanism to keep anyone out when doing a firmware upgrade. When doing a firmware upgrade of a modem we have the problem that nobody should access the modem while this is in progress. The idea is now to implement a dbus API to lock the modem by requesting a lock and only the requesting program can unlock the modem again. While the modem is locked nobody else can access the modem via fsogsmd. fsousaged: - nothing right now fsodeviced: - nothing right now lib*: - I am thinking about grouping all libraries together so just have one single framework library and don't need to maintain several small libraries which increases the complexity of release testing, ABI refinements, etc. Just one libfsoframework; this is only a thought in my head right and nothing concrete. That are some of my toughs were I want to go with FSO in the next months. So no focus on concrete devices but getting the stack itself forward to be ready for every kind of a device. I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? regards, Simon -- Simon Busch - http://mm.gravedo.de/blog/ ___ 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 all. I've never seen someone using the conference-feature. I think selecting the provider is more important. (this one really annoys me, since i am near an border and simply can't phone until i get out auf alien range, if the phone switched one time, even reboot doesn't help...). I also miss the possibility to choose loudness of the ringtone reasonably. Most other phones are even able to choose a ringtone based of the caller! Apart from that i comply with you. kind regards, Thamos Am 21.07.2012 20:45, schrieb Simon Busch: Hey everybody, as a lot of you may have noticed we did two releases in the past months of the FSO stack. Both were related to bring stability and consistence to the stack. Now I want to talk with you about the future of the stack. In the past we were only concentrating on getting new hardware supported and lost our real focus on creating a middleware suitable for embedded/specific-purpose devices. This is where I want to go back to and get into development again. In the last weeks I looked over several parts we have in our stack and tried to find out where we can improve and get into development of new features again. A lot of you have stability in mind as you want to use something with FSO on your daily phone. Thats the second peace which should be part of the core development focus of the Freesmartphone.org middleware. Getting new features is fast said but I have several things on my list where I want to improve FSO in the next weeks and months. Everything is focused on the core stack which is formed by our framework libraries and the three daemons fsodeviced, fsogsmd and fsousaged. We have other daemons like fsotdld as well but that will be not on my focus. If someone wants to step up with further development of these just go on and get in contact. But please don't get me wrong: I will support all other daemons like fsoaudiod and fsotdld in the next releases too but just not doing any development related work for them. For fsogsmd there are the following things on my list: 1. Get the last peaces of not implemented things in like conference or emergency calls 2. Several API cleanups 3. Get several bugs fixed 4. Do integration testing with a remote controlled phonesim so we can simulate incoming calls etc. This will also included integration testing with a remote controlled fsogsmd on another device 5. Multi device support: While working in HFP HF support in fsogsmd I discovered that things would be easier if we can control more than one modem with the same daemon at the same time. Think about phone with support for more than one SIM card. Work has already started for this in the morphis/multi-device branch of the cornucopia repository. 6. Cleanup of the modem status handling: right now the modem status and SIM/network status are too much tight together. We have cleanly separate them. 7. Internally we don't separate a modem from a AT based modem; that needs to be fixed 8. A lock-down mechanism to keep anyone out when doing a firmware upgrade. When doing a firmware upgrade of a modem we have the problem that nobody should access the modem while this is in progress. The idea is now to implement a dbus API to lock the modem by requesting a lock and only the requesting program can unlock the modem again. While the modem is locked nobody else can access the modem via fsogsmd. fsousaged: - nothing right now fsodeviced: - nothing right now lib*: - I am thinking about grouping all libraries together so just have one single framework library and don't need to maintain several small libraries which increases the complexity of release testing, ABI refinements, etc. Just one libfsoframework; this is only a thought in my head right and nothing concrete. That are some of my toughs were I want to go with FSO in the next months. So no focus on concrete devices but getting the stack itself forward to be ready for every kind of a device. I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? regards, Simon ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: About the future of the freesmartphone.org middleware
Hello, I think these all together will be fine. The only thing I have in my mind beside these is something I ever wanted to try but never did: redirecting sound (e.g. a sound file with pause melody or answerphone) to the call input. But just an idea, thanks! Kai Am 21.07.2012 21:44, schrieb Thamos: Hi all. I've never seen someone using the conference-feature. I think selecting the provider is more important. (this one really annoys me, since i am near an border and simply can't phone until i get out auf alien range, if the phone switched one time, even reboot doesn't help...). I also miss the possibility to choose loudness of the ringtone reasonably. Most other phones are even able to choose a ringtone based of the caller! Apart from that i comply with you. kind regards, Thamos Am 21.07.2012 20:45, schrieb Simon Busch: Hey everybody, as a lot of you may have noticed we did two releases in the past months of the FSO stack. Both were related to bring stability and consistence to the stack. Now I want to talk with you about the future of the stack. In the past we were only concentrating on getting new hardware supported and lost our real focus on creating a middleware suitable for embedded/specific-purpose devices. This is where I want to go back to and get into development again. In the last weeks I looked over several parts we have in our stack and tried to find out where we can improve and get into development of new features again. A lot of you have stability in mind as you want to use something with FSO on your daily phone. Thats the second peace which should be part of the core development focus of the Freesmartphone.org middleware. Getting new features is fast said but I have several things on my list where I want to improve FSO in the next weeks and months. Everything is focused on the core stack which is formed by our framework libraries and the three daemons fsodeviced, fsogsmd and fsousaged. We have other daemons like fsotdld as well but that will be not on my focus. If someone wants to step up with further development of these just go on and get in contact. But please don't get me wrong: I will support all other daemons like fsoaudiod and fsotdld in the next releases too but just not doing any development related work for them. For fsogsmd there are the following things on my list: 1. Get the last peaces of not implemented things in like conference or emergency calls 2. Several API cleanups 3. Get several bugs fixed 4. Do integration testing with a remote controlled phonesim so we can simulate incoming calls etc. This will also included integration testing with a remote controlled fsogsmd on another device 5. Multi device support: While working in HFP HF support in fsogsmd I discovered that things would be easier if we can control more than one modem with the same daemon at the same time. Think about phone with support for more than one SIM card. Work has already started for this in the morphis/multi-device branch of the cornucopia repository. 6. Cleanup of the modem status handling: right now the modem status and SIM/network status are too much tight together. We have cleanly separate them. 7. Internally we don't separate a modem from a AT based modem; that needs to be fixed 8. A lock-down mechanism to keep anyone out when doing a firmware upgrade. When doing a firmware upgrade of a modem we have the problem that nobody should access the modem while this is in progress. The idea is now to implement a dbus API to lock the modem by requesting a lock and only the requesting program can unlock the modem again. While the modem is locked nobody else can access the modem via fsogsmd. fsousaged: - nothing right now fsodeviced: - nothing right now lib*: - I am thinking about grouping all libraries together so just have one single framework library and don't need to maintain several small libraries which increases the complexity of release testing, ABI refinements, etc. Just one libfsoframework; this is only a thought in my head right and nothing concrete. That are some of my toughs were I want to go with FSO in the next months. So no focus on concrete devices but getting the stack itself forward to be ready for every kind of a device. I would be really happy to hear what other people are thinking about the idea behind FSO since it was started back in 2008. What are your missing features? What do you like and what not? regards, Simon ___ 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
