Palm Pre modem plugin

Palm Pre modem plugin

[morphis]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]


Hey,

I saw you added some time ago support for the Palm Pre MSM Modem. I am
working 
on the FSO (http://www.freesmartphone.org/) side to support this kind of
MSM 
modem as well. I am are currently stucked with the binary protocol spoken 
between modem and userland in webOS.

The Problem why we do this is the following: As I and some other people
find out, 
there is no support on the data channel (the one you use in oFono to speak

plain AT with the modem) for unsolicited responses.

So the only option is to support the binary protocol to get minimally the 
response from the modem when for example a call arrives.

So my question is: How do you want to manage this with your plugin for the

Palm Pre modem? Do you even plan to use the serial interface on the 
/dev/modemuart port? 

regards,
morphis

Re: Palm Pre modem plugin

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

Hi Niko,

>As of that I'm able to imagine only few reasons to use ofono instead of fso.

Then either you're not thinking hard enough or do not have enough domain 
experience to really comment.  One example: carrier certification. Please 
examine what oFono APIs cover and what FSO GSM APIs cover.  Hint, to pass GCF 
certification you will require quite a bit of what oFono provides (or figures 
out for you) and FSO is currently missing.

>The forth and worring is that a developer may be forced to use
>ofono, as the target device has some closed parts necessary for the os
>that does not work anymore if you remove ofono and use FSO.

Please do not post these crazy conspiracy theories here.  oFono is GPLed for 
exactly this reason.

> So, instead of discuss oFono vs FSO, I'd like to know what is the long
> time strategy and how to address these issues, and of course if I
> missed some important points.

FSO vs oFono is not a fair comparison anyway.    Please keep in mind that 
oFono is focused _only_ on being a telephony stack that is generic and 
applicable to all types of devices.  We started oFono to enable telephony 
applications on Laptops, Netbooks, MIDs, In-Vehicle Infotainment and many 
other types of devices.  These system types are different enough that different 
approaches to resource management, PIM, etc might be required.  Not every 
device type will have or even needs a fully-featured GSM modem.

For this reason oFono does not distinguish between smartphone vs non-
smartphone use cases.  Case in point: oFono already supports data-only GPRS 
devices, Bluetooth Handsfree profile devices, and of course proper modems (AT 
command and binary-protocol.)  

The other long-term goal is to integrate oFono with other system-level daemons 
such as BlueZ, NTPD, ConnMan, NetworkManager Gypsy, etc.  This will allow us 
to e.g. expose GPS data from the modem; enable Bluetooth telephony profiles 
like DUN, HFP AG; and expose 3G data connections for management by real 
connection managers.  We already have integration plugin infrastructure for 
feeding call history, sms history information to a PIM database of your 
choice, as well as export your phone's phonebooks to VCard format.

So, as you see, oFono allows you to integrate it into any type of system.  You 
can even make it coexist with FSO daemons (with the exception of the gsm one 
of course) if these satisfy your particular requirements.

Regards,
-Denis

Re: Palm Pre modem plugin

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]

Hi,

2009/11/20  <morphis@gravedo.de>:
> The Problem why we do this is the following: As I and some other people
> find out,
> there is no support on the data channel (the one you use in oFono to speak
> plain AT with the modem) for unsolicited responses.
>
> So the only option is to support the binary protocol to get minimally the
> response from the modem when for example a call arrives.
>
> So my question is: How do you want to manage this with your plugin for the
> Palm Pre modem? Do you even plan to use the serial interface on the
> /dev/modemuart port?

We plan to use this port when enough is known about the protocol the
modem firmware speaks on it that it can be used reliably.  I don't
have any specification for that protocol or the current firmware
sources so I can't modify it, or the WebOS telephony daemon sources.

Personally I've looked at the binary protocol and added some of my
findings to this page:
http://www.webos-internals.org/wiki/Research_Pre_GSM_Modem_Protocol ,
for that I modified the kernel to cache all the ttyS0 communication
from the start, later communication can be inspected with strace or by
renaming the /dev node to something else and providing a pty.
Do you have a fuller description of the protocol?  It doesn't seem
there's much work on it done at webos-internals for the last couple of
weeks.

The ofono plugin is experimental, but some unsolicited responses are
available on the AT port, like incoming SMS.  I've not checked
incoming voice calls yet, outgoing calls worked fine in my test.

Regards

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

Hi Morphis,

