Re: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-09-23 Thread Adam Ward
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

2012-09-22 Thread Neil Jerram
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

2012-09-22 Thread Adam Ward
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

2012-09-22 Thread Neil Jerram
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

2012-09-22 Thread Radek Polak
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

2012-09-21 Thread Adam Ward
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

2012-08-03 Thread Neil Jerram
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

2012-08-03 Thread Denis 'GNUtoo' Carikli
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

2012-08-03 Thread Jiří Pinkava

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: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-08-01 Thread Denis 'GNUtoo' Carikli
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: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-07-31 Thread Neil Jerram
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: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-07-23 Thread Radek Polak
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: [Shr-Devel] About the future of the freesmartphone.org middleware

2012-07-22 Thread Neil Jerram
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

2012-07-22 Thread Simon Busch

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

2012-07-22 Thread Rico Rommel
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

2012-07-22 Thread 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.

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

2012-07-22 Thread Simon Busch

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