This patch reads and writes the call forwarding unconditional status
from and to the SIM depending on the SIM file availability.
New property needs to be added due to the fact that number won't be
available from the cphs-cff file.
Incase of SIM, EFcphs-cff file holds call forwarding status and it
is represented as a flag. In case of USIM(EFcfis), we have the status
flag and also number.So, adding new property for status and using the
existing VoiceUnconditional with number will work for both SIM and USIM cases.
Other option is to have 2 properties, "VoiceUnconditional" and "Number".
"VoiceUnconditional" will have the status of the call forwarding( "enabled",
"disabled") whereas the "Number" property will have the call forwared number.
offline-online state transitions results in caching the call forwaring status
every time. To avoid this, call forwarding atom is moved to the post sim and
its moved also due to the fact that call forwarding status doesn't change in
Jeevaka Badrappan (7):
call-forwarding: Read/Write cfis/cphs-cff
ifx: Move call forwarding to post sim
isigen: Move call forwarding to post sim
plugins/n900: Move call forwarding to post sim
phonesim: Move call forwarding to post sim
doc: Add new property to call forwarding
TODO: Marking the Read/Write EFcfis task as done
TODO | 9 --
doc/call-forwarding-api.txt | 5 +
doc/features.txt | 5 +
plugins/ifx.c | 2 +-
plugins/isigen.c | 2 +-
plugins/n900.c | 2 +-
plugins/phonesim.c | 3 +-
src/call-forwarding.c | 242 ++++++++++++++++++++++++++++++++++++++++++-
8 files changed, 256 insertions(+), 14 deletions(-)
These patches implement the new API for the Audio Gateway in BlueZ. It
follows the last version of the HandsfreeGateway and HandsfreeAgent
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.
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
-mDataCodingScheme is set when we need to apply the same scheme in case of
multi-page CBS message.
-The method 'shouldsplit' is removed since we are using directly the method
compute size in order to check the number of pages.
-When the text is too long, the text truncation is done directly by the method
Philippe Nunes (4):
controbase: Remove entries in CBM UI
qcbsmessage: apply the same coding scheme for all the pages
hardwaremanipulator: Use the best scheme for CBS message
hardwaremanipulator: Add multi-page support for CBS message
src/control.cpp | 9 +--
src/controlbase.ui | 184 ++++++++++++++++---------------------------
src/hardwaremanipulator.cpp | 59 +++++++-------
src/hardwaremanipulator.h | 6 +-
src/qcbsmessage.cpp | 38 ++++-----
src/qcbsmessage.h | 1 -
6 files changed, 117 insertions(+), 180 deletions(-)
First patch is just one that was still pending locally. The other ones fix the
calls to g_dbus_add_signal_watch() to actually watch only the desired bus. It
depends on previous patch for gdbus to be applied first, otherwise libdbus may
call abort() when we exit.
Lucas De Marchi (4):
README: add information about mailing list and site
bluetooth: watch for signals only on BLUEZ_SERVICE
stemgr: watch for signals only on MGR_SERVICE
tools: watch for signals only on OFONO_SERVICE
README | 9 +++++++++
plugins/bluetooth.c | 13 ++++++++-----
plugins/stemgr.c | 4 ++--
tools/auto-enable.c | 20 ++++++++++----------
tools/huawei-audio.c | 17 +++++++++--------
5 files changed, 38 insertions(+), 25 deletions(-)
for personal requirements (debugging) I added 3 simple scripts
(attached) to dump the properties of specific modem interfaces.
Shall I send patches for them or are they useless for the project?
(For the records: I don't mind either)
I'm having troubles with delivery reports.
When I send a message with the property "UseDeliveryReports" set to
I can get the delivery report from the GSM modem, but ofono is unable
to decode it:
ofonod: SMS: < \r\n+CDS:
ofonod: drivers/atmodem/sms.c:at_cds_notify() Got new
Status-Report PDU via CDS:
ofonod: src/sms.c:ofono_sms_status_notify() len 32 tpdu len 32
ofonod: Unable to decode PDU
The PDU is valid, since I can decode it using some online tool.
It seems that sms_decode does not correctly handle the SMSCC part
and tries to decode it as the sender address, which obviously fails.
If in decode_deliver() function, I shift the PDU of 9 bytes (ie. PDU is
then the function still fails (more or less expected), but the sender
address is correctly decoded.
Do any of you have an idea on this matter ?