Hi,
These patches implement the new API for the Audio Gateway in BlueZ. It
follows the last version of the HandsfreeGateway and HandsfreeAgent
Intefaces API.
The first two patches is for BlueZ and the other for oFono. You can
test it with using enable-modem and test-voicecall scripts into the
test dir of oFono.
Feel free to test it and send me your comments. We have some bugs yet.
The audio part is not working yet. We are going to work on pulseaudio
this week to get this done soon.
Regards,
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi

Hi,
I am now working on modem emulator and one usage is for DUN server role. Since Padovan is working on client role, it's good to share my rough thinking for server side implementation. Here are the simple steps I have:
1. Create an oFono emulator atom in oFono. It's the emulator manager that could create DUN, HFP AG or SPP type emulators. It exposes dbus methods like CreateEmulator, DestroyEmulator, GetProperty, etc.
2. DUN agent server in BlueZ watch oFono and call CreateEmulator and pass the file descriptor to oFono. This server could further implement HFP AG and SPP connection.
3. Once an emulator is created, other atom like voicecall, grps, sms register their interested AT command handlers to it. The goal is that we could handle all mandatory AT commands defined in DUN profile spec.
4. Once a DUN emulator received ATD*99#, DUN client performs ppp connection so we forward ppp command to ppp stack. It is done by ppp server side extension. It should be the simple command forwarding.
5. Once the PPP link over DUN is established, DUN client performs ConnMan integration and setup IP address, DNS server, etc.
6. Once the Bluetooth link is disconnected, we destroy the PPP and DUN emulator. If emulator atom itself is destroyed, we destroy the PPP and the Bluetooth connection. If the PPP link is disconnected but Bluetooth link is alive, we destroy the PPP and stay emulator alive.
Comments are welcome. :)
Regards,
Zhenhua

Hi,
There are currently a bunch of helper scripts under /test for the D-Bus
API in addition to unit tests, and I'm wondering if there are any plans
to automate especially the former into a suite that could be run
semi-regularly, or even at 'make distcheck'?
I think it would be useful to have something like the current scripts,
but modified to be actual test cases as well as more easily
parametrized.
The tests could then be driven with a set of parameters (which cases to
run, what numbers to call, etc.) and a default test profile to work
with, for example, the default phonesim configuration.
Other profiles could then be made for other test environments, such as a
live modem and a test network or network simulator.
Any thoughts on this?
Cheers,
Aki

Hello all,
Here is the first step in adding proper flight mode to ofono. The patch
adds a boolean property "Online" to modem; if that is false, modem is in
flight mode and it has killed its cellular radio.
If the modem driver does not implement online method, the value of the
property is initially true. This feature is intended as temporary. It just
makes the new property as non-intrusive as possible.
There is also a watch list for online/offline state.
The second patch adds the online method to isimodem. The online property of
the isimodem follows the online/offline state of Nokia modems (however, this
has only been tested with N95).
In the next phase, I'll add separate atom lists for flight and online modes.
The old-fashioned post_sim will become post_online. The new method
post_sim_flight will request modem driver to add flight-mode atoms.
--Pekka
BTW, if you have applied the patch I sent earlier today, "usbpnmodem:
configure usbpn interfaces automatically", you can actually try Nokia phones
via USB. They should just work provided you have kernel 2.6.31 or newer
without any manual configuration. Select the "PC suite mode" from the phone
when you connect the USB cable.