Re: [PATCH 2/2] Support for pkg-config
On Wednesday 26 January 2011 13:27:23 ext Marcel Holtmann, you wrote: Name: @PACKAGE@ Description: oFono - Open Source Telephony Requires: glib-2.0 dbus-1 Hmm, wasn't the goal to not leak glib through the public API? I could not find any glib type from a quick check in include/ofono/ ... -- Rémi Denis-Courmont Nokia Devices RD, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH] modem:Add powered watches on modem.
---
src/modem.c | 47 +++
src/ofono.h |7 +++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/src/modem.c b/src/modem.c
index 8e243d8..4e026cf 100644
--- a/src/modem.c
+++ b/src/modem.c
@@ -77,6 +77,7 @@ struct ofono_modem {
guint timeout;
ofono_bool_tonline;
struct ofono_watchlist *online_watches;
+ struct ofono_watchlist *powered_watches;
GHashTable *properties;
struct ofono_sim*sim;
unsigned intsim_watch;
@@ -383,6 +384,22 @@ static void notify_online_watches(struct ofono_modem
*modem)
}
}
+static void notify_powered_watches(struct ofono_modem *modem)
+{
+ struct ofono_watchlist_item *item;
+ GSList *l;
+ ofono_modem_powered_notify_func notify;
+
+ if (modem-powered_watches == NULL)
+ return;
+
+ for (l = modem-powered_watches-items; l; l = l-next) {
+ item = l-data;
+ notify = item-notify;
+ notify(modem-powered, item-notify_data);
+ }
+}
+
static void modem_change_state(struct ofono_modem *modem,
enum modem_state new_state)
{
@@ -462,6 +479,30 @@ void __ofono_modem_remove_online_watch(struct ofono_modem
*modem,
__ofono_watchlist_remove_item(modem-online_watches, id);
}
+unsigned int __ofono_modem_add_powered_watch(struct ofono_modem *modem,
+ ofono_modem_powered_notify_func notify,
+ void *data, ofono_destroy_func destroy)
+{
+ struct ofono_watchlist_item *item;
+
+ if (modem == NULL || notify == NULL)
+ return 0;
+
+ item = g_new0(struct ofono_watchlist_item, 1);
+
+ item-notify = notify;
+ item-destroy = destroy;
+ item-notify_data = data;
+
+ return __ofono_watchlist_add_item(modem-powered_watches, item);
+}
+
+void __ofono_modem_remove_powered_watch(struct ofono_modem *modem,
+ unsigned int id)
+{
+ __ofono_watchlist_remove_item(modem-powered_watches, id);
+}
+
static void common_online_cb(const struct ofono_error *error, void *data)
{
struct ofono_modem *modem = data;
@@ -723,6 +764,8 @@ static int set_powered(struct ofono_modem *modem,
ofono_bool_t powered)
else if (err != -EINPROGRESS)
modem-powered_pending = modem-powered;
+ notify_powered_watches(modem);
+
return err;
}
@@ -1699,6 +1742,7 @@ int ofono_modem_register(struct ofono_modem *modem)
modem-atom_watches = __ofono_watchlist_new(g_free);
modem-online_watches = __ofono_watchlist_new(g_free);
+ modem-powered_watches = __ofono_watchlist_new(g_free);
emit_modem_added(modem);
call_modemwatches(modem, TRUE);
@@ -1732,6 +1776,9 @@ static void modem_unregister(struct ofono_modem *modem)
__ofono_watchlist_free(modem-online_watches);
modem-online_watches = NULL;
+
+ __ofono_watchlist_free(modem-powered_watches);
+ modem-powered_watches = NULL;
modem-sim_watch = 0;
modem-sim_ready_watch = 0;
diff --git a/src/ofono.h b/src/ofono.h
index 6ba0187..82d857f 100644
--- a/src/ofono.h
+++ b/src/ofono.h
@@ -188,6 +188,13 @@ unsigned int __ofono_modem_add_online_watch(struct
ofono_modem *modem,
void __ofono_modem_remove_online_watch(struct ofono_modem *modem,
unsigned int id);
+typedef void (*ofono_modem_powered_notify_func)(ofono_bool_t powered, void
*data);
+unsigned int __ofono_modem_add_powered_watch(struct ofono_modem *modem,
+ ofono_modem_online_notify_func notify,
+ void *data, ofono_destroy_func destroy);
+void __ofono_modem_remove_powered_watch(struct ofono_modem *modem,
+ unsigned int id);
+
#include ofono/call-barring.h
gboolean __ofono_call_barring_is_busy(struct ofono_call_barring *cb);
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: SMS Validity Period
Hi Miia, +- Add support for setting the SMS Validity Period (3GPP 23.040). Currently the + value is hard coded as 24 hours. didn't we actually change this to be the maximum value? Only place I could find this to be edited was following line in smsutil.c (3421) template.submit.vp.relative = 0xA7; /* 24 Hours */ Have I missed something then? In any case, I'd rather see the value something that API allows to set instead of hard coded value, as user can have different needs for the SMS validity period and sometimes it is not the best thing either that period is set to maximum. why does the user have different needs here? Where are these needs coming from? How does a normal user actually know what this means for him and the network he is using? Is the network actually honoring these values at all these days? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: SMS Validity Period
Hi Marcel, 2011/1/31 Marcel Holtmann mar...@holtmann.org: How does a normal user actually know what this means for him and the network he is using? Is the network actually honoring these values at all these days? These are not clear to me either, so I don't see the point in exposing this setting over the D-Bus interface. I would, however, err on the side of flexibility here, and make this a configuration option in main.conf (once that support is available in oFono). Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[RFC] voice call API changes (proposal)
Here is a proposal for expanding the VoiceCallManager interface with
call related Supplementary Services signals, and the VoiceCall
interface with new properties.
---
doc/call-barring-api.txt | 10 --
doc/voicecall-api.txt| 15 +++
doc/voicecallmanager-api.txt | 21 +
3 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/doc/call-barring-api.txt b/doc/call-barring-api.txt
index 41ae4b1..1534494 100644
--- a/doc/call-barring-api.txt
+++ b/doc/call-barring-api.txt
@@ -37,16 +37,6 @@ Signals PropertyChanged(string property,
variant value)
Signal is emitted whenever a property has changed.
The new value is passed as the signal argument.
- IncomingBarringInEffect()
-
- Signal is emitted when a call is made and an
- incoming call barring supplementary service is in use.
-
- OutgoingBarringInEffect()
-
- Signal is emitted when a call is made and an
- outgoing call barring supplementary service is in use.
-
Properties string VoiceIncoming [readwrite]
Contains the value of the barrings for the incoming
diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
index 047b8cb..e7276a3 100644
--- a/doc/voicecall-api.txt
+++ b/doc/voicecall-api.txt
@@ -145,3 +145,18 @@ Properties string LineIdentification [readonly]
Contains the indication if the voice call is an
emergency call or not.
+
+ boolean Forwarded
+
+ Contains the indication whether the voice call is a
+ forwarded call or not.
+
+ boolean RemoteHold
+
+ Contains the indication whether the voice call has been
+ put on hold by the remote party or not.
+
+ boolean Waiting
+
+ Contains the indication whether the outgoing voice call
+ is waiting or not.
diff --git a/doc/voicecallmanager-api.txt b/doc/voicecallmanager-api.txt
index 2bf9ded..bbd80db 100644
--- a/doc/voicecallmanager-api.txt
+++ b/doc/voicecallmanager-api.txt
@@ -144,6 +144,27 @@ SignalsCallAdded(object path, dict properties)
Signal is emitted whenever a property has changed.
The new value is passed as the signal argument.
+ UnconditionalForwardingInEffect
+
+ Signal is emitted when a call is made and unconditional
+ call forwarding supplementary service is active.
+
+ ConditionalForwardingInEffect
+
+ Signal is emitted when a call is made and some of the
+ conditional call forwarding supplementary services are
+ active.
+
+ IncomingBarringInEffect()
+
+ Signal is emitted when a call is made and an
+ incoming call barring supplementary service is in use.
+
+ OutgoingBarringInEffect()
+
+ Signal is emitted when a call is made and an
+ outgoing call barring supplementary service is in use.
+
Properties array{string} EmergencyNumbers [readonly]
Contains the list of emergency numbers recognized
--
1.7.0.4
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/1] gisi: Updated subscriptions and pipe handling to accomodate additional isimodem versions
Hi Rémi,
2011/1/28 Rémi Denis-Courmont remi.denis-courm...@nokia.com
It looks like you are mixing up services (PN_* from 0 to 255), with device
addresses (PN_DEV_* multiple of four from 0 to 252).
Yes, you are right. We will change it.
@@ -61,6 +61,7 @@ struct _GIsiModem {
unsigned index;
GHashTable *services;
gboolean subs_source;
+ GIsiVersion version;
I can't see where this gets set?!
In g_isi_modem_set_version() in plugins/u8500.c
New file, that will hopefully be sent in a patch to the mailing list today.
+
+ if (g_isi_modem_version_major(modem) == 2
+ g_isi_modem_version_minor(modem) == 5) {
You really need to factor this check out. It's going to be a disaster when
there are more than two versions otherwise.
Well, we really need the PNS_SUBSCRIBED_RESOURCES_EXTEND_IND because
the other one doesn't work for us.
Would a lookup function do the trick, with filling in the necessary
values in msg depending on which version it is?
If that is not satisfactory, could you please be a bit more specific
in what you would like to see so we don't misunderstand?
@@ -363,13 +382,31 @@ static gboolean modem_subs_update(gpointer data)
That should probably be a separate patch.
Yes, you are right.
diff --git a/gisi/pipe.c b/gisi/pipe.c
We already have this in kernel and I wonder why this needs to be duplicated in
userspace now?! Furthermore pipe.c is about pipes. Pipe endpoints code belongs
in pep.c. If you want to implement a pipe controller in gisi, then I think it
really deserves a new file of its own.
isimodem2.5 needs this code, the kernel struct won't be applicable for
us in the modem case.
We will move the pep functions to the pep.c
Best Regards,
Jessica Nilsson
ST-Ericsson
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] doc: Proposal for LTE/IMS API.
Hi Pekka. Do you think we will ever have more than one IMS ConnectionContext pr SIM? If not not we could probably keep the PcscfAddresses in this IMS API (see object-path proposal below). Unfortunately, yes. Could you please elaborate on this. Do you really foresee a scenario where an operator will provide more than one IMS network? Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: SMS Validity Period
Hi Marcel, why does the user have different needs here? Where are these needs coming from? You want real life user cases? :) OK, I give you some. Personally nr 1 is my favourite one as that is such a common thing to happen. 1) Have you ever been drunk and written stupid messages you really don't want to reach their destination the next day anymore if they have not already (maybe you wish they never would have reached the destination but all the mistakes can't be prevented..) 2) You have a situation that you want to buy something important and there are two options of which you prefer other one. You can not reach the guy with preferred option via call so you send a message, but you want to be sure that you know the situation before the other offer closes. Of course the preferred option's seller expects you to make the commitment right away for purchase so text message can not be sent in vain. 3) Example from the wonderful world of Internet: http://www.developershome.com/sms/sms_tutorial.asp?page=basicConcepts How does a normal user actually know what this means for him and the network he is using? The normal user knows this by reading the manual if he does not understand it directly when seeing the setting in the device. And if there is a chance that network does not support all features that device can offer, a disclaimer about that can be added to manual or help files. Is the network actually honoring these values at all these days Whether the network is honoring this case or not is not the issue here. If such would be the reason for dropping features then many things would never get completed when people would just discuss who should do what first. I have not met a situation at least in Finland where network does not support it, but I have not made comprehensive study about this. If the network does not follow the request then that is a network issue and should be handled through other channels. The truth is that if oFono does not allow this setting through the API, then devices using oFono have no means to offer this choice to its users even if the network would support it. One more thing, Meego also has a requirement about this in Featurezilla: Feature 4564 - [FEA] Cellular - SMS Validity period BR, Miia __ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: SMS Validity Period
Hi Aki, How does a normal user actually know what this means for him and the network he is using? Is the network actually honoring these values at all these days? These are not clear to me either, so I don't see the point in exposing this setting over the D-Bus interface. I would, however, err on the side of flexibility here, and make this a configuration option in main.conf (once that support is available in oFono). we did talk a bit about expected operator defaults especially in the context of default character set etc. I think Portugal is such an exception where you have to start out with a proper character set if your SIM card is originated from there. Maybe this is another one case where just picking a proper operator default is better than actually providing any option to change it. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: SMS Validity Period
Hi Miia, why does the user have different needs here? Where are these needs coming from? You want real life user cases? :) OK, I give you some. Personally nr 1 is my favourite one as that is such a common thing to happen. 1) Have you ever been drunk and written stupid messages you really don't want to reach their destination the next day anymore if they have not already (maybe you wish they never would have reached the destination but all the mistakes can't be prevented..) 2) You have a situation that you want to buy something important and there are two options of which you prefer other one. You can not reach the guy with preferred option via call so you send a message, but you want to be sure that you know the situation before the other offer closes. Of course the preferred option's seller expects you to make the commitment right away for purchase so text message can not be sent in vain. 3) Example from the wonderful world of Internet: http://www.developershome.com/sms/sms_tutorial.asp?page=basicConcepts and what does this all buy you? There are so many funny ideas in GSM that having nothing to do with reality anymore since the world has moved on since 1995. How does a normal user actually know what this means for him and the network he is using? The normal user knows this by reading the manual if he does not understand it directly when seeing the setting in the device. And if there is a chance that network does not support all features that device can offer, a disclaimer about that can be added to manual or help files. This is the worst explanation ever. You might wanna talk to some user interaction experts. They will tell you that they do exactly not want this in a mobile device. It needs to self explanatory and your are not suppose to read 600 pages of manual first. I feel like being back in 1995 with my good old Nokia phone where I had no clue what half of the options where doing for me ;) Is the network actually honoring these values at all these days Whether the network is honoring this case or not is not the issue here. If such would be the reason for dropping features then many things would never get completed when people would just discuss who should do what first. I have not met a situation at least in Finland where network does not support it, but I have not made comprehensive study about this. If the network does not follow the request then that is a network issue and should be handled through other channels. The truth is that if oFono does not allow this setting through the API, then devices using oFono have no means to offer this choice to its users even if the network would support it. And what would be the impact here with defaulting to the networks value? It would just work fine and normally it all depends on the network anyway. You can tell it to have 24 hours, but if it only wants to hold it for 6 hours, then there is nothing you can do about. SMS is not a reliable form of communication. I am pretty sure that all the terms of service regarding SMS are phrased properly by the network operators. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] atmodem: implement standard PIN retries
Hi Remi,
drivers/atmodem/sim.c | 48
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
index 0938998..dfd40f8 100644
--- a/drivers/atmodem/sim.c
+++ b/drivers/atmodem/sim.c
@@ -57,6 +57,7 @@ static const char *cpin_prefix[] = { +CPIN:, NULL };
static const char *clck_prefix[] = { +CLCK:, NULL };
static const char *huawei_cpin_prefix[] = { ^CPIN:, NULL };
static const char *xpincnt_prefix[] = { +XPINCNT:, NULL };
+static const char *cpinr_prefixes[] = { +CPINR:, +CPINRE:, NULL };
if you are not processing +CPINRE, why bother consuming it in the first
place?
static const char *none_prefix[] = { NULL };
static void at_crsm_info_cb(gboolean ok, GAtResult *result, gpointer
user_data)
@@ -554,6 +555,50 @@ error:
CALLBACK_WITH_FAILURE(cb, NULL, cbd-data);
}
+static void at_cpinr_cb(gboolean ok, GAtResult *result, gpointer user_data)
+{
+ struct cb_data *cbd = user_data;
+ ofono_sim_pin_retries_cb_t cb = cbd-cb;
+ GAtResultIter iter;
+ struct ofono_error error;
+ int retries[OFONO_SIM_PASSWORD_INVALID];
+ size_t len = sizeof(at_sim_name) / sizeof(*at_sim_name);
+ size_t i;
+
+ decode_at_error(error, g_at_result_final_response(result));
+
+ if (!ok) {
+ cb(error, NULL, cbd-data);
+ return;
+ }
+
+ for (i = 0; i OFONO_SIM_PASSWORD_INVALID; i++)
+ retries[i] = -1;
+
+ g_at_result_iter_init(iter, result);
+
+ /* Ignore +CPINRE results... */
+ while (g_at_result_iter_next(iter, +CPINR:)) {
+ const char *name;
+ int val;
+
+ if (!g_at_result_iter_next_unquoted_string(iter, name))
+ continue;
+
+ if (!g_at_result_iter_next_number(iter, val))
+ continue;
+
+ for (i = 1; i len; i++) {
+ if (!strcmp(name, at_sim_name[i].name)) {
+ retries[i] = val;
+ break;
+ }
+ }
+ }
+
+ cb(error, retries, cbd-data);
+}
+
static void at_pin_retries_query(struct ofono_sim *sim,
ofono_sim_pin_retries_cb_t cb,
void *data)
@@ -577,6 +622,9 @@ static void at_pin_retries_query(struct ofono_sim *sim,
break;
default:
+ if (g_at_chat_send(sd-chat, AT+CPINR, cpinr_prefixes,
+ at_cpinr_cb, cbd, g_free) 0)
+ return;
since this command is pretty new, don't we need to check if it is
supported? Is there any impact not checking it?
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] atmodem: implement standard PIN retries
On Monday 31 January 2011 14:59:50 ext Marcel Holtmann, you wrote:
Hi Remi,
drivers/atmodem/sim.c | 48
1 files changed, 48
insertions(+), 0 deletions(-)
diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
index 0938998..dfd40f8 100644
--- a/drivers/atmodem/sim.c
+++ b/drivers/atmodem/sim.c
@@ -57,6 +57,7 @@ static const char *cpin_prefix[] = { +CPIN:, NULL };
static const char *clck_prefix[] = { +CLCK:, NULL };
static const char *huawei_cpin_prefix[] = { ^CPIN:, NULL };
static const char *xpincnt_prefix[] = { +XPINCNT:, NULL };
+static const char *cpinr_prefixes[] = { +CPINR:, +CPINRE:, NULL };
if you are not processing +CPINRE, why bother consuming it in the first
place?
So that they're not misinterpreted as unsolicited responses.
static const char *none_prefix[] = { NULL };
static void at_crsm_info_cb(gboolean ok, GAtResult *result, gpointer
user_data)
@@ -577,6 +622,9 @@ static void at_pin_retries_query(struct ofono_sim
*sim,
break;
default:
+ if (g_at_chat_send(sd-chat, AT+CPINR, cpinr_prefixes,
+ at_cpinr_cb, cbd, g_free) 0)
+ return;
since this command is pretty new, don't we need to check if it is
supported? Is there any impact not checking it?
This will just defer the (failure) callback until the ERROR response.
--
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH] atmodem: implement standard PIN retries
Hi Remi,
drivers/atmodem/sim.c | 48
1 files changed, 48
insertions(+), 0 deletions(-)
diff --git a/drivers/atmodem/sim.c b/drivers/atmodem/sim.c
index 0938998..dfd40f8 100644
--- a/drivers/atmodem/sim.c
+++ b/drivers/atmodem/sim.c
@@ -57,6 +57,7 @@ static const char *cpin_prefix[] = { +CPIN:, NULL };
static const char *clck_prefix[] = { +CLCK:, NULL };
static const char *huawei_cpin_prefix[] = { ^CPIN:, NULL };
static const char *xpincnt_prefix[] = { +XPINCNT:, NULL };
+static const char *cpinr_prefixes[] = { +CPINR:, +CPINRE:, NULL };
if you are not processing +CPINRE, why bother consuming it in the first
place?
So that they're not misinterpreted as unsolicited responses.
they would be. Do you care?
static const char *none_prefix[] = { NULL };
static void at_crsm_info_cb(gboolean ok, GAtResult *result, gpointer
user_data)
@@ -577,6 +622,9 @@ static void at_pin_retries_query(struct ofono_sim
*sim,
break;
default:
+ if (g_at_chat_send(sd-chat, AT+CPINR, cpinr_prefixes,
+ at_cpinr_cb, cbd, g_free) 0)
+ return;
since this command is pretty new, don't we need to check if it is
supported? Is there any impact not checking it?
This will just defer the (failure) callback until the ERROR response.
Okay. If there is no impact here I am fine with it.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/1] ISI modem version detection with plugin
Hi Marcel, On Mon, Jan 31, 2011 at 2:32 PM, Marcel Holtmann mar...@holtmann.org wrote: you do need to split this. At least one for isimodem, one for udev changes and one for the u8500 plugin. Ok, we will do that. We thought this was a good logical/functional split that would give you a good overview. Do you want them as a 1-3 series patch or should I send each separately? Best Regards, Jessica Nilsson ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Selecting multiple radio access technologies in oFono
Hi all, Could it be possible to extend current TechnologyPreference setting in radio-settings-api in a way which would enable user to limit usage of certain radio accesses? For example user could choose to limit technology usage to technologies like GSM and UMTS even if the LTE coverage would be available. Following value could be introduced to current API to enable this kind of selection: gsm Only GSM used for radio access. umts Only UMTS used for radio access. gsm_umts Only GSM or UMTS used for radio access. lte Only LTE used for radio access. Other approach could be that we would rephrase existing API so that instead of using only LTE, we would use LTE whenever available and some older technology when LTE coverage is lacking. So user would select highest allowed radio access without restrictions to use only one technology which has been selected. This would save us from polluting value selection with options like gsm_umts, a decision we'd be grateful when we'll run oFono on 10G modems. ;) Use case for this could be energy conservation. At least I have habit to set network preference to 'GSM' to conserve battery life when I know I'm going to travel places where 3G coverage is not that good or I'm not going to need it. Br, Paavo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Selecting multiple radio access technologies in oFono
On Monday 31 January 2011 15:59:14 ext Paavo Leinonen, you wrote: Hi all, Could it be possible to extend current TechnologyPreference setting in radio-settings-api in a way which would enable user to limit usage of certain radio accesses? For example user could choose to limit technology usage to technologies like GSM and UMTS even if the LTE coverage would be available. Following value could be introduced to current API to enable this kind of selection: gsm Only GSM used for radio access. umts Only UMTS used for radio access. gsm_umts Only GSM or UMTS used for radio access. lte Only LTE used for radio access. Oh my, no. If you want to control technologies one by one, use a string and a boolean. If you really want atomicity w.r.t. D-Bus, then make it a dictionary. -- Rémi Denis-Courmont Nokia Devices RD, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] TODO: SMS Validity Period
Hi Miia, and what does this all buy you? There are so many funny ideas in GSM that having nothing to do with reality anymore since the world has moved on since 1995. First of all, I don't think people stopped drinking and sending stupid messages after 1995. Or that no one does any personal commerce with questionable means any more. Are simple needs of a normal individual funny? I guess many of them are but still it always feels nice when you are able to get your needs met even if for someone else your need might not make sense. Not everyone wants same things. Of course if the aim here is to do an API that already decides in the lower level the options for the device manufacturers so they don't need to bother themselves with business decisions, then this is the way to go. Good luck with serving people-of-today who value options and freedom of choice. In the end, oFono is not providing the UI, if the device manufacturer does not want its users to have the option to change the validity period then they can omit the feature. But if this kind of features are not supported even in the oFono level, then what purpose does that serve? there is no point in supporting some dreamed up use case that you are making up right now. You have no control over your SMS once it leaves your mobile phone and got accepted by the network for submission. No weird option is going to make this any better. There is no control if the receiver has their mobile phone on or off. And there is certainly no control over when the network will deliver the SMS. Same as you can not recall an email once it got delivered to the receivers inbox. This is all just a wet dream ;) This is the worst explanation ever. You might wanna talk to some user interaction experts. They will tell you that they do exactly not want this in a mobile device. It needs to self explanatory and your are not suppose to read 600 pages of manual first. A user interaction expert would be clever enough hide the menu for the setting when it is not supported by the network. There are so many decisions that UI guys can do to make the feature self explainable. So I don't think it is required to drop the features only for the reason that maybe some networks don't support it. oFono's API is clearly about what makes sense to be exposed to the actual user. It was never and will never be about adding any kind of feature that you can dream of in the GSM world. Until you really make a good case why the user should be exposed to such an option, I don't see it. So I am clearly in favor of sensible defaults here. But that is a different story. I feel like being back in 1995 with my good old Nokia phone where I had no clue what half of the options where doing for me ;) Come on! :D Here we can go back to the fact that not everything must be used that is available if you feel content as you are. Actually exposing things that can not be used or the end user can not make sense of is a pretty bad idea. And what would be the impact here with defaulting to the networks value? It would just work fine and normally it all depends on the network anyway. You can tell it to have 24 hours, but if it only wants to hold it for 6 hours, then there is nothing you can do about. SMS is not a reliable form of communication. I am pretty sure that all the terms of service regarding SMS are phrased properly by the network operators. What comes to SMS not being reliable, can you honestly say that you are working to make a better phone but the features you support are not to trust? Anyway, even if the user can not do anything to the value when network does not support the setting, then is that enough reason to deny the option from everyone? I am not following here. What is an option good for if it does not give anything to the user. In fact it could potentially be actually lying to the user since we have no control whatsoever. But hey, let me ask you this part. When did you ever changed that option on your smartphone the last time. Maybe my last phone that had such an option was the Nokia 6210 with the Bluetooth battery pack and even back then it did not make sense to me. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH v6] ifx: Adding modem selftest for Infineon modem
Hi Robertino,
Infineon modem selftest, during ifx_enable().
Two steps trigger, with timeout. In case one
fails, modem will not power up.
---
plugins/ifx.c | 112
-
1 files changed, 95 insertions(+), 17 deletions(-)
diff --git a/plugins/ifx.c b/plugins/ifx.c
index 0d31167..39f38ab 100644
--- a/plugins/ifx.c
+++ b/plugins/ifx.c
@@ -72,6 +72,8 @@
#define GPRS3_DLC 4
#define AUX_DLC 5
+#define IFX_SETUP_TIMEOUT10
+
static char *dlc_prefixes[NUM_DLC] = { Voice: , Net: , GPRS1: ,
GPRS2: , GPRS3: , Aux: };
@@ -89,7 +91,7 @@ struct ifx_data {
guint dlc_poll_count;
guint dlc_poll_source;
guint dlc_init_source;
- guint mux_init_timeout;
+ guint cmd_setup_timeout;
guint frame_size;
int mux_ldisc;
int saved_ldisc;
@@ -100,6 +102,9 @@ struct ifx_data {
int audio_loopback;
struct ofono_sim *sim;
gboolean have_sim;
+ gboolean rtc_gti_selftest_timeout;
+ gboolean dev_ver_selftest_timeout;
+ gboolean mux_setup_timeout;
what is this for? It is not a good idea.
};
static void ifx_debug(const char *str, void *user_data)
@@ -475,9 +480,9 @@ static void mux_setup_cb(gboolean ok, GAtResult *result,
gpointer user_data)
DBG();
- if (data-mux_init_timeout 0) {
- g_source_remove(data-mux_init_timeout);
- data-mux_init_timeout = 0;
+ if (data-cmd_setup_timeout 0) {
+ g_source_remove(data-cmd_setup_timeout);
+ data-cmd_setup_timeout = 0;
}
Why do you bother renaming this. Stick with mux_init_timeout.
g_at_chat_unref(data-dlcs[AUX_DLC]);
@@ -519,26 +524,88 @@ error:
ofono_modem_set_powered(modem, FALSE);
}
-static gboolean mux_timeout_cb(gpointer user_data)
+static gboolean cmd_setup_timeout_cb(gpointer user_data)
{
struct ofono_modem *modem = user_data;
struct ifx_data *data = ofono_modem_get_data(modem);
- ofono_error(Timeout with multiplexer setup);
+ if (data-rtc_gti_selftest_timeout)
+ ofono_error(ERROR:IFX Selftest
+ at@rtc:rtc_gti_test_verify_32khz()-TIMEOUT);
+ else if (data-dev_ver_selftest_timeout)
+ ofono_error(ERROR:IFX Selftest
+ at@vers:device_version_id()-TIMEOUT);
+ else if (data-mux_setup_timeout)
+ ofono_error(ERROR:IFX Mux setup-TIMEOUT);
I really thought that we cleared on how to do this. This is utterly
complex and unneeded.
So GAtChat has a builtin queue. And new commands will only be send after
the other has been processed. You can easily cancel pending commands
from a callback these days.
So you can just call g_at_chat_send() three times initially and then be
done with it. If any of these fail, you just cancel all pending commands
and fail the init. That simple.
There is no need for this complexity at all. Please re-work this patch
as I described in the other review. It should be a really simple patch
actually.
Regards
Marcel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 3/5] sim: Implement file watching and basic refresh.
Hi Denis,
I took me a while to get back to this, but we need to work it out...
On 12 January 2011 22:55, Denis Kenzior denk...@gmail.com wrote:
+void __ofono_sim_refresh(struct ofono_sim *sim, GSList *file_list,
+ ofono_bool_t full_file_change, ofono_bool_t naa_init)
+{
+ GSList *l, *filel;
+ enum sim_reset_state {
+ RESET_STATE_NOT_PRESENT = OFONO_SIM_STATE_NOT_PRESENT,
+ RESET_STATE_INSERTED = OFONO_SIM_STATE_INSERTED,
+ RESET_STATE_READY = OFONO_SIM_STATE_READY,
+ RESET_STATE_NONE,
+ } reset_state = RESET_STATE_NONE;
+
+ /* Flush cached content for affected files */
+ if (full_file_change)
+ sim_fs_cache_flush(sim-simfs);
+ else
+ for (filel = file_list; filel; filel = filel-next) {
+ struct stk_file *file = filel-data;
+ int id = (file-file[file-len - 2] 8) |
+ (file-file[file-len - 1] 0);
+
+ sim_file_changed_flush(sim, id);
+ }
Just a nitpick, but when you have such compound statements inside
if/while/for, could you enclose them in parentheses? I think that makes
the code a bit more readable.
e.g.
if (foo)
else {
for () {
}
}
Ok, good point.
+
+ if (naa_init)
+ reset_state = RESET_STATE_INSERTED;
+
+ /*
+ * Check if we have file change handlers for all of the affected
+ * files. If not, we will fall back to re-initialising the
+ * application which ensures that all files are re-read.
+ */
+ for (l = sim-fs_watches; l; l = l-next) {
+ struct fs_watch *w = l-data;
+
+ if (full_file_change) {
+ if (w-notify)
+ continue;
+
+ if (w-reset_state reset_state)
+ reset_state = reset_state;
+
+ continue;
+ }
+
+ for (filel = file_list; filel; filel = filel-next) {
+ struct stk_file *file = filel-data;
+ int id = (file-file[file-len - 2] 8) |
+ (file-file[file-len - 1] 0);
+
+ if (id != w-id)
+ continue;
+
+ if (w-notify)
+ break;
+
+ if (w-reset_state reset_state)
+ reset_state = reset_state;
+
+ break;
+ }
+ }
+
+ /*
+ * Notify the subscribers of files that have changed unless we
+ * have determined that a re-initialisation is necessary and
+ * will trigger re-reading of those files anyway.
+ */
+ for (l = sim-fs_watches; l; l = l-next) {
+ struct fs_watch *w = l-data;
+
+ if (full_file_change) {
+ if (w-reset_state reset_state)
+ w-notify(w-id, w-notify_data);
+
+ continue;
+ }
+
+ for (filel = file_list; filel; filel = filel-next) {
+ struct stk_file *file = filel-data;
+ int id = (file-file[file-len - 2] 8) |
+ (file-file[file-len - 1] 0);
+
+ if (id != w-id)
+ continue;
+
+ if (w-reset_state reset_state)
+ w-notify(w-id, w-notify_data);
+
+ break;
+ }
+ }
+
+ switch (reset_state) {
+ case RESET_STATE_NOT_PRESENT:
+ ofono_sim_inserted_notify(sim, FALSE);
+ ofono_sim_inserted_notify(sim, TRUE);
Are you sure we can do it this way? I would assume that the modem might
require some time to perform its own SIM initialization and would have
to signal the sim_inserted itself...
I assume that the modem would send the refresh command only once it
has done all its internal housekeeping and is ready for us to re-read
the changed files. If not then probably the AT interface will block
for as much time as needed?
+ break;
+ case RESET_STATE_INSERTED:
+ sim_free_state(sim);
+ sim-state = OFONO_SIM_STATE_INSERTED;
+ sim_initialize(sim);
What about removing all the post_sim / online atoms? In theory
something like EFfdn could have been changed and now we're stuck in
fixed dialing mode. We should not keep the atoms around in this case.
So in the next patch I add a watch for every file in the SIM that we
care about. Every watch has a sort of reset level, which tells
sim.c how much of our state needs to be reinitialised, so that we
don't reset the atoms if that is not necessary. For example for EFust
/ EFest we set the level to RESET_STATE_INSERTED.
This is the case for FDN,
Re: [PATCH 3/5] sim: Implement file watching and basic refresh.
On 31 January 2011 18:45, Denis Kenzior denk...@gmail.com wrote:
+ switch (reset_state) {
+ case RESET_STATE_NOT_PRESENT:
+ ofono_sim_inserted_notify(sim, FALSE);
+ ofono_sim_inserted_notify(sim, TRUE);
Are you sure we can do it this way? I would assume that the modem might
require some time to perform its own SIM initialization and would have
to signal the sim_inserted itself...
I assume that the modem would send the refresh command only once it
has done all its internal housekeeping and is ready for us to re-read
the changed files. If not then probably the AT interface will block
for as much time as needed?
So I think we have to double check this part. There are definitely STK
implementations which send the Refresh and then look at the terminal
response to see whether the refresh should succeed or not.
Yes, it would be good to confirm, at this point I have no data.
However I can't see a good way to find out when the SIM is ready to
accept new commands (except sending the commands away and waiting
until we get called back).
+ break;
+ case RESET_STATE_INSERTED:
+ sim_free_state(sim);
+ sim-state = OFONO_SIM_STATE_INSERTED;
+ sim_initialize(sim);
What about removing all the post_sim / online atoms? In theory
something like EFfdn could have been changed and now we're stuck in
fixed dialing mode. We should not keep the atoms around in this case.
So in the next patch I add a watch for every file in the SIM that we
care about. Every watch has a sort of reset level, which tells
sim.c how much of our state needs to be reinitialised, so that we
don't reset the atoms if that is not necessary. For example for EFust
/ EFest we set the level to RESET_STATE_INSERTED.
This is the case for FDN, because will be re-read EFust/EFest as a
result of sim_initialize() and later at some point we will signal
OFONO_SIM_STATE_READY so all the concerned atoms will take note. It's
not necessary to remove the atoms in this case.
Still not sure this works. Lets say you have a SIM that can change FDN
mode based on STK refresh. If it sends us such a command and FDN is now
enabled, we should remove all atoms except pre-sim, as they are no
longer relevant. If we start oFono up and FDN is enabled, the atoms
won't be present, why is the case via refresh different?
You're right, my logic has failed somewhere.. I see that the
RESET_STATE_INSERTED state is actually unneeded, it should just be
same as NOT_PRESENT and drop all post-sim atoms and then potentially
re-create.
+ break;
+ case RESET_STATE_READY:
+ sim-state = OFONO_SIM_STATE_INSERTED;
+ for (l = sim-state_watches-items; l; l = l-next) {
+ struct ofono_watchlist_item *item = l-data;
+ ofono_sim_state_event_cb_t notify = item-notify;
+
+ notify(sim-state, item-notify_data);
I'm having trouble understanding the need for this for loop. Isn't the
SIM already inserted?
I initially didn't have this loop, but I thought it might be better to
signal INSERTED just before READY, so that atoms see a *change* if
they though that the sim was READY before. But looking at the current
users of the sim state watch, it makes no difference.
Then lets drop it.
Overall it seems like there are two categories of files that we should
worry about:
- Those handled inside sim.c that affect sim initialization:
- EFust, EFest, EFsst
- EFbdn, EFfdn
- EFphase, EFcphs_info (these ones are really unlikely outside of a
full sim reset)
- EFad (This one is unlikely as it would affect the IMSI)
- The ones that don't
To me it sounds like we should just special case the ones affecting sim
initialization inside this function and use a simplified API for the rest.
So I think this wouldn't make the api much better because:
* These files you listed are the majority of all files we read, so the
normal users are in minority.
I'm not so sure, I counted at least 15 instances of 'normal' files.
* The only simplification I see would be removal of one parameter in
add_file_watch_call
int ofono_sim_add_file_watch(struct ofono_sim *sim, int id,
enum ofono_sim_state reset_state,
ofono_sim_file_notify_t notify, void *userdata);
or are you thinking about a different simplifaction?
Yes, I would yang the reset_state parameter. That one is really
confusing and not needed outside the sim atom anyway. So my proposal is
to make this as complicated as you need inside sim atom, but expose a
specialized API to the rest of the system.
Ok, sounds good.
Best regards
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] voice call API changes (proposal)
Hi Andras,
On 01/31/2011 05:56 AM, Andras Domokos wrote:
Here is a proposal for expanding the VoiceCallManager interface with
call related Supplementary Services signals, and the VoiceCall
interface with new properties.
---
doc/call-barring-api.txt | 10 --
doc/voicecall-api.txt| 15 +++
doc/voicecallmanager-api.txt | 21 +
3 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/doc/call-barring-api.txt b/doc/call-barring-api.txt
index 41ae4b1..1534494 100644
--- a/doc/call-barring-api.txt
+++ b/doc/call-barring-api.txt
@@ -37,16 +37,6 @@ SignalsPropertyChanged(string property,
variant value)
Signal is emitted whenever a property has changed.
The new value is passed as the signal argument.
- IncomingBarringInEffect()
-
- Signal is emitted when a call is made and an
- incoming call barring supplementary service is in use.
-
- OutgoingBarringInEffect()
-
- Signal is emitted when a call is made and an
- outgoing call barring supplementary service is in use.
-
Properties string VoiceIncoming [readwrite]
Contains the value of the barrings for the incoming
diff --git a/doc/voicecall-api.txt b/doc/voicecall-api.txt
index 047b8cb..e7276a3 100644
--- a/doc/voicecall-api.txt
+++ b/doc/voicecall-api.txt
@@ -145,3 +145,18 @@ Properties string LineIdentification [readonly]
Contains the indication if the voice call is an
emergency call or not.
+
+ boolean Forwarded
+
+ Contains the indication whether the voice call is a
+ forwarded call or not.
+
So just to clarify, this is usually set on a local Incoming / Waiting
call, correct?
+ boolean RemoteHold
+
+ Contains the indication whether the voice call has been
+ put on hold by the remote party or not.
+
This one is rather tricky, since AT modems do not report the index of
the call. So the only way you can report this is if you have only a
single call active or your modem supports this properly (I know ISI does).
+ boolean Waiting
+
+ Contains the indication whether the outgoing voice call
+ is waiting or not.
And this is for a local dialing / alerting call. Correct?
diff --git a/doc/voicecallmanager-api.txt b/doc/voicecallmanager-api.txt
index 2bf9ded..bbd80db 100644
--- a/doc/voicecallmanager-api.txt
+++ b/doc/voicecallmanager-api.txt
@@ -144,6 +144,27 @@ Signals CallAdded(object path, dict properties)
Signal is emitted whenever a property has changed.
The new value is passed as the signal argument.
+ UnconditionalForwardingInEffect
+
+ Signal is emitted when a call is made and unconditional
+ call forwarding supplementary service is active.
This is for a local dialing / alerting call. Correct?
+
+ ConditionalForwardingInEffect
+
+ Signal is emitted when a call is made and some of the
+ conditional call forwarding supplementary services are
+ active.
+
Same as above?
+ IncomingBarringInEffect()
+
+ Signal is emitted when a call is made and an
+ incoming call barring supplementary service is in use.
+
For local outgoing calls telling that the remote side has incoming
barring active?
+ OutgoingBarringInEffect()
+
+ Signal is emitted when a call is made and an
+ outgoing call barring supplementary service is in use.
+
And this one telling you that local outgoing barring is active?
Properties array{string} EmergencyNumbers [readonly]
Contains the list of emergency numbers recognized
Generally I'm fine with these but please document them a bit more
clearly, and we might have to pick names that make a bit more sense.
Other than that, you're missing the mpty join indications that Pekka had
in his earlier proposal. These suffer from the same problem as RemoteHold.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 0/3] EF-SPN API to sim-atom
Hi Jukka, On 01/31/2011 12:13 AM, Jukka Saunamaki wrote: Hello On Thu, 2011-01-27 at 15:22 +0200, Jukka Saunamaki wrote: Here is an asynchronous implementation of SIM Service Provider Name (EF-SPN) getter API. The trick is to delay setting sim ready until spn reading is finished. Any comments about this? So, yes, it slightly delays SIM initialisation (usually SPN value should come from disk cache), but then netreg can use it immediately when it registers. Alternative is still to create an asyncronous API now that there is a patch for safe SIM file reading. So my main problem here is that you require the SPN a handful of times in the phone's lifetime, more likely once. Yet you pay the cost of reading and delaying the initialization every time. In my view this is not really acceptable. Perhaps a better approach would be to put the spn parser into simutil so it can be shared by netreg and gprs. Then go back to your original proposal of delaying the gprs atom registration if provisioning is required and SPN is needed. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
[PATCH 1/8] bluetooth: add server support
Initial code to have support to listen over a RFCOMM socket for incoming
connections.
---
Makefile.am |1 +
plugins/bluetooth.c | 165 +++
plugins/bluetooth.h | 11
3 files changed, 177 insertions(+), 0 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index a38fcb9..77b1453 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -321,6 +321,7 @@ builtin_sources += plugins/bluetooth.c plugins/bluetooth.h
builtin_modules += hfp
builtin_sources += plugins/hfp.c plugins/bluetooth.h
+builtin_sources += $(btio_sources)
builtin_cflags += @BLUEZ_CFLAGS@
builtin_libadd += @BLUEZ_LIBS@
endif
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 93dd7a1..dcf75e6 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -35,13 +35,58 @@
#include ofono/dbus.h
+#include btio.h
#include bluetooth.h
static DBusConnection *connection;
static GHashTable *uuid_hash = NULL;
static GHashTable *adapter_address_hash = NULL;
+static GSList *server_list = NULL;
static gint bluetooth_refcount;
+struct server {
+ guint16 service;
+ gchar *name;
+ guint8 channel;
+ GIOChannel *io;
+ char*adapter;
+ guint handle;
+ ConnectFunc connect_cb;
+ gpointeruser_data;
+};
+
+typedef struct {
+ guint8 b[6];
+} __attribute__((packed)) bdaddr_t;
+
+static void baswap(bdaddr_t *dst, const bdaddr_t *src)
+{
+ register unsigned char *d = (unsigned char *) dst;
+ register const unsigned char *s = (const unsigned char *) src;
+ register int i;
+
+ for (i = 0; i 6; i++)
+ d[i] = s[5-i];
+}
+
+static int str2ba(const char *str, bdaddr_t *ba)
+{
+ guint8 b[6];
+ const char *ptr = str;
+ int i;
+
+ for (i = 0; i 6; i++) {
+ b[i] = (guint8) strtol(ptr, NULL, 16);
+ if (i != 5 !(ptr = strchr(ptr, ':')))
+ ptr = :00:00:00:00:00;
+ ptr++;
+ }
+
+ baswap(ba, (bdaddr_t *) b);
+
+ return 0;
+}
+
void bluetooth_create_path(const char *dev_addr, const char *adapter_addr,
char *buf, int size)
{
@@ -371,6 +416,70 @@ static gboolean property_changed(DBusConnection
*connection, DBusMessage *msg,
return TRUE;
}
+static void server_stop(gpointer data)
+{
+ struct server *server = data;
+
+ if (server-handle 0) {
+ DBusMessage *msg;
+
+ msg = dbus_message_new_method_call(BLUEZ_SERVICE,
+ server-adapter,
+ BLUEZ_SERVICE_INTERFACE,
+ RemoveRecord);
+ dbus_message_append_args(msg, DBUS_TYPE_UINT32, server-handle,
+ DBUS_TYPE_INVALID);
+ g_dbus_send_message(connection, msg);
+
+ server-handle = 0;
+ }
+
+ if (server-io != NULL) {
+ g_io_channel_shutdown(server-io, TRUE, NULL);
+ g_io_channel_unref(server-io);
+ server-io = NULL;
+ }
+
+ g_free(server-adapter);
+ server-adapter = NULL;
+}
+
+static void new_connection(GIOChannel *io, gpointer user_data)
+{
+ struct server *server = user_data;
+
+ DBG(%p, server);
+}
+
+static void server_start(gpointer data, gpointer user_data)
+{
+ struct server *server = data;
+ char *addr, *path = user_data;
+ bdaddr_t baddr;
+ GError *err = NULL;
+
+ if (server-handle != 0)
+ return;
+
+ addr = g_hash_table_lookup(adapter_address_hash, path);
+ str2ba(addr, baddr);
+ server-io = bt_io_listen(BT_IO_RFCOMM, NULL, new_connection,
+ server, NULL, err,
+ BT_IO_OPT_SOURCE_BDADDR, baddr,
+ BT_IO_OPT_CHANNEL, server-channel,
+ BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_MEDIUM,
+ BT_IO_OPT_INVALID);
+ if (server-io == NULL) {
+ ofono_error(Bluetooth %s register failed: %s,
+ server-name, err-message);
+ g_error_free(err);
+ server_stop(server);
+ return;
+ }
+
+ server-adapter = g_strdup(path);
+}
+
static void adapter_properties_cb(DBusPendingCall *call, gpointer user_data)
{
const char *path = user_data;
@@ -395,6 +504,9 @@ static void adapter_properties_cb(DBusPendingCall *call,
gpointer user_data)
g_hash_table_insert(adapter_address_hash,
g_strdup(path), g_strdup(addr));
+ if (server_list)
+ g_slist_foreach(server_list, server_start, (gpointer)path);
+
for (l = device_list;
[PATCH 2/8] bluetooth: add support to register Bluetooth Service
---
plugins/bluetooth.c | 75 +++
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index dcf75e6..0b5a021 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -44,6 +44,43 @@ static GHashTable *adapter_address_hash = NULL;
static GSList *server_list = NULL;
static gint bluetooth_refcount;
+static const gchar *dun_record = ?xml version=\1.0\ encoding=\UTF-8\ ?
\
+record
\
+ attribute id=\0x0001\
\
+sequence
\
+ uuid value=\0x1103\/
\
+/sequence
\
+ /attribute
\
+
\
+ attribute id=\0x0004\
\
+sequence
\
+ sequence
\
+uuid value=\0x0100\/
\
+ /sequence
\
+ sequence
\
+uuid value=\0x0003\/
\
+uint8 value=\%u\ name=\channel\/
\
+ /sequence
\
+ sequence
\
+uuid value=\0x0008\/
\
+ /sequence
\
+/sequence
\
+ /attribute
\
+
\
+ attribute id=\0x0009\
\
+sequence
\
+ sequence
\
+uuid value=\0x1103\/
\
+uint16 value=\0x0100\ name=\version\/
\
+ /sequence
\
+/sequence
\
+ /attribute
\
+
\
+ attribute id=\0x0100\
\
+text value=\%s\ name=\name\/
\
+ /attribute
\
+/record;
+
struct server {
guint16 service;
gchar *name;
@@ -451,12 +488,40 @@ static void new_connection(GIOChannel *io, gpointer
user_data)
DBG(%p, server);
}
+static void add_record_cb(DBusPendingCall *call, gpointer user_data)
+{
+ struct server *server = user_data;
+ DBusMessage *reply = dbus_pending_call_steal_reply(call);
+ DBusError derr;
+ guint32 handle;
+
+ dbus_error_init(derr);
+
+ if (dbus_set_error_from_message(derr, reply)) {
+ ofono_error(Replied with an error: %s, %s,
+ derr.name, derr.message);
+ dbus_error_free(derr);
+ server_stop(server);
+ goto done;
+ }
+
+ dbus_message_get_args(reply, NULL, DBUS_TYPE_UINT32, handle,
+ DBUS_TYPE_INVALID);
+ server-handle = handle;
+
+ ofono_info(Registered: %s, handle: 0x%x, server-name, handle);
+
+done:
+ dbus_message_unref(reply);
+}
+
static void server_start(gpointer data, gpointer user_data)
{
struct server *server = data;
char *addr, *path = user_data;
bdaddr_t baddr;
GError *err = NULL;
+ gchar *xml;
if (server-handle != 0)
return;
@@ -478,6 +543,16 @@ static void server_start(gpointer data, gpointer user_data)
}
server-adapter = g_strdup(path);
+
+ xml = g_markup_printf_escaped(dun_record, server-channel,
+ server-name);
+
+ bluetooth_send_with_reply(path, BLUEZ_SERVICE_INTERFACE, AddRecord,
+ add_record_cb, server, NULL, -1,
+
[PATCH 3/8] bluetooth: add Request auth code for new connections
Now a RFCOMM incoming connection can be made, all the pieces are here.
---
plugins/bluetooth.c | 123 ++-
1 files changed, 122 insertions(+), 1 deletions(-)
diff --git a/plugins/bluetooth.c b/plugins/bluetooth.c
index 0b5a021..f3b9140 100644
--- a/plugins/bluetooth.c
+++ b/plugins/bluetooth.c
@@ -90,6 +90,9 @@ struct server {
guint handle;
ConnectFunc connect_cb;
gpointeruser_data;
+ gbooleanpending_auth;
+ GIOChannel *client_io;
+ guint client_watch;
};
typedef struct {
@@ -453,10 +456,25 @@ static gboolean property_changed(DBusConnection
*connection, DBusMessage *msg,
return TRUE;
}
+static void disconnect(struct server *server)
+{
+ if (server-client_io == NULL)
+ return;
+
+ server-client_io = NULL;
+
+ if (server-client_watch 0) {
+ g_source_remove(server-client_watch);
+ server-client_watch = 0;
+ }
+}
+
static void server_stop(gpointer data)
{
struct server *server = data;
+ disconnect(server);
+
if (server-handle 0) {
DBusMessage *msg;
@@ -481,11 +499,114 @@ static void server_stop(gpointer data)
server-adapter = NULL;
}
+static void cancel_authorization(struct server *server)
+{
+ DBusMessage *msg;
+
+ msg = dbus_message_new_method_call(BLUEZ_SERVICE, server-adapter,
+ BLUEZ_SERVICE_INTERFACE, CancelAuthorization);
+ if (!msg)
+ return;
+
+ g_dbus_send_message(connection, msg);
+}
+
+static void auth_cb(DBusPendingCall *call, gpointer user_data)
+{
+ struct server *server = user_data;
+ DBusMessage *reply = dbus_pending_call_steal_reply(call);
+ DBusError derr;
+ GError *err = NULL;
+
+ dbus_error_init(derr);
+
+ server-pending_auth = FALSE;
+
+ if (dbus_set_error_from_message(derr, reply)) {
+ ofono_error(RequestAuthorization error: %s, %s,
+ derr.name, derr.message);
+
+ if (dbus_error_has_name(derr, DBUS_ERROR_NO_REPLY))
+ cancel_authorization(server);
+
+ dbus_error_free(derr);
+ goto failed;
+ }
+
+ ofono_info(RequestAuthorization() succeeded);
+
+ if (!bt_io_accept(server-client_io, server-connect_cb,
+ server-user_data, NULL, err)) {
+ ofono_error(%s, err-message);
+ g_error_free(err);
+ goto failed;
+ }
+ return;
+
+failed:
+ dbus_message_unref(reply);
+ disconnect(server);
+}
+
+static gboolean client_event(GIOChannel *io, GIOCondition cond,
+ gpointer user_data)
+{
+ struct server *server = user_data;
+
+ if (server-pending_auth == TRUE)
+ cancel_authorization(server);
+
+ server-pending_auth = FALSE;
+
+ disconnect(server);
+
+ return FALSE;
+}
+
static void new_connection(GIOChannel *io, gpointer user_data)
{
struct server *server = user_data;
+ GError *err = NULL;
+ char address[18];
+ const char *addr;
+ guint8 channel;
+ int ret;
+
+ if (server-client_watch != 0) {
+ ofono_info(Client already connected);
+ return;
+ }
+
+ bt_io_get(io, BT_IO_RFCOMM, err, BT_IO_OPT_DEST, address,
+ BT_IO_OPT_CHANNEL, channel,
+ BT_IO_OPT_INVALID);
+ if (err) {
+ ofono_error(%s, err-message);
+ g_error_free(err);
+ return;
+ }
+
+ ofono_info(New connection from: %s, channel %u, address, channel);
+
+ addr = address;
+ ret = bluetooth_send_with_reply(server-adapter,
+ BLUEZ_SERVICE_INTERFACE,
+ RequestAuthorization,
+ auth_cb, server, NULL, DBUS_TIMEOUT,
+ DBUS_TYPE_STRING, addr,
+ DBUS_TYPE_UINT32, server-handle,
+ DBUS_TYPE_INVALID);
+ if (ret 0) {
+ ofono_error(RequestAuthorization() failed);
+ return;
+ }
+
+ server-client_io = io;
+ server-client_watch = g_io_add_watch(server-client_io,
+ G_IO_NVAL | G_IO_HUP | G_IO_ERR,
+ client_event, server);
- DBG(%p, server);
+ server-pending_auth = TRUE;
}
static void add_record_cb(DBusPendingCall *call, gpointer user_data)
--
1.7.4.rc3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 5/8] emulator: Add emulator atom in oFono
Create emulator atom when modem state changes to online. The emulator
driver probes each driver to create specific emulator like DUN, HFP AG,
etc. Once get client connection request, create GAtServer to talk AT
commands with client side.
Based on a patch from Zhenhua Zhang zhenhua.zh...@intel.com
---
Makefile.am|5 +-
include/emulator.h |5 +-
src/emulator.c | 281
src/ofono.h|5 +
4 files changed, 291 insertions(+), 5 deletions(-)
create mode 100644 src/emulator.c
diff --git a/Makefile.am b/Makefile.am
index 77b1453..1ca08e9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,7 @@ pkginclude_HEADERS = include/log.h include/plugin.h
include/history.h \
include/audio-settings.h include/nettime.h \
include/ctm.h include/cdma-voicecall.h \
include/cdma-sms.h include/sim-auth.h \
- include/gprs-provision.h
+ include/gprs-provision.h include/emulator.h
nodist_pkginclude_HEADERS = include/version.h
@@ -363,7 +363,8 @@ src_ofonod_SOURCES = $(gdbus_sources) $(builtin_sources)
src/ofono.ver \
src/simfs.c src/simfs.h src/audio-settings.c \
src/smsagent.c src/smsagent.h src/ctm.c \
src/cdma-voicecall.c src/sim-auth.c \
- src/message.h src/message.c src/gprs-provision.c
+ src/message.h src/message.c src/gprs-provision.c \
+ src/emulator.c
src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ -ldl
diff --git a/include/emulator.h b/include/emulator.h
index 1287b47..bc89071 100644
--- a/include/emulator.h
+++ b/include/emulator.h
@@ -33,9 +33,8 @@ struct ofono_emulator;
struct ofono_emulator_driver {
const char *name;
enum ofono_atom_type type;
- int (*probe)(struct ofono_emulator *emulator,
- struct ofono_modem *modem);
- void (*remove)();
+ int (*probe)(struct ofono_emulator *emulator);
+ void (*remove)(void);
};
int ofono_emulator_enable(struct ofono_emulator *emulator, int fd);
diff --git a/src/emulator.c b/src/emulator.c
new file mode 100644
index 000..aa71e21
--- /dev/null
+++ b/src/emulator.c
@@ -0,0 +1,281 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include stdio.h
+#include string.h
+#include errno.h
+#include glib.h
+#include gdbus.h
+
+#include ofono.h
+#include common.h
+#include gatserver.h
+
+struct ofono_emulator {
+ struct ofono_modem *modem;
+ struct ofono_atom *atom;
+ GAtServer *server;
+ struct ofono_emulator_driver *driver;
+};
+
+static GSList *emulator_drivers = NULL;
+
+static void ofono_emulator_debug(const char *str, void *data)
+{
+ g_print(%s: %s\n, (char *)data, str);
+}
+
+void ofono_emulator_remove(struct ofono_emulator *emulator)
+{
+ if (emulator == NULL)
+ return;
+
+ __ofono_atom_free(emulator-atom);
+}
+
+static void ppp_connect(const char *iface, const char *local,
+ const char *remote,
+ const char *dns1, const char *dns2,
+ gpointer user_data)
+{
+ DBG(Network Device: %s\n, iface);
+ DBG(IP Address: %s\n, local);
+ DBG(Remote IP Address: %s\n, remote);
+ DBG(Primary DNS Server: %s\n, dns1);
+ DBG(Secondary DNS Server: %s\n, dns2);
+}
+
+static void ppp_disconnect(GAtPPPDisconnectReason reason, gpointer user_data)
+{
+ struct ofono_emulator *e = user_data;
+
+ DBG();
+
+ g_at_ppp_unref(e-ppp);
+ e-ppp = NULL;
+
+ if (e-server == NULL)
+ return;
+
+ g_at_server_resume(e-server);
+
+ g_at_server_send_final(e-server, G_AT_SERVER_RESULT_NO_CARRIER);
+}
+
+static gboolean setup_ppp(gpointer user_data)
+{
+ struct ofono_emulator *e = user_data;
+ GAtServer *server = e-server;
+ GAtIO *io;
+
+ DBG();
+
+ io = g_at_server_get_io(server);
+
+ g_at_server_suspend(server);
+
+ e-ppp =
[PATCH 6/8] dun_gw: Add DUN server plugin for oFono
DUN server is probed when modem state changes to online. It registers
DUN record to Bluetooth adapter and wait for incoming DUN connection.
Based on a patch from Zhenhua Zhang zhenhua.zh...@intel.com
---
Makefile.am |3 +
plugins/bluetooth.h |3 +
plugins/dun_gw.c| 156 +++
3 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 plugins/dun_gw.c
diff --git a/Makefile.am b/Makefile.am
index 1ca08e9..1794ace 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -321,6 +321,9 @@ builtin_sources += plugins/bluetooth.c plugins/bluetooth.h
builtin_modules += hfp
builtin_sources += plugins/hfp.c plugins/bluetooth.h
+builtin_modules += dun_gw
+builtin_sources += plugins/dun_gw.c plugins/bluetooth.h
+
builtin_sources += $(btio_sources)
builtin_cflags += @BLUEZ_CFLAGS@
builtin_libadd += @BLUEZ_LIBS@
diff --git a/plugins/bluetooth.h b/plugins/bluetooth.h
index f6fc6a6..7a6c858 100644
--- a/plugins/bluetooth.h
+++ b/plugins/bluetooth.h
@@ -32,6 +32,9 @@
/* Profiles bitfield */
#define HFP_AG 0x01
+/* Server bitfield */
+#define DUN_GW 0x01
+
struct bluetooth_profile {
const char *name;
int (*create)(const char *device, const char *dev_addr,
diff --git a/plugins/dun_gw.c b/plugins/dun_gw.c
new file mode 100644
index 000..78b87e2
--- /dev/null
+++ b/plugins/dun_gw.c
@@ -0,0 +1,156 @@
+/*
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2010 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+#include stdio.h
+#include string.h
+#include errno.h
+#include glib.h
+#include ofono.h
+
+#define OFONO_API_SUBJECT_TO_CHANGE
+#include ofono/plugin.h
+#include ofono/log.h
+#include ofono/modem.h
+#include gdbus.h
+
+#include bluetooth.h
+
+#define DUN_GW_CHANNEL 1
+
+static struct server *server;
+static guint modemwatch_id;
+static guint channel_watch;
+
+static gboolean dun_gw_disconnect_cb(GIOChannel *io, GIOCondition cond,
+ gpointer user_data)
+{
+ struct ofono_emulator *emulator = user_data;
+
+ ofono_emulator_disable(emulator);
+
+ return FALSE;
+}
+
+static void dun_gw_connect_cb(GIOChannel *io, GError *err, gpointer user_data)
+{
+ struct ofono_emulator *emulator = user_data;
+ int fd;
+
+ DBG();
+
+ if (err) {
+ DBG(%s, err-message);
+ return;
+ }
+
+ fd = g_io_channel_unix_get_fd(io);
+
+ if (ofono_emulator_enable(emulator, fd) 0)
+ goto failed;
+
+ channel_watch = g_io_add_watch(io, G_IO_NVAL | G_IO_HUP | G_IO_ERR,
+ dun_gw_disconnect_cb, emulator);
+
+ return;
+
+failed:
+ g_io_channel_shutdown(io, TRUE, NULL);
+ server = NULL;
+}
+
+static int dun_gw_probe(struct ofono_emulator *emulator)
+{
+ if (server)
+ return -EEXIST;
+
+ DBG();
+
+ server = bluetooth_register_server(DUN_GW, Dial-Up Networking,
+ DUN_GW_CHANNEL, dun_gw_connect_cb, emulator);
+
+ return 0;
+}
+
+static void dun_gw_remove(void)
+{
+ if (server == NULL)
+ return;
+
+ DBG();
+
+ bluetooth_unregister_server(server);
+ server = NULL;
+}
+
+static void gprs_watch(struct ofono_atom *atom,
+ enum ofono_atom_watch_condition cond,
+ void *data)
+{
+ struct ofono_modem *modem = data;
+
+ if (cond == OFONO_ATOM_WATCH_CONDITION_UNREGISTERED)
+ return;
+
+ __ofono_emulator_probe_drivers(modem);
+}
+
+static void modem_watch(struct ofono_modem *modem, gboolean added, void *user)
+{
+ DBG(modem: %p, added: %d, modem, added);
+
+ if (added == FALSE)
+ return;
+
+ __ofono_modem_add_atom_watch(modem, OFONO_ATOM_TYPE_GPRS,
+ gprs_watch, modem, NULL);
+}
+
+static void call_modemwatch(struct ofono_modem *modem, void *user)
+{
+ modem_watch(modem, TRUE, user);
+}
+
+static struct ofono_emulator_driver emulator_driver = {
+ .name = Dial-Up Networking,
+ .type = OFONO_ATOM_TYPE_EMULATOR_DUN,
+ .probe = dun_gw_probe,
+ .remove =
[PATCH 7/8] emulator: Implement dialing up for DUN
It handles client ATD*99# request and then initiate the PPP negotiation.
IP forward through the new ppp interface is not done yet.
Initially based on patches from Zhenhua Zhang zhenhua.zh...@intel.com
---
src/emulator.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/src/emulator.c b/src/emulator.c
index aa71e21..12e801d 100644
--- a/src/emulator.c
+++ b/src/emulator.c
@@ -32,11 +32,18 @@
#include ofono.h
#include common.h
#include gatserver.h
+#include gatppp.h
+
+#define DUN_SERVER_ADDRESS 192.168.1.1
+#define DUN_PEER_ADDRESS 192.168.1.2
+#define DUN_DNS_SERVER_1 10.10.10.10
+#define DUN_DNS_SERVER_2 10.10.10.11
struct ofono_emulator {
struct ofono_modem *modem;
struct ofono_atom *atom;
GAtServer *server;
+ GAtPPP *ppp;
struct ofono_emulator_driver *driver;
};
@@ -167,6 +174,12 @@ void ofono_emulator_disable(struct ofono_emulator *e)
{
DBG();
+ if (e-ppp) {
+ g_at_ppp_shutdown(e-ppp);
+ g_at_ppp_unref(e-ppp);
+ e-ppp = NULL;
+ }
+
g_at_server_shutdown(e-server);
g_at_server_unref(e-server);
e-server = NULL;
@@ -201,6 +214,8 @@ int ofono_emulator_enable(struct ofono_emulator *e, int fd)
g_at_server_set_disconnect_function(e-server,
emulator_disconnect_cb, e);
+ g_at_server_register(e-server, D, dial_cb, e, NULL);
+
return 0;
}
--
1.7.4.rc3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
[PATCH 8/8] gsmdial: add option for Bluetooth DUN dialing
---
gatchat/gsmdial.c | 17 ++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/gatchat/gsmdial.c b/gatchat/gsmdial.c
index 1be80e3..d54a26e 100644
--- a/gatchat/gsmdial.c
+++ b/gatchat/gsmdial.c
@@ -56,6 +56,7 @@ static gboolean option_legacy = FALSE;
static gchar *option_username = NULL;
static gchar *option_password = NULL;
static gchar *option_pppdump = NULL;
+static gboolean option_bluetooth = 0;
static GAtPPP *ppp;
static GAtChat *control;
@@ -266,6 +267,9 @@ static void no_carrier_notify(GAtResult *result, gpointer
user_data)
{
char buf[64];
+ if (option_bluetooth)
+ return;
+
sprintf(buf, AT+CFUN=%u, option_offmode);
g_at_chat_send(control, buf, none_prefix, power_down, NULL, NULL);
}
@@ -612,6 +616,8 @@ static GOptionEntry options[] = {
Specify CFUN offmode },
{ legacy, 'l', 0, G_OPTION_ARG_NONE, option_legacy,
Use ATD*99***cid# },
+ { bluetooth, 'b', 0, G_OPTION_ARG_NONE, option_bluetooth,
+ Use only ATD*99 },
{ username, 'u', 0, G_OPTION_ARG_STRING, option_username,
Specify PPP username },
{ password, 'w', 0, G_OPTION_ARG_STRING, option_password,
@@ -700,9 +706,14 @@ int main(int argc, char **argv)
event_loop = g_main_loop_new(NULL, FALSE);
- g_at_chat_send(control, ATE0Q0V1, NULL, NULL, NULL, NULL);
- g_at_chat_send(control, AT+CFUN?, cfun_prefix,
- check_mode, NULL, NULL);
+ if (option_bluetooth) {
+ g_at_chat_send(control, ATD*99, none_prefix, connect_cb,
+ NULL, NULL);
+ } else {
+ g_at_chat_send(control, ATE0Q0V1, NULL, NULL, NULL, NULL);
+ g_at_chat_send(control, AT+CFUN?, cfun_prefix,
+ check_mode, NULL, NULL);
+ }
g_main_loop_run(event_loop);
g_source_remove(signal_source);
--
1.7.4.rc3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