> I saw you added some time ago support for the Palm Pre MSM Modem. I am
> working 
> on the FSO (http://www.freesmartphone.org/) side to support this kind of
> MSM 
> modem as well. I am are currently stucked with the binary protocol spoken 
> between modem and userland in webOS.
> 
> The Problem why we do this is the following: As I and some other people
> find out, 
> there is no support on the data channel (the one you use in oFono to speak
> 
> plain AT with the modem) for unsolicited responses.
> 
> So the only option is to support the binary protocol to get minimally the 
> response from the modem when for example a call arrives.
> 
> So my question is: How do you want to manage this with your plugin for the
> 
> Palm Pre modem? Do you even plan to use the serial interface on the 
> /dev/modemuart port? 

I expect that at some point someone does a MSM plugin that talks this
binary protocol and it will work with more Qualcomm based devices than
the Palm Pre. We will see. However any patches are more than welcome.

Regards

Marcel

Re: Palm Pre modem plugin

[morphis]

[-- Attachment #1: Type: text/plain, Size: 3239 bytes --]

On Fri, Nov 20, 2009 at 02:17:06PM +0100, andrzej zaborowski wrote:
> Hi,
> 
> 2009/11/20  <morphis@gravedo.de>:
> > The Problem why we do this is the following: As I and some other people
> > find out,
> > there is no support on the data channel (the one you use in oFono to speak
> > plain AT with the modem) for unsolicited responses.
> >
> > So the only option is to support the binary protocol to get minimally the
> > response from the modem when for example a call arrives.
> >
> > So my question is: How do you want to manage this with your plugin for the
> > Palm Pre modem? Do you even plan to use the serial interface on the
> > /dev/modemuart port?
> 
> We plan to use this port when enough is known about the protocol the
> modem firmware speaks on it that it can be used reliably.  I don't
> have any specification for that protocol or the current firmware
> sources so I can't modify it, or the WebOS telephony daemon sources.

Ok. I don't think anyone else has the plain sources of the telephony
daemon, but if anyone have, please tell :D

> Personally I've looked at the binary protocol and added some of my
> findings to this page:
> http://www.webos-internals.org/wiki/Research_Pre_GSM_Modem_Protocol ,
> for that I modified the kernel to cache all the ttyS0 communication
> from the start, later communication can be inspected with strace or by
> renaming the /dev node to something else and providing a pty.
> Do you have a fuller description of the protocol?  It doesn't seem
> there's much work on it done at webos-internals for the last couple of
> weeks.

You are right, I don't published very much informations about my
research the last time. I am currently working on the implementation of
the basics I found out about the protocol. I split the whole code into
two projects: msmcommd and libmsmcomm. msmcommd is a daemon which does
all the link layer protocol handling which is required to speak probably
with the modem. The library libmsmcomm is an easy utilitiy to format
the different messages type and decode them on receive. 

The link layer part is nearly done. Establishment of a link should work
and on the handling of sending and receiving data I am currently
working.

When libmsmcomm and msmcommd are done I have the plan to open from
fsogsmd a network channel to msmcommd and send all my telephony commands
to msmcommd whichs put them into link layer frames and sends them to the
modem. 

The big part which is mostly undone at the moment, is the one how the
real messages are decoded. My current informations are that commands are
even as small as the AT ones. So you have one for getting the imei, one 
for starting a call and so on. 

> 
> The ofono plugin is experimental, but some unsolicited responses are
> available on the AT port, like incoming SMS.  I've not checked
> incoming voice calls yet, outgoing calls worked fine in my test.

Hm ok. That maybe opens us the way to do most things with AT commands
and only a little subset like power management with the binary protocol.

> Regards
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Palm Pre modem plugin

[morphis]

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Fri, Nov 20, 2009 at 02:28:19PM +0100, Marcel Holtmann wrote:
> Hi Morphis,
> 
> > I saw you added some time ago support for the Palm Pre MSM Modem. I am
> > working 
> > on the FSO (http://www.freesmartphone.org/) side to support this kind of
> > MSM 
> > modem as well. I am are currently stucked with the binary protocol spoken 
> > between modem and userland in webOS.
> > 
> > The Problem why we do this is the following: As I and some other people
> > find out, 
> > there is no support on the data channel (the one you use in oFono to speak
> > 
> > plain AT with the modem) for unsolicited responses.
> > 
> > So the only option is to support the binary protocol to get minimally the 
> > response from the modem when for example a call arrives.
> > 
> > So my question is: How do you want to manage this with your plugin for the
> > 
> > Palm Pre modem? Do you even plan to use the serial interface on the 
> > /dev/modemuart port? 
> 
> I expect that at some point someone does a MSM plugin that talks this
> binary protocol and it will work with more Qualcomm based devices than
> the Palm Pre. We will see. However any patches are more than welcome.

No patches from me for oFono as I am a FSO fan boy :) 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

Hi Morphis,

> > > I saw you added some time ago support for the Palm Pre MSM Modem. I am
> > > working 
> > > on the FSO (http://www.freesmartphone.org/) side to support this kind of
> > > MSM 
> > > modem as well. I am are currently stucked with the binary protocol spoken 
> > > between modem and userland in webOS.
> > > 
> > > The Problem why we do this is the following: As I and some other people
> > > find out, 
> > > there is no support on the data channel (the one you use in oFono to speak
> > > 
> > > plain AT with the modem) for unsolicited responses.
> > > 
> > > So the only option is to support the binary protocol to get minimally the 
> > > response from the modem when for example a call arrives.
> > > 
> > > So my question is: How do you want to manage this with your plugin for the
> > > 
> > > Palm Pre modem? Do you even plan to use the serial interface on the 
> > > /dev/modemuart port? 
> > 
> > I expect that at some point someone does a MSM plugin that talks this
> > binary protocol and it will work with more Qualcomm based devices than
> > the Palm Pre. We will see. However any patches are more than welcome.
> 
> No patches from me for oFono as I am a FSO fan boy :) 

I think we need to convert you :)

To be honest it would be way simpler for you to write a MSM plugin for
oFono since it is actually designed to support binary protocols like the
Nokia Phonet in the first place.

Regards

Marcel

Re: Palm Pre modem plugin

[morphis]

[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]

On Sat, Nov 21, 2009 at 11:33:24AM +0100, Marcel Holtmann wrote:
> Hi Morphis,
> 
> > > > I saw you added some time ago support for the Palm Pre MSM Modem. I am
> > > > working 
> > > > on the FSO (http://www.freesmartphone.org/) side to support this kind of
> > > > MSM 
> > > > modem as well. I am are currently stucked with the binary protocol spoken 
> > > > between modem and userland in webOS.
> > > > 
> > > > The Problem why we do this is the following: As I and some other people
> > > > find out, 
> > > > there is no support on the data channel (the one you use in oFono to speak
> > > > 
> > > > plain AT with the modem) for unsolicited responses.
> > > > 
> > > > So the only option is to support the binary protocol to get minimally the 
> > > > response from the modem when for example a call arrives.
> > > > 
> > > > So my question is: How do you want to manage this with your plugin for the
> > > > 
> > > > Palm Pre modem? Do you even plan to use the serial interface on the 
> > > > /dev/modemuart port? 
> > > 
> > > I expect that at some point someone does a MSM plugin that talks this
> > > binary protocol and it will work with more Qualcomm based devices than
> > > the Palm Pre. We will see. However any patches are more than welcome.
> > 
> > No patches from me for oFono as I am a FSO fan boy :) 
> 
> I think we need to convert you :)

