* Re: SEGFAULT in obexd manager.c:find_session
From: Marcin Zawiejski @ 2012-12-31 0:01 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJTCf9eiVm10SoLRDQ870ayt00Eiz=szXEb1fhktWyHcQ@mail.gmail.com>
Hi Luiz,
On Sun, 2012-12-30 at 16:28 +0200, Luiz Augusto von Dentz wrote:
> Hi Marcin,
>
> On Sun, Dec 30, 2012 at 3:18 PM, Marcin Zawiejski <dragmz@gmail.com> wrote:
> > Hi, I think there is a bug in obexd in manager.c:find_session function.
> >
> > What happens here is a segfault when manager.c:find_session calls
> > g_str_equal(obc_session_get_path(session), path). This is caused by the
> > sessions list having a session with a NULL path.
> >
> > Basically when I call manager.c:create_session, the session created there is
> > added to sessions list but it has a NULL path until the
> > manager.c:create_callback is called.
> >
> > However the manager.c:create_callback is not called at all if the remote
> > device refuses the connection. So when manager.c:find_session is called, it
> > actually calls the g_str_equal(NULL, path) causing the segfault.
> >
> > This might be simply fixed by modifying the manager.c:find_session to check
> > for a NULL session path before calling g_str_equal(...).
> >
> > The problem is reproducible by having two sessions, with one awaiting
> > connection and another one with an active file transfer. When the file
> > transfer errors and I call org.bluez.obex.Client1 RemoveSession then the
> > obexd segfaults since the session awaiting connection has a NULL path.
> >
> > I'm not sure if the session with a NULL path should be on the sessions list
> > or not. If its okay, then here's a simple patch for the
> > manager.c:find_session function:
> >
> > ---
> > diff --git a/obexd/client/manager.c b/obexd/client/manager.c
> > index 8f62a30..28b890c 100644
> > --- a/obexd/client/manager.c
> > +++ b/obexd/client/manager.c
> > @@ -142,8 +142,9 @@ static struct obc_session *find_session(const char
> > *path)
> >
> > for (l = sessions; l; l = l->next) {
> > struct obc_session *session = l->data;
> > + const char *session_path = obc_session_get_path(session);
> >
> > - if (g_str_equal(obc_session_get_path(session), path) ==
> > TRUE)
> > + if (session_path != NULL && g_str_equal(session_path, path)
> > == TRUE)
> > return session;
> > }
> > ---
>
> You can use g_strcmp0 which checks for NULL, gonna take a look why the
> session path is NULL perhaps we should not even add to the session
> list until the connection completes and it is properly registered.
I think you are right - session with no path should not be placed on the
sessions list because it is not usable in such case anyway. Below is a patch
that works for me, here's a summary of the changes:
- move g_slist_append from create_session to create_callback so the
session is added to sessions list after it has been registered
- split shutdown_session into shutdown_session and release_session; the
shutdown_session performs the shutdown and unref on the session but does
not try to remove session from the list; the release_session removes the
session from the list and calls release_shutdown
- modify create_callback so it calls shutdown_session for failures
before the session has been registered (so it doesn't try to remove
session from the list since the session is not on the list)
- modify remove_session to call release_session in order to remove the
session from list and do shutdown
---
diff --git a/obexd/client/manager.c b/obexd/client/manager.c
index 8f62a30..118dd48 100644
--- a/obexd/client/manager.c
+++ b/obexd/client/manager.c
@@ -59,11 +59,16 @@ static GSList *sessions = NULL;
static void shutdown_session(struct obc_session *session)
{
- sessions = g_slist_remove(sessions, session);
obc_session_shutdown(session);
obc_session_unref(session);
}
+static void release_session(struct obc_session *session)
+{
+ sessions = g_slist_remove(sessions, session);
+ shutdown_session(session);
+}
+
static void unregister_session(void *data)
{
struct obc_session *session = data;
@@ -94,6 +99,16 @@ static void create_callback(struct obc_session
*session,
path = obc_session_register(session, unregister_session);
+ if(path == NULL) {
+ DBusMessage *error = g_dbus_create_error(data->message,
+ ERROR_INTERFACE ".Failed",
+ NULL);
+ g_dbus_send_message(data->connection, error);
+ shutdown_session(session);
+ goto done;
+ }
+
+ sessions = g_slist_append(sessions, session);
g_dbus_send_reply(data->connection, data->message,
DBUS_TYPE_OBJECT_PATH, &path,
DBUS_TYPE_INVALID);
@@ -190,7 +205,6 @@ static DBusMessage *create_session(DBusConnection
*connection,
dbus_message_get_sender(message),
create_callback, data);
if (session != NULL) {
- sessions = g_slist_append(sessions, session);
return NULL;
}
@@ -224,7 +238,7 @@ static DBusMessage *remove_session(DBusConnection
*connection,
ERROR_INTERFACE ".NotAuthorized",
"Not Authorized");
- shutdown_session(session);
+ release_session(session);
return dbus_message_new_method_return(message);
}
---
Marcin.
^ permalink raw reply related
* Re: SEGFAULT in obexd manager.c:find_session
From: Marcin Zawiejski @ 2012-12-30 23:58 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJTCf9eiVm10SoLRDQ870ayt00Eiz=szXEb1fhktWyHcQ@mail.gmail.com>
Hi Luiz,
On Sun, 2012-12-30 at 16:28 +0200, Luiz Augusto von Dentz wrote:
> Hi Marcin,
>
> On Sun, Dec 30, 2012 at 3:18 PM, Marcin Zawiejski <dragmz@gmail.com> wrote:
> > Hi, I think there is a bug in obexd in manager.c:find_session function.
> >
> > What happens here is a segfault when manager.c:find_session calls
> > g_str_equal(obc_session_get_path(session), path). This is caused by the
> > sessions list having a session with a NULL path.
> >
> > Basically when I call manager.c:create_session, the session created there is
> > added to sessions list but it has a NULL path until the
> > manager.c:create_callback is called.
> >
> > However the manager.c:create_callback is not called at all if the remote
> > device refuses the connection. So when manager.c:find_session is called, it
> > actually calls the g_str_equal(NULL, path) causing the segfault.
> >
> > This might be simply fixed by modifying the manager.c:find_session to check
> > for a NULL session path before calling g_str_equal(...).
> >
> > The problem is reproducible by having two sessions, with one awaiting
> > connection and another one with an active file transfer. When the file
> > transfer errors and I call org.bluez.obex.Client1 RemoveSession then the
> > obexd segfaults since the session awaiting connection has a NULL path.
> >
> > I'm not sure if the session with a NULL path should be on the sessions list
> > or not. If its okay, then here's a simple patch for the
> > manager.c:find_session function:
> >
> > ---
> > diff --git a/obexd/client/manager.c b/obexd/client/manager.c
> > index 8f62a30..28b890c 100644
> > --- a/obexd/client/manager.c
> > +++ b/obexd/client/manager.c
> > @@ -142,8 +142,9 @@ static struct obc_session *find_session(const char
> > *path)
> >
> > for (l = sessions; l; l = l->next) {
> > struct obc_session *session = l->data;
> > + const char *session_path = obc_session_get_path(session);
> >
> > - if (g_str_equal(obc_session_get_path(session), path) ==
> > TRUE)
> > + if (session_path != NULL && g_str_equal(session_path, path)
> > == TRUE)
> > return session;
> > }
> > ---
>
> You can use g_strcmp0 which checks for NULL, gonna take a look why the
> session path is NULL perhaps we should not even add to the session
> list until the connection completes and it is properly registered.
I think you are right - session with no path should not be placed on the
sessions list because it is not usable in such case. Below is a patch
that works for me, here's a summary of the changes:
- move g_slist_append from create_session to create_callback so the
session is added to sessions list after it has been registered
- split shutdown_session into shutdown_session and release_session; the
shutdown_session performs the shutdown and unref on the session but does
not try to remove session from the list; the release_session removes the
session from the list and calls release_shutdown
- modify create_callback so it calls shutdown_session for failures
before the session has been registered (so it doesn't try to remove
session from the list since the session is not on the list)
- modify remove_session to call release_session in order to remove the
session from list and do shutdown
---
diff --git a/obexd/client/manager.c b/obexd/client/manager.c
index 8f62a30..118dd48 100644
--- a/obexd/client/manager.c
+++ b/obexd/client/manager.c
@@ -59,11 +59,16 @@ static GSList *sessions = NULL;
static void shutdown_session(struct obc_session *session)
{
- sessions = g_slist_remove(sessions, session);
obc_session_shutdown(session);
obc_session_unref(session);
}
+static void release_session(struct obc_session *session)
+{
+ sessions = g_slist_remove(sessions, session);
+ shutdown_session(session);
+}
+
static void unregister_session(void *data)
{
struct obc_session *session = data;
@@ -94,6 +99,16 @@ static void create_callback(struct obc_session
*session,
path = obc_session_register(session, unregister_session);
+ if(path == NULL) {
+ DBusMessage *error = g_dbus_create_error(data->message,
+ ERROR_INTERFACE ".Failed",
+ NULL);
+ g_dbus_send_message(data->connection, error);
+ shutdown_session(session);
+ goto done;
+ }
+
+ sessions = g_slist_append(sessions, session);
g_dbus_send_reply(data->connection, data->message,
DBUS_TYPE_OBJECT_PATH, &path,
DBUS_TYPE_INVALID);
@@ -190,7 +205,6 @@ static DBusMessage *create_session(DBusConnection
*connection,
dbus_message_get_sender(message),
create_callback, data);
if (session != NULL) {
- sessions = g_slist_append(sessions, session);
return NULL;
}
@@ -224,7 +238,7 @@ static DBusMessage *remove_session(DBusConnection
*connection,
ERROR_INTERFACE ".NotAuthorized",
"Not Authorized");
- shutdown_session(session);
+ release_session(session);
return dbus_message_new_method_return(message);
}
---
Marcin.
^ permalink raw reply related
* Re: bluez-5.0 dropped --with-ouifile=PATH
From: Pacho Ramos @ 2012-12-30 20:12 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356897940.19248.87.camel@aeonflux>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
El dom, 30-12-2012 a las 12:05 -0800, Marcel Holtmann escribió:
> Hi Pacho,
>
> > > > That option is needed on Gentoo to let it catch oui.txt file present
> > > > on /usr/share/misc/oui.txt, could it be re-added to prevent us from
> > > > needing to sed src/oui.c looking for that file in our location?
> > >
> > > or you build against a recent version of udev that comes with hwdb
> > > support. Then it will actually start using the efficient version of
> > > reading the OUI values from this file.
> > >
> > > There is no plan to keep support for oui.txt for very long. It is still
> > > supported as transition period, but that is about it.
> >
> > And what is replacing oui.txt? udev directly?
>
> as I said above, udev's hwdb. Check udevadm hwdb for a command line
> example too. Also src/oui.c is pretty obvious in that regard.
>
> Regards
>
> Marcel
OK, thanks
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: bluez-5.0 dropped --with-ouifile=PATH
From: Marcel Holtmann @ 2012-12-30 20:05 UTC (permalink / raw)
To: Pacho Ramos; +Cc: linux-bluetooth
In-Reply-To: <1356897497.19380.0.camel@belkin4>
Hi Pacho,
> > > That option is needed on Gentoo to let it catch oui.txt file present
> > > on /usr/share/misc/oui.txt, could it be re-added to prevent us from
> > > needing to sed src/oui.c looking for that file in our location?
> >
> > or you build against a recent version of udev that comes with hwdb
> > support. Then it will actually start using the efficient version of
> > reading the OUI values from this file.
> >
> > There is no plan to keep support for oui.txt for very long. It is still
> > supported as transition period, but that is about it.
>
> And what is replacing oui.txt? udev directly?
as I said above, udev's hwdb. Check udevadm hwdb for a command line
example too. Also src/oui.c is pretty obvious in that regard.
Regards
Marcel
^ permalink raw reply
* Re: bluez-5.0 dropped --with-ouifile=PATH
From: Pacho Ramos @ 2012-12-30 19:58 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356892983.19248.82.camel@aeonflux>
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
El dom, 30-12-2012 a las 10:43 -0800, Marcel Holtmann escribió:
> Hi Pacho,
>
> > That option is needed on Gentoo to let it catch oui.txt file present
> > on /usr/share/misc/oui.txt, could it be re-added to prevent us from
> > needing to sed src/oui.c looking for that file in our location?
>
> or you build against a recent version of udev that comes with hwdb
> support. Then it will actually start using the efficient version of
> reading the OUI values from this file.
>
> There is no plan to keep support for oui.txt for very long. It is still
> supported as transition period, but that is about it.
>
> Regards
>
> Marcel
>
And what is replacing oui.txt? udev directly?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH BlueZ 00/11] Add experimental command line switch option
From: Marcel Holtmann @ 2012-12-30 19:02 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
> These set of patches introduces g_dbus_set_flags along with experimental flags,
> g_dbus_set_flags is not per connection as originally suggested to avoid using
> dbus_connection_allocate_data_slot which requires calling
> dbus_connection_free_data_slot once done but currently we don't keep any data
> associated with connections, besides the flags comes from command line options
> which would end up setting the same flags for every connection anyway.
>
> In addition to experimental it also add support to enable deprecated via compat
> swith option, this makes any API marked as deprecated to be disabled if compat
> is not set. This is on purpose to expose applications using deprecated APIs.
besides the deprecated switch, all patches have been applied.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 06/11] gdbus: Introduce G_DBUS_FLAG_ENABLE_DEPRECATED
From: Marcel Holtmann @ 2012-12-30 18:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1356699069-5469-7-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
> This flag can be set using g_dbus_set_flags to enable deprecated
> interfaces, default is unset.
> ---
> gdbus/gdbus.h | 3 ++-
> gdbus/object.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+), 1 deletion(-)
I decided against this patch. At least for now. The whole point of the
interface versioning is to support two API versions. So having an option
to manually enable them makes no sense. We can revisit this once we
reach that point, but otherwise I leave this out for now.
Regards
Marcel
^ permalink raw reply
* Re: bluez-5.0 dropped --with-ouifile=PATH
From: Marcel Holtmann @ 2012-12-30 18:43 UTC (permalink / raw)
To: Pacho Ramos; +Cc: linux-bluetooth
In-Reply-To: <1356878136.18481.1.camel@belkin4>
Hi Pacho,
> That option is needed on Gentoo to let it catch oui.txt file present
> on /usr/share/misc/oui.txt, could it be re-added to prevent us from
> needing to sed src/oui.c looking for that file in our location?
or you build against a recent version of udev that comes with hwdb
support. Then it will actually start using the efficient version of
reading the OUI values from this file.
There is no plan to keep support for oui.txt for very long. It is still
supported as transition period, but that is about it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/1] adapter, AVCTP: Replaced calls to g_queue_free_full function
From: Anderson Lizardo @ 2012-12-30 14:37 UTC (permalink / raw)
To: Giovanni Gherdovich; +Cc: linux-bluetooth
In-Reply-To: <1356862632-5938-1-git-send-email-g.gherdovich@gmail.com>
Hi Giovanni,
A few coding style comments below.
On Sun, Dec 30, 2012 at 6:17 AM, Giovanni Gherdovich
<g.gherdovich@gmail.com> wrote:
> The function g_queue_free_full is available only from GLib 2.32.
> If BlueZ has to build against GLib 2.28, as stated in the configure.ac,
> this patch replaces the calls to g_queue_free_full with its body,
> taken from the sources of GLib 2.32.
>
> Signed-off-by: Giovanni Gherdovich <g.gherdovich@gmail.com>
BlueZ does not use Signed-off-by tag, so you must remove it.
> ---
> profiles/audio/avctp.c | 3 ++-
> src/adapter.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
> index 013c587..745ced8 100644
> --- a/profiles/audio/avctp.c
> +++ b/profiles/audio/avctp.c
> @@ -395,7 +395,8 @@ static void avctp_channel_destroy(struct avctp_channel *chan)
> g_source_remove(chan->process_id);
>
> g_free(chan->buffer);
> - g_queue_free_full(chan->queue, pending_destroy);
> + g_queue_foreach(chan->queue, (GFunc)pending_destroy, NULL);
> + g_queue_free(chan->queue);
Where possible, try to avoid using casts for functions. In this case,
try removing "(GFunc)" and see if code still compiles cleanly with
"./bootstrap-configure && make".
> g_slist_free_full(chan->processed, pending_destroy);
> g_slist_free_full(chan->handlers, g_free);
> g_free(chan);
> diff --git a/src/adapter.c b/src/adapter.c
> index e71cea8..a244ae2 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -1697,7 +1697,8 @@ static void adapter_free(gpointer user_data)
> if (adapter->auth_idle_id)
> g_source_remove(adapter->auth_idle_id);
>
> - g_queue_free_full(adapter->auths, g_free);
> + g_queue_foreach (adapter->auths, (GFunc)g_free, NULL);
> + g_queue_free (adapter->auths);
Same comment as above regarding "(GFunc)". Also remove the whitespace
before "(" for the two statements.
We usually split the patches if they touch "core" files (in src/*) and
profile code in profiles/*. For simple patches it is no big deal, but
it also does not hurt if you do this always.
And finally, the commit summary should be in present tense (Replaced
-> Replace), e.g.:
core: Replace calls to g_queue_free_full function
AVCTP: Replace calls to g_queue_free_full function
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* bluez-5.0 dropped --with-ouifile=PATH
From: Pacho Ramos @ 2012-12-30 14:35 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
That option is needed on Gentoo to let it catch oui.txt file present
on /usr/share/misc/oui.txt, could it be re-added to prevent us from
needing to sed src/oui.c looking for that file in our location?
Thanks a lot
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: SEGFAULT in obexd manager.c:find_session
From: Luiz Augusto von Dentz @ 2012-12-30 14:28 UTC (permalink / raw)
To: Marcin Zawiejski; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <50E03F0D.6020605@gmail.com>
Hi Marcin,
On Sun, Dec 30, 2012 at 3:18 PM, Marcin Zawiejski <dragmz@gmail.com> wrote:
> Hi, I think there is a bug in obexd in manager.c:find_session function.
>
> What happens here is a segfault when manager.c:find_session calls
> g_str_equal(obc_session_get_path(session), path). This is caused by the
> sessions list having a session with a NULL path.
>
> Basically when I call manager.c:create_session, the session created there is
> added to sessions list but it has a NULL path until the
> manager.c:create_callback is called.
>
> However the manager.c:create_callback is not called at all if the remote
> device refuses the connection. So when manager.c:find_session is called, it
> actually calls the g_str_equal(NULL, path) causing the segfault.
>
> This might be simply fixed by modifying the manager.c:find_session to check
> for a NULL session path before calling g_str_equal(...).
>
> The problem is reproducible by having two sessions, with one awaiting
> connection and another one with an active file transfer. When the file
> transfer errors and I call org.bluez.obex.Client1 RemoveSession then the
> obexd segfaults since the session awaiting connection has a NULL path.
>
> I'm not sure if the session with a NULL path should be on the sessions list
> or not. If its okay, then here's a simple patch for the
> manager.c:find_session function:
>
> ---
> diff --git a/obexd/client/manager.c b/obexd/client/manager.c
> index 8f62a30..28b890c 100644
> --- a/obexd/client/manager.c
> +++ b/obexd/client/manager.c
> @@ -142,8 +142,9 @@ static struct obc_session *find_session(const char
> *path)
>
> for (l = sessions; l; l = l->next) {
> struct obc_session *session = l->data;
> + const char *session_path = obc_session_get_path(session);
>
> - if (g_str_equal(obc_session_get_path(session), path) ==
> TRUE)
> + if (session_path != NULL && g_str_equal(session_path, path)
> == TRUE)
> return session;
> }
> ---
You can use g_strcmp0 which checks for NULL, gonna take a look why the
session path is NULL perhaps we should not even add to the session
list until the connection completes and it is properly registered.
--
Luiz Augusto von Dentz
^ permalink raw reply
* SEGFAULT in obexd manager.c:find_session
From: Marcin Zawiejski @ 2012-12-30 13:18 UTC (permalink / raw)
To: linux-bluetooth
Hi, I think there is a bug in obexd in manager.c:find_session function.
What happens here is a segfault when manager.c:find_session calls
g_str_equal(obc_session_get_path(session), path). This is caused by the
sessions list having a session with a NULL path.
Basically when I call manager.c:create_session, the session created
there is added to sessions list but it has a NULL path until the
manager.c:create_callback is called.
However the manager.c:create_callback is not called at all if the remote
device refuses the connection. So when manager.c:find_session is called,
it actually calls the g_str_equal(NULL, path) causing the segfault.
This might be simply fixed by modifying the manager.c:find_session to
check for a NULL session path before calling g_str_equal(...).
The problem is reproducible by having two sessions, with one awaiting
connection and another one with an active file transfer. When the file
transfer errors and I call org.bluez.obex.Client1 RemoveSession then the
obexd segfaults since the session awaiting connection has a NULL path.
I'm not sure if the session with a NULL path should be on the sessions
list or not. If its okay, then here's a simple patch for the
manager.c:find_session function:
---
diff --git a/obexd/client/manager.c b/obexd/client/manager.c
index 8f62a30..28b890c 100644
--- a/obexd/client/manager.c
+++ b/obexd/client/manager.c
@@ -142,8 +142,9 @@ static struct obc_session *find_session(const char
*path)
for (l = sessions; l; l = l->next) {
struct obc_session *session = l->data;
+ const char *session_path = obc_session_get_path(session);
- if (g_str_equal(obc_session_get_path(session), path) ==
TRUE)
+ if (session_path != NULL && g_str_equal(session_path,
path) == TRUE)
return session;
}
---
Marcin.
^ permalink raw reply related
* Re: inconsistency in configure.ac for BlueZ 5.0 : GLib 2.32 required
From: Giovanni Gherdovich @ 2012-12-30 10:25 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1356826885.19248.79.camel@aeonflux>
Hello Marcel,
2012/12/30 Marcel Holtmann <marcel@holtmann.org>:
>
> I prefer to keep it at GLib 2.28 for now. So please send a patch to
> workaround that issue for the missing g_queue_free_full.
OK, I just sent it.
Regards,
Giovanni
^ permalink raw reply
* [PATCH 1/1] adapter, AVCTP: Replaced calls to g_queue_free_full function
From: Giovanni Gherdovich @ 2012-12-30 10:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Giovanni Gherdovich
The function g_queue_free_full is available only from GLib 2.32.
If BlueZ has to build against GLib 2.28, as stated in the configure.ac,
this patch replaces the calls to g_queue_free_full with its body,
taken from the sources of GLib 2.32.
Signed-off-by: Giovanni Gherdovich <g.gherdovich@gmail.com>
---
profiles/audio/avctp.c | 3 ++-
src/adapter.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
index 013c587..745ced8 100644
--- a/profiles/audio/avctp.c
+++ b/profiles/audio/avctp.c
@@ -395,7 +395,8 @@ static void avctp_channel_destroy(struct avctp_channel *chan)
g_source_remove(chan->process_id);
g_free(chan->buffer);
- g_queue_free_full(chan->queue, pending_destroy);
+ g_queue_foreach(chan->queue, (GFunc)pending_destroy, NULL);
+ g_queue_free(chan->queue);
g_slist_free_full(chan->processed, pending_destroy);
g_slist_free_full(chan->handlers, g_free);
g_free(chan);
diff --git a/src/adapter.c b/src/adapter.c
index e71cea8..a244ae2 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1697,7 +1697,8 @@ static void adapter_free(gpointer user_data)
if (adapter->auth_idle_id)
g_source_remove(adapter->auth_idle_id);
- g_queue_free_full(adapter->auths, g_free);
+ g_queue_foreach (adapter->auths, (GFunc)g_free, NULL);
+ g_queue_free (adapter->auths);
sdp_list_free(adapter->services, NULL);
--
1.7.4.1
^ permalink raw reply related
* BLE multiple connection - Recv() issue
From: Ajay @ 2012-12-30 1:25 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
hi,
I have 2 LE links A1 to B and A2 to C ( A1 and A2 are client
running at same device )
when i starts sending data from B to A1 its happening and A1 is
receiving properly . But the very next moment i started data transfer
from C to A2 , A1 stops recievng . I could see data from B to A1
reaches upto hci layer(hcidump) , and then routed to A2 l2cap recv() .
Here i used recv() and send() system calls for data transfer with l2cap
socket (cid 0x04 and psm 0x00) .Bind() is done at both client and server
side . Is it possible for a BLE device to recv data simultaneously from
other two devices .????? .
--
Thanks & Regards
AJAY KV
GlobalEdge software Ltd
8892753703
[-- Attachment #2: ajay_kv.vcf --]
[-- Type: text/x-vcard, Size: 74 bytes --]
begin:vcard
fn:AJAY KV
n:;AJAY
tel;cell:8892753703
version:2.1
end:vcard
^ permalink raw reply
* Re: inconsistency in configure.ac for BlueZ 5.0 : GLib 2.32 required
From: Marcel Holtmann @ 2012-12-30 0:21 UTC (permalink / raw)
To: Giovanni Gherdovich; +Cc: linux-bluetooth
In-Reply-To: <CAJN7YmO4th=T2u0s9ya6fEwjO5RdEiVZCfyhTHRLb94u9Q2KeA@mail.gmail.com>
Hi Giovanni,
> I believe there is a little inconsistency in configure.ac
> of BlueZ 5.0:
>
> it requires GLib 2.28, but actually the files
I prefer to keep it at GLib 2.28 for now. So please send a patch to
workaround that issue for the missing g_queue_free_full.
Regards
Marcel
^ permalink raw reply
* inconsistency in configure.ac for BlueZ 5.0 : GLib 2.32 required
From: Giovanni Gherdovich @ 2012-12-29 20:01 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
I believe there is a little inconsistency in configure.ac
of BlueZ 5.0:
it requires GLib 2.28, but actually the files
/profiles/audio/avctp.c
/src/adapter.c
use the function g_queue_free_full which appeared in
GLib 2.32
http://developer.gnome.org/glib/2.31/glib-Double-ended-Queues.html#g-queue-free-full
Even if the documentation states clearly that g_queue_free_full
appeared in GLib 2.32, I used git bisect to be sure:
----------8<----------------------------
$ git clone http://git.gnome.org/browse/glib
$ cd glib
$ git bisect start 2.32.0 2.28.0
$ git bisect run /bin/bash -c "! grep -rq g_queue_free_full *"
[...]
1d4009e6f7e1d368b3e3df2fa41b007277b600d8 is the first bad commit
commit 1d4009e6f7e1d368b3e3df2fa41b007277b600d8
Author: Ravi Sankar Guntur <ravi.g@samsung.com>
Date: Wed Dec 14 20:17:54 2011 +0530
Added API g_queue_free_full().
[...]
----------8<----------------------------
so it was added here
http://git.gnome.org/browse/glib/commit/?id=1d4009e6f7e1d368b3e3df2fa41b007277b600d8
between tags 2.31.4 and 2.31.6
I don't know if it is better to change the configure.ac or to
substitute the (two) calls to g_queue_free_full with equivalent code
(that function is just a convenience method, its body is two lines).
In both cases, you can find a proposed patch below.
Or, maybe, I overlooked something obvious and there is no problem at all.
I used the git bisect trick to check when these two calls where
introduced in BlueZ, and here it is:
----------8<----------------------------
$ git clone http://git.kernel.org/pub/scm/bluetooth/bluez.git
$ cd bluez
$ git bisect start 5.0 4.0
$ git bisect run /bin/bash -c "! grep -rq g_queue_free_full *"
[...]
0314008ff39d156ff1a98c2f20f13284983d0d84 is the first bad commit
commit 0314008ff39d156ff1a98c2f20f13284983d0d84
Author: Mikel Astiz <mikel.astiz@bmw-carit.de>
Date: Fri Sep 28 18:32:24 2012 +0200
adapter: Queue parallel authorization requests
[...]
$ git bisect reset
$ git bisect run /bin/bash -c "! grep -rq g_queue_free_full .
--include=\"*avctp.c\""
[...]
a835942875da320cc2a2dba6898081d17a07efdf is the first bad commit
commit a835942875da320cc2a2dba6898081d17a07efdf
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: Mon Oct 15 16:05:30 2012 +0200
AVCTP: Add proper queueing for channels
[...]
----------8<----------------------------
So the commits which introduced those two calls are
http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=a835942875da320cc2a2dba6898081d17a07efdf
and
http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=0314008ff39d156ff1a98c2f20f13284983d0d84
proposed patches follow.
Best regards,
Giovanni Gherdovich
ggherdov on #bluez @ freenode
----------8<----------------------------
>From 6e0047a014605237dbbd18f3dc69d7af74037fb5 Mon Sep 17 00:00:00 2001
From: Giovanni Gherdovich <g.gherdovich@gmail.com>
Date: Sat, 29 Dec 2012 18:26:03 +0100
Subject: [PATCH] Updated dependency to glib version from 2.28 to 2.32
the tree makes use of the function g_queue_free_full which is
available only from GLib 2.32, while configure.ac requires
GLib version 2.28
---
configure.ac | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index cdfc013..8873af0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -43,8 +43,8 @@ AC_CHECK_FUNC(signalfd, dummy=yes,
AC_CHECK_LIB(dl, dlopen, dummy=yes,
AC_MSG_ERROR(dynamic linking loader is required))
-PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.28, dummy=yes,
- AC_MSG_ERROR(GLib >= 2.28 is required))
+PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.32, dummy=yes,
+ AC_MSG_ERROR(GLib >= 2.32 is required))
AC_SUBST(GLIB_CFLAGS)
AC_SUBST(GLIB_LIBS)
--
1.7.4.1
----------8<----------------------------
>From 159bede1a24e060c614a4934627d696ab9bd8a7d Mon Sep 17 00:00:00 2001
From: Giovanni Gherdovich <g.gherdovich@gmail.com>
Date: Sat, 29 Dec 2012 19:32:29 +0100
Subject: [PATCH] Replaced calls to g_queue_free_full function
The function g_queue_free_full is available only from GLib 2.32.
If BlueZ has to build against GLib 2.28, as stated in the configure.ac,
this patch replaces the calls to g_queue_free_full with its
definition, taken from the sources of GLib 2.32.
---
profiles/audio/avctp.c | 3 ++-
src/adapter.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
index 013c587..745ced8 100644
--- a/profiles/audio/avctp.c
+++ b/profiles/audio/avctp.c
@@ -395,7 +395,8 @@ static void avctp_channel_destroy(struct
avctp_channel *chan)
g_source_remove(chan->process_id);
g_free(chan->buffer);
- g_queue_free_full(chan->queue, pending_destroy);
+ g_queue_foreach(chan->queue, (GFunc)pending_destroy, NULL);
+ g_queue_free(chan->queue);
g_slist_free_full(chan->processed, pending_destroy);
g_slist_free_full(chan->handlers, g_free);
g_free(chan);
diff --git a/src/adapter.c b/src/adapter.c
index e71cea8..a244ae2 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1697,7 +1697,8 @@ static void adapter_free(gpointer user_data)
if (adapter->auth_idle_id)
g_source_remove(adapter->auth_idle_id);
- g_queue_free_full(adapter->auths, g_free);
+ g_queue_foreach (adapter->auths, (GFunc)g_free, NULL);
+ g_queue_free (adapter->auths);
sdp_list_free(adapter->services, NULL);
--
1.7.4.1
----------8<----------------------------
^ permalink raw reply related
* [PATCH] Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.
From: Daniel Schaal @ 2012-12-29 10:14 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-kernel
Cc: Daniel Schaal
In-Reply-To: <1356776074-1703-1-git-send-email-farbing@web.de>
T: Bus=02 Lev=02 Prnt=02 Port=06 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3006 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
Signed-off-by: Daniel Schaal <farbing@web.de>
---
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index b00000e..d936c5d 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -77,6 +77,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x0CF3, 0x311D) },
{ USB_DEVICE(0x13d3, 0x3375) },
{ USB_DEVICE(0x04CA, 0x3005) },
+ { USB_DEVICE(0x04CA, 0x3006) },
{ USB_DEVICE(0x13d3, 0x3362) },
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
@@ -104,6 +105,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x0cf3, 0x311D), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a1d4ede..3252792 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -135,6 +135,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3375), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x13d3, 0x3362), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
--
1.7.10.4
^ permalink raw reply related
* [PATCH] Bluetooth: Add support for GC-WB300D PCIe [04ca:3006]
From: Daniel Schaal @ 2012-12-29 10:14 UTC (permalink / raw)
To: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-bluetooth,
linux-kernel
Cc: Daniel Schaal
The following patch adds support for the bluetooth part of
Gigabyte's GC-WB300D PCIe card (combo card with AR9462 WLAN
and ATH3012 BT).
On every boot there is an error from this device:
usb 2-1.7: string descriptor 0 read error: -22
But that doesn't seem to have any negative effect AFAICT.
It also needed a newer firmware than is in linux-firmware.git,
using the one from the Windows driver worked fine.
(AthrBT_0x11020000.dfu and ramps_0x11020000_40.dfu)
Daniel Schaal (1):
Bluetooth: Add support for GC-WB300D PCIe [04ca:3006] to ath3k.
drivers/bluetooth/ath3k.c | 2 ++
drivers/bluetooth/btusb.c | 1 +
2 files changed, 3 insertions(+)
--
1.7.10.4
^ permalink raw reply
* Re: [RFC/RFT] rtk_btusb: Bluetooth driver for Realtek RTL8723AE combo device
From: Oliver Neukum @ 2012-12-29 9:29 UTC (permalink / raw)
To: Larry Finger
Cc: linville, Marcel Holtmann, Gustavo Padovan, Johan Hedberg,
linux-wireless, linux-bluetooth, Champion Chen
In-Reply-To: <50DA64E7.9050700@lwfinger.net>
On Tuesday 25 December 2012 20:45:59 Larry Finger wrote:
> >> +struct patch_info {
> >> + uint16_t prod_id;
> >> + uint16_t lmp_sub;
> >> + char *patch_name;
> >> + char *config_name;
> >> + uint8_t *fw_cache;
> >> + int fw_len;
> >> +};
> >> +
> >> +struct xchange_data {
> >> + struct dev_data *dev_entry;
> >> + int pipe_in, pipe_out;
> >> + uint8_t send_pkt[PKT_LEN];
> >> + uint8_t rcv_pkt[PKT_LEN];
> >
> > Violations of the DMA coherency rules, fails on non-x86
>
> I see that the buffers are not 64-bit aligned. What other conditions are necessary?
They need to be aligned on cache lines and nothing else may use
that cache line. The size of a cache line is specific to an architecture.
It is generally easiest for such buffers to be allocated separately with kmalloc().
> Thanks for the review. As suggested by you and Marcel, a complete rewrite is
> needed. I plan to use the mini-driver approach of Tedd Ho-Jeong An; however,
> your comments will be used when constructing that code.
Very good.
Regards
Oliver
^ permalink raw reply
* Re: How to pair device from CLI?
From: Kamil Jońca @ 2012-12-28 15:25 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20121228135423.GA14448@x220.P-661HNU-F1>
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]
Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
> Hi Kamil,
>
>> > HCI Event: IO Capability Request (0x31) plen 6
>> bdaddr D4:E8:B2:AA:15:FA
>> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
>> bdaddr D4:E8:B2:AA:15:FA capability 0x04 oob 0x00 auth 0x03
>> Capability: Reserved (OOB data not present)
>> Authentication: Dedicated Bonding (MITM Protection)
>
> Here's the problem. The kernel is respoding with an invalid IO
> capability value. The same issue was discussed here just a week ago:
>
> http://marc.info/?l=linux-bluetooth&m=135599627517032&w=2
Do I understand correctly, that I have too old kernel version?
> The quick fix is to change "KeyboardDisplay" to "DisplayYesNo" in the
> simple-agent script.
After that change I can pair my phone (thanks), but cannot use obexftp.
--8<---------------cut here---------------start------------->8---
obexftp -b D4:E8:B2:AA:15:FA -l .
Browsing D4:E8:B2:AA:15:FA ...
Connecting...failed: connect
Tried to connect for 3ms
error on connect(): Invalid argument
Still trying to connect
Connecting...failed: connect
Tried to connect for 2ms
error on connect(): Invalid argument
Still trying to connect
Connecting...failed: connect
Tried to connect for 2ms
error on connect(): Invalid argument
Still trying to connect
--8<---------------cut here---------------end--------------->8---
hcidump in attachment
[-- Attachment #2: hcidump.txt --]
[-- Type: text/plain, Size: 9762 bytes --]
HCI sniffer - Bluetooth packet analyzer ver 2.4
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr D4:E8:B2:AA:15:FA ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr D4:E8:B2:AA:15:FA type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 12
Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 12 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Max Slots Change (0x1b) plen 3
handle 12 slots 5
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 12 page 1 max 1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr D4:E8:B2:AA:15:FA mode 2 clkoffset 0x0000
< ACL data: handle 12 flags 0x00 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Info rsp: type 2 result 1
Not supported
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0048 scid 0x0040 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Config req: dcid 0x0048 flags 0x00 clen 0
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 256
< ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x0048 flags 0x00 result 0 clen 4
MTU 256
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 12 flags 0x00 dlen 36
L2CAP(d): cid 0x0048 len 32 [psm 1]
SDP SSA Req: tid 0x0 len 0x1b
pat uuid-128 00005005-0000-1000-8000-0002ee000001
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr D4:E8:B2:AA:15:FA name 'theta'
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x5
count 2
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
< ACL data: handle 12 flags 0x00 dlen 22
L2CAP(d): cid 0x0048 len 18 [psm 1]
SDP SSA Req: tid 0x1 len 0xd
pat uuid-16 0x1106 (OBEXObjTrnsf)
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SSA Rsp: tid 0x1 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x0048 scid 0x0040
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0048 scid 0x0040
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0049 scid 0x0041 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Config req: dcid 0x0049 flags 0x00 clen 0
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 256
< ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x0049 flags 0x00 result 0 clen 4
MTU 256
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 12 flags 0x00 dlen 36
L2CAP(d): cid 0x0049 len 32 [psm 1]
SDP SSA Req: tid 0x0 len 0x1b
pat uuid-128 00005005-0000-1000-8000-0002ee000001
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 22
L2CAP(d): cid 0x0049 len 18 [psm 1]
SDP SSA Req: tid 0x1 len 0xd
pat uuid-16 0x1106 (OBEXObjTrnsf)
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 1]
SDP SSA Rsp: tid 0x1 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x0049 scid 0x0041
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0049 scid 0x0041
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x004a scid 0x0040 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Config req: dcid 0x004a flags 0x00 clen 0
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 256
< ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x004a flags 0x00 result 0 clen 4
MTU 256
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
Success
< ACL data: handle 12 flags 0x00 dlen 36
L2CAP(d): cid 0x004a len 32 [psm 1]
SDP SSA Req: tid 0x0 len 0x1b
pat uuid-128 00005005-0000-1000-8000-0002ee000001
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 22
L2CAP(d): cid 0x004a len 18 [psm 1]
SDP SSA Req: tid 0x1 len 0xd
pat uuid-16 0x1106 (OBEXObjTrnsf)
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 1]
SDP SSA Rsp: tid 0x1 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x004a scid 0x0040
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004a scid 0x0040
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x004b scid 0x0041 result 0 status 0
Connection successful
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Config req: dcid 0x004b flags 0x00 clen 0
> ACL data: handle 12 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 256
< ACL data: handle 12 flags 0x00 dlen 18
L2CAP(s): Config rsp: scid 0x004b flags 0x00 result 0 clen 4
MTU 256
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 0
Success
< ACL data: handle 12 flags 0x00 dlen 36
L2CAP(d): cid 0x004b len 32 [psm 1]
SDP SSA Req: tid 0x0 len 0x1b
pat uuid-128 00005005-0000-1000-8000-0002ee000001
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 1]
SDP SSA Rsp: tid 0x0 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 22
L2CAP(d): cid 0x004b len 18 [psm 1]
SDP SSA Req: tid 0x1 len 0xd
pat uuid-16 0x1106 (OBEXObjTrnsf)
max 65535
aid(s) 0x0004 (ProtocolDescList)
cont 00
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 2
> ACL data: handle 12 flags 0x02 dlen 14
L2CAP(d): cid 0x0041 len 10 [psm 1]
SDP SSA Rsp: tid 0x1 len 0x5
count 2
cont 00
< ACL data: handle 12 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x004b scid 0x0041
> ACL data: handle 12 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004b scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 12 packets 1
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 12 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 12 reason 0x16
Reason: Connection Terminated by Local Host
[-- Attachment #3: Type: text/plain, Size: 169 bytes --]
KJ
--
http://modnebzdury.wordpress.com/2009/10/01/niewiarygodny-list-prof-majewskiej-wprowadzenie/
This fortune would be seven words long if it were six words shorter.
^ permalink raw reply
* Re: How to pair device from CLI?
From: Johan Hedberg @ 2012-12-28 13:54 UTC (permalink / raw)
To: Kamil Jońca; +Cc: linux-bluetooth
In-Reply-To: <87wqw2s3qm.fsf@alfa.kjonca>
Hi Kamil,
> > HCI Event: IO Capability Request (0x31) plen 6
> bdaddr D4:E8:B2:AA:15:FA
> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
> bdaddr D4:E8:B2:AA:15:FA capability 0x04 oob 0x00 auth 0x03
> Capability: Reserved (OOB data not present)
> Authentication: Dedicated Bonding (MITM Protection)
Here's the problem. The kernel is respoding with an invalid IO
capability value. The same issue was discussed here just a week ago:
http://marc.info/?l=linux-bluetooth&m=135599627517032&w=2
The quick fix is to change "KeyboardDisplay" to "DisplayYesNo" in the
simple-agent script.
Johan
^ permalink raw reply
* Re: How to pair device from CLI?
From: Kamil Jońca @ 2012-12-28 13:30 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20121228080842.GA28814@x220.P-661HNU-F1>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
Johan Hedberg <johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
writes:
> Hi Kamil,
>
> On Fri, Dec 28, 2012, Kamil Jońca wrote:
[....]
>
> It's quite odd that you should get RequestPasskey. That's something that
> should only happen if you're pretending to be a keyboard in which case
> you should enter the passkey displayed on the remote device (your phone
> in this case).
Nothing shows on my phone.
>
>> What do I should check? (s)trace?
>>
>> Distribution is pretty fresh debian sid.
>
> The most useful too would be hcidump (bluez-hcidump package). The output
> of hcidump -X for the full pairing process would be interesting.
Two tries in attachment.
[-- Attachment #2: Log --]
[-- Type: text/plain, Size: 6851 bytes --]
Sorry, try again.
HCI sniffer - Bluetooth packet analyzer ver 2.4
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr D4:E8:B2:AA:15:FA ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr D4:E8:B2:AA:15:FA role 0x01
Role: Slave
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr D4:E8:B2:AA:15:FA type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 12
> HCI Event: Max Slots Change (0x1b) plen 3
handle 12 slots 5
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 12
Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 12 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 12 page 1 max 1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr D4:E8:B2:AA:15:FA mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Link Supervision Timeout Change (0x38) plen 4
handle 12 timeout 8000
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr D4:E8:B2:AA:15:FA name 'theta'
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Link Key Request (0x17) plen 6
bdaddr D4:E8:B2:AA:15:FA
< HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
bdaddr D4:E8:B2:AA:15:FA
> HCI Event: Command Complete (0x0e) plen 10
Link Key Request Negative Reply (0x01|0x000c) ncmd 1
status 0x00 bdaddr D4:E8:B2:AA:15:FA
> HCI Event: IO Capability Request (0x31) plen 6
bdaddr D4:E8:B2:AA:15:FA
< HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
bdaddr D4:E8:B2:AA:15:FA capability 0x04 oob 0x00 auth 0x03
Capability: Reserved (OOB data not present)
Authentication: Dedicated Bonding (MITM Protection)
> HCI Event: Command Complete (0x0e) plen 10
IO Capability Request Reply (0x01|0x002b) ncmd 1
status 0x00 bdaddr D4:E8:B2:AA:15:FA
> HCI Event: IO Capability Response (0x32) plen 9
bdaddr D4:E8:B2:AA:15:FA capability 0x01 oob 0x00 auth 0x03
Capability: DisplayYesNo (OOB data not present)
Authentication: Dedicated Bonding (MITM Protection)
> HCI Event: User Passkey Request (0x34) plen 6
bdaddr D4:E8:B2:AA:15:FA
< HCI Command: User Passkey Request Reply (0x01|0x002e) plen 10
bdaddr D4:E8:B2:AA:15:FA passkey 0
> HCI Event: Command Complete (0x0e) plen 10
User Passkey Request Reply (0x01|0x002e) ncmd 1
status 0x00 bdaddr D4:E8:B2:AA:15:FA
> HCI Event: Simple Pairing Complete (0x36) plen 7
status 0x05 bdaddr D4:E8:B2:AA:15:FA
Error: Authentication Failure
> HCI Event: Auth Complete (0x06) plen 3
status 0x05 handle 12
Error: Authentication Failure
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 12 reason 0x05
Reason: Authentication Failure
< HCI Command: Create Connection (0x01|0x0005) plen 13
bdaddr D4:E8:B2:AA:15:FA ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 12 bdaddr D4:E8:B2:AA:15:FA type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 12
Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 12 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Max Slots Change (0x1b) plen 3
handle 12 slots 5
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 12 page 1 max 1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr D4:E8:B2:AA:15:FA mode 2 clkoffset 0x0000
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr D4:E8:B2:AA:15:FA name 'theta'
< HCI Command: Authentication Requested (0x01|0x0011) plen 2
handle 12
> HCI Event: Command Status (0x0f) plen 4
Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> HCI Event: Link Key Request (0x17) plen 6
bdaddr D4:E8:B2:AA:15:FA
< HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
bdaddr D4:E8:B2:AA:15:FA
> HCI Event: Command Complete (0x0e) plen 10
Link Key Request Negative Reply (0x01|0x000c) ncmd 1
status 0x00 bdaddr D4:E8:B2:AA:15:FA
> HCI Event: IO Capability Request (0x31) plen 6
bdaddr D4:E8:B2:AA:15:FA
< HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
bdaddr D4:E8:B2:AA:15:FA capability 0x04 oob 0x00 auth 0x03
Capability: Reserved (OOB data not present)
Authentication: Dedicated Bonding (MITM Protection)
> HCI Event: Command Complete (0x0e) plen 10
IO Capability Request Reply (0x01|0x002b) ncmd 1
status 0x00 bdaddr D4:E8:B2:AA:15:FA
> HCI Event: IO Capability Response (0x32) plen 9
bdaddr D4:E8:B2:AA:15:FA capability 0x01 oob 0x00 auth 0x03
Capability: DisplayYesNo (OOB data not present)
Authentication: Dedicated Bonding (MITM Protection)
> HCI Event: User Passkey Request (0x34) plen 6
bdaddr D4:E8:B2:AA:15:FA
< HCI Command: User Passkey Request Reply (0x01|0x002e) plen 10
bdaddr D4:E8:B2:AA:15:FA passkey 0
> HCI Event: Command Complete (0x0e) plen 10
User Passkey Request Reply (0x01|0x002e) ncmd 1
status 0x00 bdaddr D4:E8:B2:AA:15:FA
> HCI Event: Simple Pairing Complete (0x36) plen 7
status 0x05 bdaddr D4:E8:B2:AA:15:FA
Error: Authentication Failure
> HCI Event: Auth Complete (0x06) plen 3
status 0x05 handle 12
Error: Authentication Failure
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 12 reason 0x05
Reason: Authentication Failure
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
--
http://modnebzdury.wordpress.com/2009/10/01/niewiarygodny-list-prof-majewskiej-wprowadzenie/
I want to reach your mind -- where is it currently located?
^ permalink raw reply
* [PATCH BlueZ 11/11] AVRCP: Fix not checking for media_player_controller_create
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Now that the MediaPlayer1 interface is experimental the interface
registration may fail which return NULL, in that case there is no
point on register to any notifications.
---
profiles/audio/avrcp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
index 4e3d31d..ce070cd 100644
--- a/profiles/audio/avrcp.c
+++ b/profiles/audio/avrcp.c
@@ -1987,6 +1987,11 @@ static gboolean avrcp_get_capabilities_resp(struct avctp *conn,
count = pdu->params[1];
+ path = device_get_path(session->dev->btd_dev);
+ mp = media_player_controller_create(path);
+ if (mp == NULL)
+ return FALSE;
+
for (; count > 0; count--) {
uint8_t event = pdu->params[1 + count];
@@ -2001,8 +2006,6 @@ static gboolean avrcp_get_capabilities_resp(struct avctp *conn,
}
}
- path = device_get_path(session->dev->btd_dev);
- mp = media_player_controller_create(path);
media_player_set_callbacks(mp, &ct_cbs, player);
player->user_data = mp;
player->destroy = (GDestroyNotify) media_player_destroy;
--
1.8.0.1
^ permalink raw reply related
* [PATCH BlueZ 10/11] player: Enable MediaPlayer1 interface as experimental
From: Luiz Augusto von Dentz @ 2012-12-28 12:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1356699069-5469-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This enable MediaPlayer1 when GDBUS_EXPERIMENTAL=1
---
profiles/audio/player.c | 28 ++++++++++++++++------------
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/profiles/audio/player.c b/profiles/audio/player.c
index 005d0d1..693a590 100644
--- a/profiles/audio/player.c
+++ b/profiles/audio/player.c
@@ -239,25 +239,31 @@ static void set_setting(const GDBusPropertyTable *property,
}
static const GDBusMethodTable media_player_methods[] = {
- { GDBUS_METHOD("GetTrack",
+ { GDBUS_EXPERIMENTAL_METHOD("GetTrack",
NULL, GDBUS_ARGS({ "metadata", "a{sv}" }),
media_player_get_track) },
{ }
};
static const GDBusSignalTable media_player_signals[] = {
- { GDBUS_SIGNAL("TrackChanged",
+ { GDBUS_EXPERIMENTAL_SIGNAL("TrackChanged",
GDBUS_ARGS({ "metadata", "a{sv}" })) },
{ }
};
static const GDBusPropertyTable media_player_properties[] = {
- { "Position", "u", get_position },
- { "Status", "s", get_status, NULL, status_exists },
- { "Equalizer", "s", get_setting, set_setting, setting_exists },
- { "Repeat", "s", get_setting, set_setting, setting_exists },
- { "Shuffle", "s", get_setting, set_setting, setting_exists },
- { "Scan", "s", get_setting, set_setting, setting_exists },
+ { "Position", "u", get_position, NULL, NULL,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Status", "s", get_status, NULL, status_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Equalizer", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Repeat", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Shuffle", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
+ { "Scan", "s", get_setting, set_setting, setting_exists,
+ G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
{ }
};
@@ -298,7 +304,6 @@ struct media_player *media_player_controller_create(const char *path)
g_free, g_free);
mp->progress = g_timer_new();
-#if 0
if (!g_dbus_register_interface(btd_get_dbus_connection(),
mp->path, MEDIA_PLAYER_INTERFACE,
media_player_methods,
@@ -308,7 +313,7 @@ struct media_player *media_player_controller_create(const char *path)
media_player_destroy(mp);
return NULL;
}
-#endif
+
DBG("%s", mp->path);
return mp;
@@ -410,7 +415,6 @@ void media_player_set_status(struct media_player *mp, const char *status)
static gboolean process_metadata_changed(void *user_data)
{
-#if 0
struct media_player *mp = user_data;
DBusMessage *signal;
DBusMessageIter iter, dict;
@@ -439,7 +443,7 @@ static gboolean process_metadata_changed(void *user_data)
dbus_message_iter_close_container(&iter, &dict);
g_dbus_send_message(btd_get_dbus_connection(), signal);
-#endif
+
return FALSE;
}
--
1.8.0.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox