----- Alkuperäinen viesti -----
> > Yeah, perhaps the property should be called "TechnologyPreference" with values
> > "any", "2G", "3G", "4G". For now at least.
> so what about the magic CDMA + UMTS combo chips. We basically have to
> reload the firmware with these. Would be nice to figure out on how that
> can be done. Not that we know much about how Qualcomm intends to use
> that in a phone case scenario, but would be nice to at least think about
> it a bit.
I'm not at all sure toggling between CDMA and UMTS is going to work smoothly enough for it to be done at this interface level. It sounds more like disabling one modem and enabling another. And I'm sure there are other areas in the API that are going to need tweaking for CDMA. I would rather cross that bridge when we come to it.
> Also I wanted you to ask about the data roaming. Does the Nokia modem
> has an option to NOT data roam that we can set. The problem with doing
> it in the host is that a bit of data goes through if you start roaming
> and have a PDP context active. So it costs the user. At least some
> reports indicate this. Does your modem forces a detach or does it just
> happily data roam and just give us a cell update?
You mean PDP contexts survive a network change? I don't think they do. Sounds like a bug in the application.
The Nokia modems have a setting to automatically attach, but that doesn't yet move any data.
Sent from Nokia N900 running Maemo 5
> > > +Properties string Mode [read-write]
> > > +
> > > + The current radio access selection mode, also known
> > > + as network preference.
> > > +
> > > + The possible values are:
> > > + "dual" Radio access selection is done
> > > + automatically, using either 2G
> > > + or 3G, depending on reception.
> > > + "2g" Only GSM used for radio access.
> > > + "3g" Only UTRAN used for radio access.
> > > + "unknown" Mode currently unknown.
> > how would we be dealing with LTE here. The word "dual" is kinda tricky
> > in that sense. Also what about chips like Qualcomm GOBI that can change
> > their firmware and start operating in CDMA. We do wanna extend oFono to
> > support CDMA at some point.
> Yeah, perhaps the property should be called "TechnologyPreference" with values "any", "2G", "3G", "4G". For now at least.
so what about the magic CDMA + UMTS combo chips. We basically have to
reload the firmware with these. Would be nice to figure out on how that
can be done. Not that we know much about how Qualcomm intends to use
that in a phone case scenario, but would be nice to at least think about
it a bit.
Also I wanted you to ask about the data roaming. Does the Nokia modem
has an option to NOT data roam that we can set. The problem with doing
it in the host is that a bit of data goes through if you start roaming
and have a PDP context active. So it costs the user. At least some
reports indicate this. Does your modem forces a detach or does it just
happily data roam and just give us a cell update?
The AT command specification obviously didn't care about this at all :(
I'm trying to add support for the Handsfree Gateway role Gustavo just added
to BlueZ and oFono. The BlueZ patches can be found on  and  and the
oFono part was just merged upstream.
But when it comes to integrate them with Pulse, I'm getting a POLLHUP when
trying to write on the fd. Also, it seems different gateways have different
behaviours regarding when they connect the SCO link. Some phone connect
them just after the RFCOMM link (some Nokia phones), when there is no call
going on yet, and others just when a call is started (Android 1.5).
Also, right now the same property (State) is beeing used to refer when the
RFCOOM link is established (State=Connected) and when the SCO link is
established (State=Playing). Shouldn't this be handled by separate props?
And last but not least, is the new Media API intended to handle the audio
part of handsfree gateways too? If so, maybe we should use all this work
as a prototype for latter integration with the new API.
Any help on testing and getting this working together or comments on the
topic would be appreciated.
João Paulo Rechi Vita
On Tue, Feb 2, 2010 at 09:10, Lennart Poettering <lennart(a)poettering.net> wrote:
> On Fri, 29.01.10 12:53, João Paulo Rechi Vita (jprvita(a)gmail.com) wrote:
>> > Any help on testing and getting this working together or comments on the
>> > topic would be appreciated.
>> >  http://www.spinics.net/lists/linux-bluetooth/msg04250.html
>> >  http://www.spinics.net/lists/linux-bluetooth/msg04251.html
>> I forgot to add, suspending of the sink/source seemed to cause
>> disconnection by the AG, so you might want to disable
>> module-suspend-on-idle when testing. BTW, Lennart, is there any way to
>> mark a source/sink to not be suspended?
> Not really. As Colin mentioned you can make suspending a simple NOOP
> which does what you want. That said I do believe it makes a lot of
> sense to actually mark sinks as "suspendable". I.e. Introduce a sink
> flag PA_SINK_SUSPENDABLE or so that we flag for all sinks that
> actually support suspending and leave unset fo all others, like yours.
Even after figuring out suspending wasn't really causing any problem
to my tests, it sounds like a good thing to have support for.
> Anyway, the patches look really good to me. I'd be happy to merge
> this, though is the bluez counterpart merged yet? (sorry, haven't
> closely followed bluez development for a while)
BlueZ part is still not merged, the code is under peer-review now but
it's likely to be merged soon. There may be some modification on which
signals to listen in order to load module-bluetooth-device (for HFP
case only), also. I'll send a patch rebased against git's head when
the merging time comes.
> Lennart Poettering Red Hat, Inc.
> lennart [at] poettering [dot] net
> http://0pointer.net/lennart/ GnuPG 0x1A015CC4
> pulseaudio-discuss mailing list
João Paulo Rechi Vita