You can try but I think it's currently impossible :)

> 
> To be honest it would be way simpler for you to write a MSM plugin for
> oFono since it is actually designed to support binary protocols like the
> Nokia Phonet in the first place.

What do mean with that? If I look at fsogsmd (the vala implementation of
the fso gsm daemon) it's even abstracted so I can easily implement a
binary protocol as we found in the Palm Pre modem.

> 
> Regards
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2639 bytes --]

Hi Morphis,

> > > > > I saw you added some time ago support for the Palm Pre MSM Modem. I am
> > > > > working 
> > > > > on the FSO (http://www.freesmartphone.org/) side to support this kind of
> > > > > MSM 
> > > > > modem as well. I am are currently stucked with the binary protocol spoken 
> > > > > between modem and userland in webOS.
> > > > > 
> > > > > The Problem why we do this is the following: As I and some other people
> > > > > find out, 
> > > > > there is no support on the data channel (the one you use in oFono to speak
> > > > > 
> > > > > plain AT with the modem) for unsolicited responses.
> > > > > 
> > > > > So the only option is to support the binary protocol to get minimally the 
> > > > > response from the modem when for example a call arrives.
> > > > > 
> > > > > So my question is: How do you want to manage this with your plugin for the
> > > > > 
> > > > > Palm Pre modem? Do you even plan to use the serial interface on the 
> > > > > /dev/modemuart port? 
> > > > 
> > > > I expect that at some point someone does a MSM plugin that talks this
> > > > binary protocol and it will work with more Qualcomm based devices than
> > > > the Palm Pre. We will see. However any patches are more than welcome.
> > > 
> > > No patches from me for oFono as I am a FSO fan boy :) 
> > 
> > I think we need to convert you :)
> 
> You can try but I think it's currently impossible :)

for oFono we have a pretty much brought spectrum and if the Qualcomm
GOBI cards use a similar protocol to what we find in the Palm Pre, then
you might wanna actually consider going for oFono. Since we will be
pushing oFono as the main telephony stack for desktops, laptops and
netbooks. Using it on actual mobile phones is just a side product.

And I did see FSO using the SMS PDU engine from oFono already, so you
might switch over ;)

> > To be honest it would be way simpler for you to write a MSM plugin for
> > oFono since it is actually designed to support binary protocols like the
> > Nokia Phonet in the first place.
> 
> What do mean with that? If I look at fsogsmd (the vala implementation of
> the fso gsm daemon) it's even abstracted so I can easily implement a
> binary protocol as we found in the Palm Pre modem.

If you wanna go for FSO, then by all means go for it. If they finally
have a proper abstraction layer then all the better. With all the weird
integration work we have done so far, we are pretty happy with our
current design and have the flexibility we need and it worked out better
for us than we ever dreamed it would.

Regards

Marcel

Re: Palm Pre modem plugin

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

2009/11/21  <morphis@gravedo.de>:
> I am currently working on the implementation of
> the basics I found out about the protocol. I split the whole code into
> two projects: msmcommd and libmsmcomm. msmcommd is a daemon which does
> all the link layer protocol handling which is required to speak probably
> with the modem. The library libmsmcomm is an easy utilitiy to format
> the different messages type and decode them on receive.
>
> The link layer part is nearly done. Establishment of a link should work
> and on the handling of sending and receiving data I am currently
> working.
>
> When libmsmcomm and msmcommd are done I have the plan to open from
> fsogsmd a network channel to msmcommd and send all my telephony commands
> to msmcommd whichs put them into link layer frames and sends them to the
> modem.

