Re: [RFC v0 02/13] hfp_hf_bluez5: Register handsfree audio driver
Hi Denis:
snip
if (err 0) {
+ ofono_handsfree_card_driver_register(card_driver15);
I will fix it in the next series. Copy paste error: It is unregister
instead of register.
g_dbus_unregister_interface(conn, HFP_EXT_PROFILE_PATH,
BLUEZ_PROFILE_INTERFACE);
return err;
@@ -647,6 +675,7 @@ static void hfp_exit(void)
g_dbus_unregister_interface(conn, HFP_EXT_PROFILE_PATH,
BLUEZ_PROFILE_INTERFACE);
ofono_modem_driver_unregister(hfp_driver);
+ ofono_handsfree_card_driver_register(card_driver15);
Same here.
g_dbus_client_unref(bluez);
ofono_handsfree_audio_unref();
--
1.7.11.7
Regards,
Claudio
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Randomly SMS sent passes or fails
On 06. 03. 13 10:23, Viallard Anthony wrote: On 05. 03. 13 21:43, Denis Kenzior wrote: Nope, can't really help here; perhaps if you shared a detailed AT log? Regards, -Denis I tried to find some information about the operator and SMS/GPRS. I didn't find documentation in my fluent language. I will ask to a german guy. Maybe, there are a AT command to know wether operator supports this ? Otherwise, I try to find documentation about this amazing SMS over GPRS feature. From what I read, there an AT command to select the behavior. I guess it's the AT+CGSMS command. Ofono set CGSMS to 3 : AT+CGSMS=3 From the modem documentation, I see : A numeric parameter which indicates the service or service preference to be used 0 – GPRS(value is not really supported and is internally mapped to 2) 1 – circuit switched(value is not really supported and is internally mapped to 3) 2 – GPRS preferred (use circuit switched if GPRS not available) 3 – circuit switched preferred (use GPRS if circuit switched not available) Maybe the circuit switched has got some troubles on the operator network and as I disabled GPRS, the SMS sending failed most of the time ? There also the command AT+CSMS : +CSMS: 1,1,1 The first 1 tells the SMS at command is compatible with GSM phase 2+.. Perhaps, the thing has an impact about the issue ... Any comments ? :( Before, I tested with 1.6. And, today, I tried with 1.12. And, I've got some troubles at modem power up... During the 3 first start, ofono was blocked after sending a command. Here 2 pastes : -- [...] ofonod[13400]: drivers/atmodem/cbs.c:at_cbs_set_topics() ofonod[13400]: Data: AT+CSCB=0,4352-4356\r ofonod[13400]: Data: \r\nOK\r\n ofonod[13400]: Data: AT+CRSM=192,28437\r ofonod[13400]: Data: \r\n+CRSM: 106,130,\r\n\r\nOK\r\n ofonod[13400]: Data: AT+CRSM=192,28436\r -- -- [...] ofonod[10387]: src/network.c:ofono_netreg_status_notify() /simcom_0 status 1 tech -1 ofonod[10387]: src/cbs.c:cbs_location_changed() 1, -1, -1, -1, (null)(null) ofonod[10387]: Data: AT+CRSM=192,28480\r ofonod[10387]: Data: \r\n+CRSM: 144,0,\r\n\r\nOK\r\n ofonod[10387]: drivers/atmodem/sim.c:at_crsm_info_cb() crsm_info_cb: 90, 00, 0 ofonod[10387]: Data: AT+CMGF=?\r -- As you can see, It's not always at the same moment. After that, I can't send AT command anymore, the modem seems to be locked. I try to debug this and found the CMUX and CMUXSRVPORT ports. I can have a DIAG port, so, I try to configure it. I stopped ofono, the modem and sent these commands : -- AT+CMUXSRVPORT=0, 0 AT+CMUXSRVPORT=1, 5 AT+CMUXSRVPORT=2, 1 AT+CMUXSRVPORT=3, 1 +CMUX=0 -- -- AT+CMUXSRVPORT -- port : virtual com port 0 – 3 currently support 4 virtual com ports index from 0 to 3 service : valid service 0 – DIAG Service 1 – DATA(MODEM) Service 5 – NMEA Service -- And now, each time I start ofono and power up the modem, it works. No lock. Hum, I'm disapointed. I didn't think theses commands could fix the problem. And, no messages in diag or NMEA tty. Hum... And moreover, now all SMS I send are received. No failure. So good news, but, I'm troubled. After grepping on ofono source, I see some driver plugins do a CMUX set (calipso, phonesim). Maybe, I need to execute a CMUX set ??? It can be important ? Nevertheless, I don't understand why I have problems with this T-Mobile SIM card and not with Vodafone for example... Regards, Anthony. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC v0 11/13] handsfree-audio: Add sending SCO fd
Hi Claudio,
On Fri, Mar 08, 2013, Claudio Takahasi wrote:
This patch adds the call of NewConnection method when the SCO connection
is established for HF initiated scenarios.
---
src/handsfree-audio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/handsfree-audio.c b/src/handsfree-audio.c
index f5d0a7b..6fa8b67 100644
--- a/src/handsfree-audio.c
+++ b/src/handsfree-audio.c
@@ -242,12 +242,19 @@ static gboolean sco_connect_cb(GIOChannel *io,
GIOCondition cond,
{
struct ofono_handsfree_card *card = user_data;
DBusMessage *reply;
+ int sk;
if (cond (G_IO_ERR | G_IO_HUP | G_IO_NVAL)) {
reply = __ofono_error_failed(card-msg);
goto done;
}
+ sk = g_io_channel_unix_get_fd(io);
+
+ send_new_connection(card-path, sk);
+
+ close(sk);
+
reply = dbus_message_new_method_return(card-msg);
Shouldn't you be adding a watch for the connected SCO socket instead of
closing it? Is it not necessary for oFono to know the SCO state? (to
detect when PA did shutdown() on the socket, return already connected
for Connect(), etc.)
Johan
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC v0 11/13] handsfree-audio: Add sending SCO fd
Hi Johan:
On Mon, Mar 11, 2013 at 11:55 AM, Johan Hedberg johan.hedb...@gmail.com wrote:
Hi Claudio,
On Fri, Mar 08, 2013, Claudio Takahasi wrote:
This patch adds the call of NewConnection method when the SCO connection
is established for HF initiated scenarios.
---
src/handsfree-audio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/handsfree-audio.c b/src/handsfree-audio.c
index f5d0a7b..6fa8b67 100644
--- a/src/handsfree-audio.c
+++ b/src/handsfree-audio.c
@@ -242,12 +242,19 @@ static gboolean sco_connect_cb(GIOChannel *io,
GIOCondition cond,
{
struct ofono_handsfree_card *card = user_data;
DBusMessage *reply;
+ int sk;
if (cond (G_IO_ERR | G_IO_HUP | G_IO_NVAL)) {
reply = __ofono_error_failed(card-msg);
goto done;
}
+ sk = g_io_channel_unix_get_fd(io);
+
+ send_new_connection(card-path, sk);
+
+ close(sk);
+
reply = dbus_message_new_method_return(card-msg);
Shouldn't you be adding a watch for the connected SCO socket instead of
closing it? Is it not necessary for oFono to know the SCO state? (to
detect when PA did shutdown() on the socket, return already connected
for Connect(), etc.)
In the current implementation if the user calls Connect and the audio
connection is established already, Handsfree Audio Card returns
'org.ofono.Error.Failed: Operation failed'
In the current API, it is not necessary to track the state or emit
signals. I prefer to keep this simple approach than add additional
logic to track incoming/outgoing SCO connections.
We can improve it later if necessary, as soon as Denis pushes the
basic functionality we can fix the corner cases and issues like this
one.
Regards,
Claudio.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 02/13] dundee: Start BlueZ 5 support
Hi Paulo, I guess, I am in charge to review your patches. Let's start then :) Just a nitpick in this one. On 03/04/2013 08:33 PM, Paulo Borges wrote: This patch adds the BlueZ 5 support file for dundee. --- Makefile.am | 16 ++-- dundee/bluez5.c | 37 + 2 files changed, 47 insertions(+), 6 deletions(-) create mode 100644 dundee/bluez5.c diff --git a/Makefile.am b/Makefile.am index ed35988..1748d06 100644 --- a/Makefile.am +++ b/Makefile.am @@ -756,24 +756,28 @@ endif endif if BLUETOOTH -if BLUEZ4 if DUNDEE sbin_PROGRAMS += dundee/dundee -dundee_dundee_SOURCES = $(gdbus_sources) $(gatchat_sources) $(btio_sources) \ - src/log.c src/dbus.c plugins/bluez4.c \ - dundee/dundee.h dundee/main.c dundee/dbus.c \ - dundee/manager.c dundee/device.c dundee/bluez4.c +dundee_common_sources = $(gdbus_sources) $(gatchat_sources) \ + src/log.c src/dbus.c dundee/dundee.h dundee/main.c \ + dundee/dbus.c dundee/manager.c dundee/device.c dundee_dundee_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ -ldl if DATAFILES dist_dbusconf_DATA += dundee/dundee.conf - if SYSTEMD systemdunit_DATA += dundee/dundee.service endif endif The line removal seems not necessary. cheers, daniel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 04/13] dundee: Initial GDBusClient for BlueZ 5
Hi Paulo,
On 03/04/2013 08:33 PM, Paulo Borges wrote:
This patch adds the callbacks to track additions and removals of
BlueZ related interfaces and property changes in these interfaces.
---
dundee/bluez5.c | 60 +++
dundee/dundee.h |2 ++
2 files changed, 62 insertions(+)
diff --git a/dundee/bluez5.c b/dundee/bluez5.c
index 6685b4c..40df700 100644
--- a/dundee/bluez5.c
+++ b/dundee/bluez5.c
@@ -22,16 +22,76 @@
#include config.h
#endif
+#include stdint.h
+#include sys/socket.h
+#include gdbus.h
+
#include dundee.h
+#include plugins/bluez5.h
+
+#define DUN_DT_PROFILE_PATH /bluetooth/profile/dun_dt
+
+static GDBusClient *bluez;
+
+static void proxy_added(GDBusProxy *proxy, void *user_data)
+{
+ const char *path = g_dbus_proxy_get_path(proxy);
+ const char *interface = g_dbus_proxy_get_interface(proxy);
+
+ if (g_str_equal(BLUEZ_DEVICE_INTERFACE, interface) == FALSE)
+ return;
In oFono, just use let the '== FALSE' part away. The same applies for
the rest of the series.
cheers,
daniel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 07/13] dundee: Listen to devices property changes
Hi Paulo,
On 03/04/2013 08:33 PM, Paulo Borges wrote:
When a bluetooth device property change and this property is Alias
or UUIDs, we need to refresh our representation of this device.
---
dundee/bluez5.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/dundee/bluez5.c b/dundee/bluez5.c
index 8d8e656..623201f 100644
--- a/dundee/bluez5.c
+++ b/dundee/bluez5.c
@@ -169,11 +169,35 @@ static void property_changed(GDBusProxy *proxy, const
char *name,
{
const char *path = g_dbus_proxy_get_path(proxy);
const char *interface = g_dbus_proxy_get_interface(proxy);
+ const char *alias;
+ struct bluetooth_device *bt_device;
+ gboolean uuid;
if (g_str_equal(BLUEZ_DEVICE_INTERFACE, interface) == FALSE)
return;
- DBG(%s %s.%s, path, interface, name);
+ bt_device = g_hash_table_lookup(registered_devices, path);
+
+ if (g_str_equal(name, Alias) == TRUE) {
+ if (bt_device == NULL)
+ return;
+
+ dbus_message_iter_get_basic(iter, alias);
+
+ DBG(%s alias changed: %s, path, alias);
+
+ bt_device-name = g_strdup(alias);
+ } else if (g_str_equal(name, UUIDs) == TRUE) {
+ DBG(%s uuids changed, path);
+
+ uuid = has_dun_uuid(iter);
+
+ if (bt_device != NULL uuid == FALSE)
+ bluetooth_device_unregister(path);
+
+ else if (bt_device == NULL uuid == TRUE)
+ bluetooth_device_register(proxy);
+ }
I find this a bit hard to read. What about
if (uuid)
if (bt_device != NULL)
bluetooth_device_unregister(path);
else
if (bt_device == NULL)
bluetooth_device_regster(path);
? I am not sure if Denis or Marcel approves this :)
cheers,
daniel
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 00/13] Add support for BlueZ 5 Profile1 API to dundee
Hi Paulo, On 03/04/2013 08:33 PM, Paulo Borges wrote: This series implements support for BlueZ 5 to dundee. It uses the org.bluez.Profile1 API to register an external profile. While the interface between BlueZ and dundee has changed, the interfaces org.ofono.dundee.Device and org.ofono.dundee.Manager remains unchanged. Thanks for your patches. They look pretty good to me. Let's see if Denis or Marcel have something to say. cheer, daniel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 00/13] Add support for BlueZ 5 Profile1 API to dundee
Hi Daniel, On Mon, Mar 11, 2013 at 2:23 PM, Daniel Wagner w...@monom.org wrote: Hi Paulo, Thanks for your patches. They look pretty good to me. Let's see if Denis or Marcel have something to say. cheer, daniel Thank you for reviewing my patches! I'll fix the mentioned points and send a v2 soon. Paulo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