I like the idea of libmsmcomm as a library, this means it may be easy
in the future to make an oFono plugin linked against the library.  I
don't think having a separate daemon and another communication channel
between what is eventually a dialer or sms app, and the modem is such
a good idea (with the D-Bus socket, D-Bus daemon, FSO and serial
driver already there)

Regards

Re: Palm Pre modem plugin

[Nicola Mfb]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

Hi!
FSO is not only ogsmd, but manages resource handling to save power,
alsa state change for audio routing, networking, hardware led (lights,
vibration), suspending resume, rtc wakeup alarms, pim contacts, music
playing and so on, it's a full featured framework to abstract the
entire smartphone with a nice api.

For that reason it attracts a lot of api consumers that have the
possibility to write code and having it running on all FSO supported
devices without going at a low level to achieve specific machine
tasks.

Add the fact that there are entire linux distros already carrying of
FSO and a lot of application FSO based, (openembedded derived, gentoo,
debian etc.)

As of that I'm able to imagine only few reasons to use ofono instead of fso.
The first may be is ofono may implement some important missing
features, but is nosense becouse is open, so FSO may pickup what they
need (and the contrary).
The second may be that many peoples were bored by the python
implementation, but now FSO2 is going further with vala resulting in c
speed, so this may be minimal.
The third is to experiment, we for example are coding a wrapper daemon
to use oFono or FSO, or oFono and FSO (with the gsmd module disabled).
The forth and worring is that a developer may be *forced* to use
ofono, as the target device has some closed parts necessary for the os
that does not work anymore if you remove ofono and use FSO.

So, instead of discuss oFono vs FSO, I'd like to know what is the long
time strategy and how to address these issues, and of course if I
missed some important points.

Best Regards.

      Niko

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

Hi Andrzej,

> > I am currently working on the implementation of
> > the basics I found out about the protocol. I split the whole code into
> > two projects: msmcommd and libmsmcomm. msmcommd is a daemon which does
> > all the link layer protocol handling which is required to speak probably
> > with the modem. The library libmsmcomm is an easy utilitiy to format
> > the different messages type and decode them on receive.
> >
> > The link layer part is nearly done. Establishment of a link should work
> > and on the handling of sending and receiving data I am currently
> > working.
> >
> > When libmsmcomm and msmcommd are done I have the plan to open from
> > fsogsmd a network channel to msmcommd and send all my telephony commands
> > to msmcommd whichs put them into link layer frames and sends them to the
> > modem.
> 
> I like the idea of libmsmcomm as a library, this means it may be easy
> in the future to make an oFono plugin linked against the library.  I
> don't think having a separate daemon and another communication channel
> between what is eventually a dialer or sms app, and the modem is such
> a good idea (with the D-Bus socket, D-Bus daemon, FSO and serial
> driver already there)

I do think that a native integration directly into the oFono source code
as msmmodem might be better. However the second daemon solution is
stupid and causes too much overhead.

Also I did look into the QMI stuff a little bit and I think we might
have to actually create a QMI subsystem in the Linux kernel like we have
for Phonet since with USB the network interface and the management
interface do share endpoints as far as I can tell so far.

Regards

Marcel

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]

Hi guys,

> >The forth and worring is that a developer may be forced to use
> >ofono, as the target device has some closed parts necessary for the os
> >that does not work anymore if you remove ofono and use FSO.
> 
> Please do not post these crazy conspiracy theories here.  oFono is GPLed for 
> exactly this reason.

let me point this out once again. oFono is 100% GPL source code and this
means that all plugins, drivers or extensions have to be released under
GPL. This was our first and important item when creating oFono. We want
a full open source telephony stack. No binary code running inside the
daemon ever.

Seems like everybody assumes that a GSM telephony system needs to have
closed source components, but on the host CPU, we disagree with this and
strongly enforce open source.

We only draw the line with the UI elements like dialer etc. These are
components that involve branding, customization and differentiation of
products and since they talk via D-Bus they can be closed source. And to
keep the complexity in the UI components minimal we handle all the
details in the daemon.

Regards

Marcel

Re: Palm Pre modem plugin

[Nicola Mfb]

[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]

On Fri, Nov 20, 2009 at 2:08 PM, Denis Kenzior <denkenz@gmail.com> wrote:
[...]
> Then either you're not thinking hard enough or do not have enough domain
> experience to really comment.  One example: carrier certification. Please
> examine what oFono APIs cover and what FSO GSM APIs cover.  Hint, to pass GCF
> certification you will require quite a bit of what oFono provides (or figures
> out for you) and FSO is currently missing.

I cannot comment about FSO objectives but will forward to the right guys.
Keep in mind I'm speaking about general developers and their interest,
not about organizations, just pointing that *actually* FSO carries
more interests on *some* areas.

>>The forth and worring is that a developer may be forced to use
>>ofono, as the target device has some closed parts necessary for the os
>>that does not work anymore if you remove ofono and use FSO.
>
> Please do not post these crazy conspiracy theories here.  oFono is GPLed for
> exactly this reason.

May you elaborate about that? May not a close source project use oFono
by calling it's DBus API?

>> So, instead of discuss oFono vs FSO, I'd like to know what is the long
>> time strategy and how to address these issues, and of course if I
>> missed some important points.
>
> FSO vs oFono is not a fair comparison anyway.    Please keep in mind that
> oFono is focused _only_ on being a telephony stack that is generic and
> applicable to all types of devices.  We started oFono to enable telephony
> applications on Laptops, Netbooks, MIDs, In-Vehicle Infotainment and many
> other types of devices.  These system types are different enough that different
> approaches to resource management, PIM, etc might be required.  Not every
> device type will have or even needs a fully-featured GSM modem.

That's one of the reason FSO is modularized. Anyway resource
management in a complex system has to be handled in a central way to
take coherency between subsytems.
Having a middleware doing that is really important, just a case about
the correct way to suspend/resume a device should be not the interest
of a high level software.

[...]
> The other long-term goal is to integrate oFono with other system-level daemons
> such as BlueZ, NTPD, ConnMan, NetworkManager Gypsy, etc.  This will allow us
> to e.g. expose GPS data from the modem; enable Bluetooth telephony profiles
> like DUN, HFP AG; and expose 3G data connections for management by real
> connection managers.  We already have integration plugin infrastructure for
> feeding call history, sms history information to a PIM database of your
> choice, as well as export your phone's phonebooks to VCard format.
>
> So, as you see, oFono allows you to integrate it into any type of system.  You
> can even make it coexist with FSO daemons (with the exception of the gsm one
> of course) if these satisfy your particular requirements.

Nice to hear that. Anyway do not missunderstand, our team is adopting
oFono, we are just digging incoming issues with the nogsm part
integration!!!

Regards

      Niko

Re: Palm Pre modem plugin

[morphis]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

On Sun, Nov 22, 2009 at 03:21:27PM +0100, Marcel Holtmann wrote:
> Hi Andrzej,
> 
> > > I am currently working on the implementation of
> > > the basics I found out about the protocol. I split the whole code into
> > > two projects: msmcommd and libmsmcomm. msmcommd is a daemon which does
> > > all the link layer protocol handling which is required to speak probably
> > > with the modem. The library libmsmcomm is an easy utilitiy to format
> > > the different messages type and decode them on receive.
> > >
> > > The link layer part is nearly done. Establishment of a link should work
> > > and on the handling of sending and receiving data I am currently
> > > working.
> > >
> > > When libmsmcomm and msmcommd are done I have the plan to open from
> > > fsogsmd a network channel to msmcommd and send all my telephony commands
> > > to msmcommd whichs put them into link layer frames and sends them to the
> > > modem.
> > 
> > I like the idea of libmsmcomm as a library, this means it may be easy
> > in the future to make an oFono plugin linked against the library.  I
> > don't think having a separate daemon and another communication channel
> > between what is eventually a dialer or sms app, and the modem is such
> > a good idea (with the D-Bus socket, D-Bus daemon, FSO and serial
> > driver already there)
> 
> I do think that a native integration directly into the oFono source code
> as msmmodem might be better. However the second daemon solution is
> stupid and causes too much overhead.
> 
> Also I did look into the QMI stuff a little bit and I think we might
> have to actually create a QMI subsystem in the Linux kernel like we have
> for Phonet since with USB the network interface and the management
> interface do share endpoints as far as I can tell so far.

Whats QMI? Never heard about it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2337 bytes --]

Hi Morphis,

> > > > I am currently working on the implementation of
> > > > the basics I found out about the protocol. I split the whole code into
> > > > two projects: msmcommd and libmsmcomm. msmcommd is a daemon which does
> > > > all the link layer protocol handling which is required to speak probably
> > > > with the modem. The library libmsmcomm is an easy utilitiy to format
> > > > the different messages type and decode them on receive.
> > > >
> > > > The link layer part is nearly done. Establishment of a link should work
> > > > and on the handling of sending and receiving data I am currently
> > > > working.
> > > >
> > > > When libmsmcomm and msmcommd are done I have the plan to open from
> > > > fsogsmd a network channel to msmcommd and send all my telephony commands
> > > > to msmcommd whichs put them into link layer frames and sends them to the
> > > > modem.
> > > 
> > > I like the idea of libmsmcomm as a library, this means it may be easy
> > > in the future to make an oFono plugin linked against the library.  I
> > > don't think having a separate daemon and another communication channel
> > > between what is eventually a dialer or sms app, and the modem is such
> > > a good idea (with the D-Bus socket, D-Bus daemon, FSO and serial
> > > driver already there)
> > 
> > I do think that a native integration directly into the oFono source code
> > as msmmodem might be better. However the second daemon solution is
> > stupid and causes too much overhead.
> > 
> > Also I did look into the QMI stuff a little bit and I think we might
> > have to actually create a QMI subsystem in the Linux kernel like we have
> > for Phonet since with USB the network interface and the management
> > interface do share endpoints as far as I can tell so far.
> 
> Whats QMI? Never heard about it.

if you look through the Windows drivers and some of the .inf files, you
find the QMI and most likely it means Qualcomm Management Interface. And
there is also QMUX which is kind of a multiplexer similar to what Phonet
does for the Nokia protocol. The QMI is similar to ISI from Nokia.

Look through the MSM stuff from the Android kernel tree since they are
also using some of these terms. And I guess all MSM modems are similar
one way or the other.

Regards

Marcel

Re: Palm Pre modem plugin

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Hi Nicola,

> >>The forth and worring is that a developer may be forced to use
> >>ofono, as the target device has some closed parts necessary for the os
> >>that does not work anymore if you remove ofono and use FSO.
> >
> > Please do not post these crazy conspiracy theories here.  oFono is GPLed for
> > exactly this reason.
> 
> May you elaborate about that? May not a close source project use oFono
> by calling it's DBus API?

see my other email I wrote to explain it a little bit more. Yes, you can
write an UI and keep it closed source. This is on purpose.

However the D-Bus API is designed in a way that your UI is simple to
begin with since we moved all the logic into the daemon. This is the big
difference to the FSO GSM part. oFono does the heavy and complex work
and all that is 100% GPL. Exactly how it should be.

Regards

Marcel

Re: Palm Pre modem plugin

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

Hi Niko,

> Keep in mind I'm speaking about general developers and their interest,
> not about organizations, just pointing that *actually* FSO carries
> more interests on *some* areas.

Yes, I believe we completely agree on this point.   oFono's intention was 
never to be an entire application framework.  Our ambitions are only to create 
the best flexible, customizable and easy to use telephony stack.

> May you elaborate about that? May not a close source project use oFono
> by calling it's DBus API?

Marcel explained some of this very well already.  But just to add: oFono takes 
nearly full control of the modem, so even if it is technically possible to go 
behind oFono's back and try to do something in a closed/proprietary way, it 
would not be very practical.  This is also something we will actively 
discourage.

> That's one of the reason FSO is modularized. Anyway resource
> management in a complex system has to be handled in a central way to
> take coherency between subsytems.
> Having a middleware doing that is really important, just a case about
> the correct way to suspend/resume a device should be not the interest
> of a high level software.
>

Sure, however alternatives exist.  For this reason oFono does not dictate any 
particular approach.  In oFono everything is setup as a plugin / driver, so 
customizing any part or making it integrate with your particular environment 
should be quite easy.

>
> Nice to hear that. Anyway do not missunderstand, our team is adopting
> oFono, we are just digging incoming issues with the nogsm part
> integration!!!
>

Sounds interesting.  Let me know if I can be of assistance :)

Regards,
-Denis

oFono running on new Freerunner distribution (was: Palm Pre modem plugin)

[DJDAS]

[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]

Denis Kenzior ha scritto:
> Hi Niko,
>   
>> Nice to hear that. Anyway do not missunderstand, our team is adopting
>> oFono, we are just digging incoming issues with the nogsm part
>> integration!!!
>>
>>     
>
> Sounds interesting.  Let me know if I can be of assistance :)
>
>   

Well, maybe you missed some of my previous email in this list some time 
ago :)
I'm the project leader of a new distribution, called NEOPhysis, for the 
Openmoko Freerunner and Niko is the UI team leader.
We are about 10 people in our team and started from scratch creating a 
new distribution which differs from the others, approaching the system 
concept as an embedded low resources device instead of a micro-desktop 
system.
The main focus was not in a "Linux distribution" but in a "Phone with 
advanced capabilities", so as I follow this project since its born, I 
proposed to use oFono as the main telephony stack and FSO for the 
remaining part.
As a proof-of-concept I wrote a "ncurses phone app" which uses oFono to 
do simple calls and ATM I'm able to call a number dialed with the touch 
screen (yes it's very geek! :P ) and I'm finishing the parsing part to 
handle the call status to be able to answer calls.
I asked in my previous emails if someone of the oFono team could send me 
a simple C code because all the test code were written in Python (but 
for the telephony part our focus is speed and reliability so its 
mandatory to use a C/C++ framework/middleware) but received no answer, 
OTOH this let me learn using DBUS and oFono APIs so it was not as bad :)
We put up a build host which produces even an oFono package for the 
OpenEmbedded repository and we are very proud to be the first (AFAIK) to 
use oFono. If you need/want to test oFono on the Freerunner we can 
provide you the packages built each time you need to.
I have just one question: I noticed the Calypso modem registers on the 
network quite slowly (about 1,5-2 mins after powering up) is this 
normal? Can we help you in testing/patching the code to achieve faster 
times (normal phones usually register in seconds).
Thank you very much for your great work, good bye.
Dario.

Re: oFono running on new Freerunner distribution (was: Palm Pre modem plugin)

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]

Hi Dario,

> Well, maybe you missed some of my previous email in this list some time
> ago :)
> I'm the project leader of a new distribution, called NEOPhysis, for the
> Openmoko Freerunner and Niko is the UI team leader.
> We are about 10 people in our team and started from scratch creating a
> new distribution which differs from the others, approaching the system
> concept as an embedded low resources device instead of a micro-desktop
> system.

Ah, I do remember seeing your previous post.  Did not connect the two together 
though.

> I asked in my previous emails if someone of the oFono team could send me
> a simple C code because all the test code were written in Python (but
> for the telephony part our focus is speed and reliability so its
> mandatory to use a C/C++ framework/middleware) but received no answer,

Actually a reference UI for oFono is something we're still lacking.  We've all 
been too busy adding core features.  This is something we want to fix...

> I have just one question: I noticed the Calypso modem registers on the
> network quite slowly (about 1,5-2 mins after powering up) is this
> normal? Can we help you in testing/patching the code to achieve faster
> times (normal phones usually register in seconds).

This might have been related to automatic operator scanning.  Freerunner is 
especially slow on this operation.  The API was changed recently to disable 
this.  Can you test git HEAD to see if this still happens?  

Regards,
-Denis

Re: oFono running on new Freerunner distribution

[DJDAS]

[-- Attachment #1: Type: text/plain, Size: 1010 bytes --]

Denis Kenzior ha scritto:
> Actually a reference UI for oFono is something we're still lacking.  We've all 
> been too busy adding core features.  This is something we want to fix...
>   
I know, following the list I imagine you're very busy. Maybe I can send 
you my code (after finishing and cleaning up) if you want a simple C 
test program...
>   
>> I have just one question: I noticed the Calypso modem registers on the
>> network quite slowly (about 1,5-2 mins after powering up) is this
>> normal? Can we help you in testing/patching the code to achieve faster
>> times (normal phones usually register in seconds).
>>     
>
> This might have been related to automatic operator scanning.  Freerunner is 
> especially slow on this operation.  The API was changed recently to disable 
> this.  Can you test git HEAD to see if this still happens?  
>
> Regards,
> -Denis
>   

Do I have to take the git code or these features are already in the 
current 0.10 version?
Bye,
Dario

Re: oFono running on new Freerunner distribution

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]

Hi Dario,
> Do I have to take the git code or these features are already in the
> current 0.10 version?

This change was made after 0.10 was tagged.  So you'll need the git version.

Regards,
-Denis

Re: oFono running on new Freerunner distribution

[DJDAS]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Hi Denis,
> Hi Dario,
>   
>> Do I have to take the git code or these features are already in the
>> current 0.10 version?
>>     
>
> This change was made after 0.10 was tagged.  So you'll need the git version.
>
>   

OK, I'm pulling from the git, I'll let you know ASAP.
Bye,
Dario.

Re: oFono running on new Freerunner distribution

[DJDAS]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

DJDAS ha scritto:
> Hi Denis,
>> Hi Dario,
>>  
>>> Do I have to take the git code or these features are already in the
>>> current 0.10 version?
>>>     
>>
>> This change was made after 0.10 was tagged.  So you'll need the git 
>> version.
>>
>>   
>
> OK, I'm pulling from the git, I'll let you know ASAP.
> Bye,
> Dario.

GREAT!!!! It worked!!! :)
It registers in less than one minute! :)
I noticed I don't need to call the Register method of 
NetworkRegistration interface but I just need to power up the modem, is 
it ok?
I have another question but maybe it's my fault: I noticed if I want to 
hangup a call during its "alerting" state, I can't, the other party 
continues ringing even if I call the hangup method on the correct path ( 
/calypso0/voicecall01). What am I missing?
Thank you very much in advance, bye.
Bye,
Dario.

Re: oFono running on new Freerunner distribution

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

Hi Dario,

> GREAT!!!! It worked!!! :)
> It registers in less than one minute! :)
> I noticed I don't need to call the Register method of
> NetworkRegistration interface but I just need to power up the modem, is
> it ok?

By default the netreg atom registers you automatically.  However it does 
remember the setting, so if you choose manual registration or deregister from 
the network it will not attempt to register you the next time you reboot.

> I have another question but maybe it's my fault: I noticed if I want to
> hangup a call during its "alerting" state, I can't, the other party
> continues ringing even if I call the hangup method on the correct path (
> /calypso0/voicecall01). What am I missing?

This seems to be a peculiarity of the Calypso modem.  When using ATD on an 
uninitialized port the ATD returns immediately.  This means that 
dialing/alerting calls can be hung up.  However, we use CPI indications and 
for some reason the ATD behavior changes when this is used.  ATD now only 
returns when a call connects, which means we can't hangup dialing/alerting 
calls, as you point out.  There are a couple of solutions we can try, stay 
tuned.

Regards,
-Denis

Re: oFono running on new Freerunner distribution

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

> This seems to be a peculiarity of the Calypso modem.  When using ATD on an
> uninitialized port the ATD returns immediately.  This means that
> dialing/alerting calls can be hung up.  However, we use CPI indications and
> for some reason the ATD behavior changes when this is used.  ATD now only
> returns when a call connects, which means we can't hangup dialing/alerting
> calls, as you point out.  There are a couple of solutions we can try, stay
> tuned.

I pushed an experimental fix.  Let me know if you can now hangup alerting 
calls.  It did not make it into release 0.11 though.

Regards,
-Denis

Re: oFono running on new Freerunner distribution

[DJDAS]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

Hi Denis,
> I pushed an experimental fix.  Let me know if you can now hangup alerting 
> calls.  It did not make it into release 0.11 though.
>
>   

Sorry for the late reply but I was busy at work in last days. I tried 
your patch but had no positive results, the behavior remains the same as 
before, I can dial but can't hangup during alerting state. Furthermore 
after the first conversation this new release doesn't let me dial any 
other number but can receive calls... I tried the previous one (0.9 
IIRC) and it worked well.
If I can help you sending some logs please feel free to ask me what you 
need.
Thank you in advance, bye.
Dario.

Re: oFono running on new Freerunner distribution

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 976 bytes --]

Hi Dario,

> Hi Denis,
>
> > I pushed an experimental fix.  Let me know if you can now hangup alerting
> > calls.  It did not make it into release 0.11 though.
>
> before, I can dial but can't hangup during alerting state. Furthermore

Ok, I pushed a few more things that should fix this.  At least it does for me 
on my Freerunner.   If it still doesn't work, can you send me a log of what 
happens.  export OFONO_AT_DEBUG=1 and run with ofono -nd.

> after the first conversation this new release doesn't let me dial any
> other number but can receive calls... I tried the previous one (0.9
> IIRC) and it worked well.

Is your moko device upgraded to the latest gsm firmware?  I'm using moko11 and 
this seems to work.  Are you running the native calypso plugin or using 
phonesim plugin?

Note that the previous wakeup handling did not always for the phonesim one, 
I've pushed a few fixes that should take care of this as well.

Regards,
-Denis

Re: oFono running on new Freerunner distribution

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

Hi Dario,

> I recompiled from the git and the situation is the same as before;
> attached are two archives, each containing two log files, one made by
> oFono with the options above, the second is the console output of the
> "dbus-monitor --system" command (in which, at the end of file, I pasted

Please make sure you restart oFono when setting OFONO_AT_DEBUG.  The 
environment variable is checked only when the modem is created, which is 
usually startup in the case of modem.conf ones.  This will give much more 
output, including every command sent and received from the modem.

Please redo the logs with the environment variable set before ofono is 
started.

> the command lines I used to do the tests);  the first archive
> (call_answer_hangup*) is a simple test call using one of my provider
> service numbers, I simply called, they answered and I hangup the call,
> after this, as you can see, I was not able to do another call (I did my
> previous tests with my phone application and I didn't notice the error
> given by oFono, sorry!); the second archive (call_hanguptry_remotedisc*)
> is a call to another phone (I masked the number with xxxx for privacy
> purposes), tried to hangup but wasn't able to and asked the other party
> to hangup.

Ok, you were hitting a bug that Zhenhua just caught.  I pushed out his fix.  
I'd be interested in first seeing whether dial -> alerting -> hangup now works 
on a freshly booted oFono instance.

Regards,
-Denis

Re: oFono running on new Freerunner distribution

[DJDAS]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]

Hi Denis,
>
> Ok, I pushed a few more things that should fix this.  At least it does for me 
> on my Freerunner.   If it still doesn't work, can you send me a log of what 
> happens.  export OFONO_AT_DEBUG=1 and run with ofono -nd.
>   
I recompiled from the git and the situation is the same as before; 
attached are two archives, each containing two log files, one made by 
oFono with the options above, the second is the console output of the 
"dbus-monitor --system" command (in which, at the end of file, I pasted 
the command lines I used to do the tests);  the first archive 
(call_answer_hangup*) is a simple test call using one of my provider 
service numbers, I simply called, they answered and I hangup the call, 
after this, as you can see, I was not able to do another call (I did my 
previous tests with my phone application and I didn't notice the error 
given by oFono, sorry!); the second archive (call_hanguptry_remotedisc*) 
is a call to another phone (I masked the number with xxxx for privacy 
purposes), tried to hangup but wasn't able to and asked the other party 
to hangup.

>   
>> after the first conversation this new release doesn't let me dial any
>> other number but can receive calls... I tried the previous one (0.9
>> IIRC) and it worked well.
>>     
>
> Is your moko device upgraded to the latest gsm firmware?  I'm using moko11 and 
> this seems to work.  Are you running the native calypso plugin or using 
> phonesim plugin?
>   
I upgraded my firmware about 3 months ago to moko11 using the SD Image 
provided by Mickey Laurel and I'm using the calypso plugin (what is the 
different between the two plugins?) my phone is a GTA02-A6 model with 
the buzz fixing applied by Golden Delicious (I don't think this could be 
useful but I'm trying to tell you the more informations I can).
Thank you in advance for your kind answers, bye.
Dario.


[-- Attachment #2: call_answer_hangup_ofonodbus_logs.zip --]
[-- Type: application/octet-stream, Size: 4537 bytes --]

[-- Attachment #3: call_hanguptry_remotedisc_ofonodbus_logs.zip --]
[-- Type: application/octet-stream, Size: 4577 bytes --]