All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/2] Report local services(UUIDs) through DBus
@ 2010-03-26 22:54 Francisco Alecrim
  2010-03-26 22:54 ` [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change Francisco Alecrim
  0 siblings, 1 reply; 9+ messages in thread
From: Francisco Alecrim @ 2010-03-26 22:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Francisco Alecrim

Include UUIDs field to method GetProperties(org.bluez.Adapter).
Applications can get local services(UUIDs) available through DBus.
---
 doc/adapter-api.txt |    5 +++++
 src/adapter.c       |   20 +++++++++++++++++++-
 src/sdpd-database.c |   20 ++++++++++++++++++++
 src/sdpd.h          |    1 +
 test/list-devices   |    3 +++
 5 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 48cab40..6098c76 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -270,3 +270,8 @@ Properties	string Address [readonly]
 		array{object} Devices [readonly]
 
 			List of device object paths.
+
+		array{string} UUIDs [readonly]
+
+			List of 128-bit UUIDs that represents the available
+			local services.
diff --git a/src/adapter.c b/src/adapter.c
index 5fd0736..2027484 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -37,6 +37,7 @@
 #include <bluetooth/hci.h>
 #include <bluetooth/hci_lib.h>
 #include <bluetooth/sdp.h>
+#include <bluetooth/sdp_lib.h>
 
 #include <glib.h>
 #include <dbus/dbus.h>
@@ -1196,7 +1197,8 @@ static DBusMessage *get_properties(DBusConnection *conn,
 	DBusMessageIter dict;
 	char str[MAX_NAME_LENGTH + 1], srcaddr[18];
 	gboolean value;
-	char **devices;
+	char **devices, **uuids;
+	sdp_list_t *list, *lfree;
 	int i;
 	GSList *l;
 
@@ -1270,6 +1272,22 @@ static DBusMessage *get_properties(DBusConnection *conn,
 								&devices, i);
 	g_free(devices);
 
+	/* UUIDs */
+	list = sdp_get_record_list_by_device(&adapter->bdaddr);
+	lfree = list; /* keep head to prevent leak */
+	uuids = g_new0(char *, sdp_list_len(list) + 1);
+
+	for (i = 0; list; list = list->next, i++) {
+		sdp_record_t *rec = list->data;
+		uuids[i] = bt_uuid2string(&rec->svclass);
+	}
+	dict_append_array(&dict, "UUIDs", DBUS_TYPE_STRING, &uuids, i);
+
+	sdp_list_free(lfree, NULL);
+	for (i = 0; uuids[i]; i++)
+		g_free(uuids[i]);
+	g_free(uuids);
+
 	dbus_message_iter_close_container(&iter, &dict);
 
 	return reply;
diff --git a/src/sdpd-database.c b/src/sdpd-database.c
index 07a0bc3..8f99758 100644
--- a/src/sdpd-database.c
+++ b/src/sdpd-database.c
@@ -273,6 +273,26 @@ sdp_list_t *sdp_get_access_list(void)
 	return access_db;
 }
 
+sdp_list_t *sdp_get_record_list_by_device(const bdaddr_t *device)
+{
+	sdp_list_t *list, *acc;
+
+	acc = access_db;
+	list = NULL;
+	for (; acc; acc = acc->next) {
+		sdp_access_t *a = acc->data;
+		sdp_record_t *rec = sdp_record_find(a->handle);
+		if (!rec)
+			continue;
+
+		if (bacmp(&a->device, device) == 0 ||
+				bacmp(&a->device, BDADDR_ANY) == 0)
+			list = sdp_list_append(list, rec);
+	}
+
+	return list;
+}
+
 int sdp_check_access(uint32_t handle, bdaddr_t *device)
 {
 	sdp_list_t *p = access_locate(handle);
diff --git a/src/sdpd.h b/src/sdpd.h
index 1352a83..15e163b 100644
--- a/src/sdpd.h
+++ b/src/sdpd.h
@@ -79,6 +79,7 @@ void sdp_record_add(const bdaddr_t *device, sdp_record_t *rec);
 int sdp_record_remove(uint32_t handle);
 sdp_list_t *sdp_get_record_list(void);
 sdp_list_t *sdp_get_access_list(void);
+sdp_list_t *sdp_get_record_list_by_device(const bdaddr_t *device);
 int sdp_check_access(uint32_t handle, bdaddr_t *device);
 uint32_t sdp_next_handle(void);
 
diff --git a/test/list-devices b/test/list-devices
index 511d0cf..9120714 100755
--- a/test/list-devices
+++ b/test/list-devices
@@ -40,6 +40,9 @@ for i in adapter_list:
 		if (key == "Devices"):
 			list = extract_objects(value)
 			print "    %s = %s" % (key, list)
+		elif (key == "UUIDs"):
+			list = extract_uuids(value)
+			print "    %s = %s" % (key, list)
 		else:
 			print "    %s = %s" % (key, value)
 
-- 
1.6.3.3


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-26 22:54 [PATCH v2 1/2] Report local services(UUIDs) through DBus Francisco Alecrim
@ 2010-03-26 22:54 ` Francisco Alecrim
  2010-03-29  7:45   ` Johan Hedberg
  0 siblings, 1 reply; 9+ messages in thread
From: Francisco Alecrim @ 2010-03-26 22:54 UTC (permalink / raw)
  To: linux-bluetooth; +Cc: Francisco Alecrim

Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
to inform that adapter properties changed.
---
 src/adapter.c       |   75 ++++++++++++++++++++++++++++++++++++++++++++------
 src/adapter.h       |    1 +
 src/sdpd-database.c |    3 ++
 3 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/src/adapter.c b/src/adapter.c
index 2027484..884762f 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1034,6 +1034,71 @@ static void adapter_update_devices(struct btd_adapter *adapter)
 	g_free(devices);
 }
 
+static char **adapter_get_uuids(struct btd_adapter *adapter)
+{
+	char **uuids;
+	sdp_list_t *list, *lfree;
+	int i;
+
+	list = sdp_get_record_list_by_device(&adapter->bdaddr);
+	if (!list)
+		return NULL;
+
+	/* Keep head to prevent leak */
+	lfree = list;
+	uuids = g_new0(char *, sdp_list_len(list) + 1);
+	for (i = 0; list; list = list->next, i++) {
+		sdp_record_t *rec = list->data;
+		uuids[i] = bt_uuid2string(&rec->svclass);
+	}
+
+	sdp_list_free(lfree, NULL);
+	return uuids;
+}
+
+static void adapter_emit_uuids_updated(struct btd_adapter *adapter)
+{
+	char **uuids;
+	int i;
+
+	uuids = adapter_get_uuids(adapter);
+	if (!uuids)
+		return;
+
+	emit_array_property_changed(connection, adapter->path,
+			ADAPTER_INTERFACE, "UUIDs",
+			DBUS_TYPE_STRING, &uuids);
+
+	for (i = 0; uuids[i]; i++)
+		g_free(uuids[i]);
+	g_free(uuids);
+}
+
+void adapter_uuids_updated(const bdaddr_t *bdaddr)
+{
+	GSList *adapters;
+	struct btd_adapter *adapter;
+
+	if (bacmp(bdaddr, BDADDR_ANY) != 0) {
+		/* Only one adapter */
+		adapter = manager_find_adapter(bdaddr);
+		if (!adapter)
+			return;
+
+		adapter_emit_uuids_updated(adapter);
+
+		return;
+	}
+
+	/* Emit D-Bus msg to all adapters */
+	adapters = manager_get_adapters();
+
+	for (; adapters; adapters = adapters->next) {
+		adapter = adapters->data;
+		adapter_emit_uuids_updated(adapter);
+	}
+}
+
 struct btd_device *adapter_create_device(DBusConnection *conn,
 						struct btd_adapter *adapter,
 						const char *address)
@@ -1198,7 +1263,6 @@ static DBusMessage *get_properties(DBusConnection *conn,
 	char str[MAX_NAME_LENGTH + 1], srcaddr[18];
 	gboolean value;
 	char **devices, **uuids;
-	sdp_list_t *list, *lfree;
 	int i;
 	GSList *l;
 
@@ -1273,17 +1337,10 @@ static DBusMessage *get_properties(DBusConnection *conn,
 	g_free(devices);
 
 	/* UUIDs */
-	list = sdp_get_record_list_by_device(&adapter->bdaddr);
-	lfree = list; /* keep head to prevent leak */
-	uuids = g_new0(char *, sdp_list_len(list) + 1);
+	uuids = adapter_get_uuids(adapter);
 
-	for (i = 0; list; list = list->next, i++) {
-		sdp_record_t *rec = list->data;
-		uuids[i] = bt_uuid2string(&rec->svclass);
-	}
 	dict_append_array(&dict, "UUIDs", DBUS_TYPE_STRING, &uuids, i);
 
-	sdp_list_free(lfree, NULL);
 	for (i = 0; uuids[i]; i++)
 		g_free(uuids[i]);
 	g_free(uuids);
diff --git a/src/adapter.h b/src/adapter.h
index 9b4ce10..e453eff 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -121,6 +121,7 @@ void adapter_mode_changed(struct btd_adapter *adapter, uint8_t scan_mode);
 void adapter_setname_complete(bdaddr_t *local, uint8_t status);
 void adapter_update_tx_power(bdaddr_t *bdaddr, uint8_t status, void *ptr);
 void adapter_update_local_name(bdaddr_t *bdaddr, uint8_t status, void *ptr);
+void adapter_uuids_updated(const bdaddr_t *bdaddr);
 void adapter_set_class_complete(bdaddr_t *bdaddr, uint8_t status);
 
 struct agent *adapter_get_agent(struct btd_adapter *adapter);
diff --git a/src/sdpd-database.c b/src/sdpd-database.c
index 8f99758..97befe0 100644
--- a/src/sdpd-database.c
+++ b/src/sdpd-database.c
@@ -40,6 +40,7 @@
 
 #include "sdpd.h"
 #include "logging.h"
+#include "adapter.h"
 
 static sdp_list_t *service_db;
 static sdp_list_t *access_db;
@@ -183,6 +184,7 @@ void sdp_record_add(const bdaddr_t *device, sdp_record_t *rec)
 	dev->handle = rec->handle;
 
 	access_db = sdp_list_insert_sorted(access_db, dev, access_sort);
+	adapter_uuids_updated(device);
 }
 
 static sdp_list_t *record_locate(uint32_t handle)
@@ -253,6 +255,7 @@ int sdp_record_remove(uint32_t handle)
 		a = (sdp_access_t *) p->data;
 		if (a) {
 			access_db = sdp_list_remove(access_db, a);
+			adapter_uuids_updated(&a->device);
 			access_free(a);
 		}
 	}
-- 
1.6.3.3


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-26 22:54 ` [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change Francisco Alecrim
@ 2010-03-29  7:45   ` Johan Hedberg
  2010-03-29  8:29     ` Marcel Holtmann
  0 siblings, 1 reply; 9+ messages in thread
From: Johan Hedberg @ 2010-03-29  7:45 UTC (permalink / raw)
  To: Francisco Alecrim; +Cc: linux-bluetooth, marcel

Hi,

On Fri, Mar 26, 2010, Francisco Alecrim wrote:
> Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
> to inform that adapter properties changed.
> ---
>  src/adapter.c       |   75 ++++++++++++++++++++++++++++++++++++++++++++------
>  src/adapter.h       |    1 +
>  src/sdpd-database.c |    3 ++
>  3 files changed, 70 insertions(+), 9 deletions(-)

Thanks for the patches. In principle they look good, but I haven't
applied them yet due to one thing that looks a bit strange: both the SDP
server record UUID (0x1000) as well as the public browse group UUID
(0x1001) always show up in the UUIDs list. I wonder if there'd be any
clean way to avoid getting them into the list. Marcel, do you have any
idea about this or is it even a problem that these UUIDs are always in
the list?

Johan

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-29  7:45   ` Johan Hedberg
@ 2010-03-29  8:29     ` Marcel Holtmann
  2010-03-29 18:48       ` Luiz Augusto von Dentz
  0 siblings, 1 reply; 9+ messages in thread
From: Marcel Holtmann @ 2010-03-29  8:29 UTC (permalink / raw)
  To: Johan Hedberg; +Cc: Francisco Alecrim, linux-bluetooth

Hi Johan,

> > Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
> > to inform that adapter properties changed.
> > ---
> >  src/adapter.c       |   75 ++++++++++++++++++++++++++++++++++++++++++++------
> >  src/adapter.h       |    1 +
> >  src/sdpd-database.c |    3 ++
> >  3 files changed, 70 insertions(+), 9 deletions(-)
> 
> Thanks for the patches. In principle they look good, but I haven't
> applied them yet due to one thing that looks a bit strange: both the SDP
> server record UUID (0x1000) as well as the public browse group UUID
> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
> clean way to avoid getting them into the list. Marcel, do you have any
> idea about this or is it even a problem that these UUIDs are always in
> the list?

these UUIDs are always in the server, but not in the public browse group
and we skip them on purpose. The only reason why they are always present
is that the specification requires it.

Regards

Marcel



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-29  8:29     ` Marcel Holtmann
@ 2010-03-29 18:48       ` Luiz Augusto von Dentz
  2010-03-29 21:52         ` Johan Hedberg
  0 siblings, 1 reply; 9+ messages in thread
From: Luiz Augusto von Dentz @ 2010-03-29 18:48 UTC (permalink / raw)
  To: Marcel Holtmann; +Cc: Johan Hedberg, Francisco Alecrim, linux-bluetooth

Hi,

On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@holtmann.org> wro=
te:
> Hi Johan,
>
>> > Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus messa=
ge
>> > to inform that adapter properties changed.
>> > ---
>> > =A0src/adapter.c =A0 =A0 =A0 | =A0 75 ++++++++++++++++++++++++++++++++=
++++++++++++------
>> > =A0src/adapter.h =A0 =A0 =A0 | =A0 =A01 +
>> > =A0src/sdpd-database.c | =A0 =A03 ++
>> > =A03 files changed, 70 insertions(+), 9 deletions(-)
>>
>> Thanks for the patches. In principle they look good, but I haven't
>> applied them yet due to one thing that looks a bit strange: both the SDP
>> server record UUID (0x1000) as well as the public browse group UUID
>> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
>> clean way to avoid getting them into the list. Marcel, do you have any
>> idea about this or is it even a problem that these UUIDs are always in
>> the list?
>
> these UUIDs are always in the server, but not in the public browse group
> and we skip them on purpose. The only reason why they are always present
> is that the specification requires it.

IMO, it should be the same list as we export in extended inquiry
response, so perhaps we could use the data from
create_ext_inquiry_response which already filter those away. Perhaps
some refactoring could also be done since this code seems to be called
multiple times in case of new services because it also changes class
which then triggers create_ext_inquiry_response again.


--=20
Luiz Augusto von Dentz
Computer Engineer

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-29 18:48       ` Luiz Augusto von Dentz
@ 2010-03-29 21:52         ` Johan Hedberg
  2010-03-29 22:12           ` Francisco Alecrim
  0 siblings, 1 reply; 9+ messages in thread
From: Johan Hedberg @ 2010-03-29 21:52 UTC (permalink / raw)
  To: Luiz Augusto von Dentz
  Cc: Marcel Holtmann, Francisco Alecrim, linux-bluetooth

Hi Luiz,

On Mon, Mar 29, 2010, Luiz Augusto von Dentz wrote:
> On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> > Hi Johan,
> >
> >> > Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
> >> > to inform that adapter properties changed.
> >> > ---
> >> >  src/adapter.c       |   75 ++++++++++++++++++++++++++++++++++++++++++++------
> >> >  src/adapter.h       |    1 +
> >> >  src/sdpd-database.c |    3 ++
> >> >  3 files changed, 70 insertions(+), 9 deletions(-)
> >>
> >> Thanks for the patches. In principle they look good, but I haven't
> >> applied them yet due to one thing that looks a bit strange: both the SDP
> >> server record UUID (0x1000) as well as the public browse group UUID
> >> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
> >> clean way to avoid getting them into the list. Marcel, do you have any
> >> idea about this or is it even a problem that these UUIDs are always in
> >> the list?
> >
> > these UUIDs are always in the server, but not in the public browse group
> > and we skip them on purpose. The only reason why they are always present
> > is that the specification requires it.
> 
> IMO, it should be the same list as we export in extended inquiry
> response, so perhaps we could use the data from
> create_ext_inquiry_response which already filter those away. Perhaps
> some refactoring could also be done since this code seems to be called
> multiple times in case of new services because it also changes class
> which then triggers create_ext_inquiry_response again.

That makes quite a lot sense, and is actually what I was chatting with
Marcel about earlier today on irc. The EIR UUIDs list does have a few
restrictions though that the Adapter UUIDs property doesn't have, such
as a maximum limit on the amount of UUIDs (since EIR data is quite
limited in size), so the lists will not always be exactly the same.

You can see the creation of the EIR list in the for-loop of the
create_ext_inquiry_response function in sdpd-service.c. The most
important part for the Adapter UUIDs property would be the following
code snippet which also answers the original question I had about how to
best get rid of the unnecessary UUIDs:

       if (rec->svclass.value.uuid16 < 0x1100)
               continue;
       if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID)
               continue;

In addition those there's also the duplicate UUID check which I think
the original patch was missing. So, if the same code could somehow be
reused for EIR and the Adapter UUIDs property it'd be great. However, if
it's too messy, the above two filters and the duplicate UUID check
should at least be applied to the Adapter UUIDs property.

Johan

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-29 21:52         ` Johan Hedberg
@ 2010-03-29 22:12           ` Francisco Alecrim
  2010-03-29 22:56             ` Johan Hedberg
  0 siblings, 1 reply; 9+ messages in thread
From: Francisco Alecrim @ 2010-03-29 22:12 UTC (permalink / raw)
  To: Luiz Augusto von Dentz, Marcel Holtmann, Francisco Alecrim,
	linux-bluetooth

Hi Johan and Luiz,

Johan Hedberg wrote:
> Hi Luiz,
> 
> On Mon, Mar 29, 2010, Luiz Augusto von Dentz wrote:
>> On Mon, Mar 29, 2010 at 11:29 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
>>> Hi Johan,
>>>
>>>>> Emitting Adapter.PropertyChanged signal when UUIDs change. D-Bus message
>>>>> to inform that adapter properties changed.
>>>>> ---
>>>>>  src/adapter.c       |   75 ++++++++++++++++++++++++++++++++++++++++++++------
>>>>>  src/adapter.h       |    1 +
>>>>>  src/sdpd-database.c |    3 ++
>>>>>  3 files changed, 70 insertions(+), 9 deletions(-)
>>>> Thanks for the patches. In principle they look good, but I haven't
>>>> applied them yet due to one thing that looks a bit strange: both the SDP
>>>> server record UUID (0x1000) as well as the public browse group UUID
>>>> (0x1001) always show up in the UUIDs list. I wonder if there'd be any
>>>> clean way to avoid getting them into the list. Marcel, do you have any
>>>> idea about this or is it even a problem that these UUIDs are always in
>>>> the list?
>>> these UUIDs are always in the server, but not in the public browse group
>>> and we skip them on purpose. The only reason why they are always present
>>> is that the specification requires it.
>> IMO, it should be the same list as we export in extended inquiry
>> response, so perhaps we could use the data from
>> create_ext_inquiry_response which already filter those away. Perhaps
>> some refactoring could also be done since this code seems to be called
>> multiple times in case of new services because it also changes class
>> which then triggers create_ext_inquiry_response again.

I'm not so sure about it but create_ext_inquiry_response list all
services to any adapters. Shouldn't it list just services per
adapter(access_db)?

> 
> That makes quite a lot sense, and is actually what I was chatting with
> Marcel about earlier today on irc. The EIR UUIDs list does have a few
> restrictions though that the Adapter UUIDs property doesn't have, such
> as a maximum limit on the amount of UUIDs (since EIR data is quite
> limited in size), so the lists will not always be exactly the same.
> 
> You can see the creation of the EIR list in the for-loop of the
> create_ext_inquiry_response function in sdpd-service.c. The most
> important part for the Adapter UUIDs property would be the following
> code snippet which also answers the original question I had about how to
> best get rid of the unnecessary UUIDs:
> 
>        if (rec->svclass.value.uuid16 < 0x1100)
>                continue;
>        if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID)
>                continue;
> 
> In addition those there's also the duplicate UUID check which I think
> the original patch was missing. So, if the same code could somehow be
> reused for EIR and the Adapter UUIDs property it'd be great. However, if
> it's too messy, the above two filters and the duplicate UUID check
> should at least be applied to the Adapter UUIDs property.

Great! That's the piece of code I was trying to find. I'll try
re-organize this code.

Thanks,
Alecrim.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-29 22:12           ` Francisco Alecrim
@ 2010-03-29 22:56             ` Johan Hedberg
  2010-03-30  1:21               ` Marcel Holtmann
  0 siblings, 1 reply; 9+ messages in thread
From: Johan Hedberg @ 2010-03-29 22:56 UTC (permalink / raw)
  To: Francisco Alecrim
  Cc: Luiz Augusto von Dentz, Marcel Holtmann, linux-bluetooth

Hi Alecrim,

On Mon, Mar 29, 2010, Francisco Alecrim wrote:
> >> IMO, it should be the same list as we export in extended inquiry
> >> response, so perhaps we could use the data from
> >> create_ext_inquiry_response which already filter those away. Perhaps
> >> some refactoring could also be done since this code seems to be called
> >> multiple times in case of new services because it also changes class
> >> which then triggers create_ext_inquiry_response again.
> 
> I'm not so sure about it but create_ext_inquiry_response list all
> services to any adapters. Shouldn't it list just services per
> adapter(access_db)?

It should be per-adapter (or records registered to BDADDR_ANY) since EIR
is also per-adapter, so looks like a possible bug in the current
implementation.

Btw, another restriction to note with the current EIR UUID list
implementation is that it only supports 16-bit UUIDs. The EIR format
itself would support also 32 and 128 bit formats but probably for
simplicity these have been left out. The Adapter UUIDs list should
however contain all UUIDs (with the exceptions that we already
discussed).

Johan

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change
  2010-03-29 22:56             ` Johan Hedberg
@ 2010-03-30  1:21               ` Marcel Holtmann
  0 siblings, 0 replies; 9+ messages in thread
From: Marcel Holtmann @ 2010-03-30  1:21 UTC (permalink / raw)
  To: Johan Hedberg; +Cc: Francisco Alecrim, Luiz Augusto von Dentz, linux-bluetooth

Hi Johan,

> > >> IMO, it should be the same list as we export in extended inquiry
> > >> response, so perhaps we could use the data from
> > >> create_ext_inquiry_response which already filter those away. Perhaps
> > >> some refactoring could also be done since this code seems to be called
> > >> multiple times in case of new services because it also changes class
> > >> which then triggers create_ext_inquiry_response again.
> > 
> > I'm not so sure about it but create_ext_inquiry_response list all
> > services to any adapters. Shouldn't it list just services per
> > adapter(access_db)?
> 
> It should be per-adapter (or records registered to BDADDR_ANY) since EIR
> is also per-adapter, so looks like a possible bug in the current
> implementation.
> 
> Btw, another restriction to note with the current EIR UUID list
> implementation is that it only supports 16-bit UUIDs. The EIR format
> itself would support also 32 and 128 bit formats but probably for
> simplicity these have been left out. The Adapter UUIDs list should
> however contain all UUIDs (with the exceptions that we already
> discussed).

it should also contain the UUID-128 ones (the UUID-32 are pointless and
with LE they are gone for good). The reason why these were left out is
because it is pretty hard to fit them into the limited space of EIR. If
you are up for fixing this, then I am more than happy to have this. I
think we need to introduce some priority mapping here to decide which
UUID list to cut in favor of others. Same as how we can shortcut the
device name etc.

So in general the DID information and at least a short device name
should be present. For the short name, we might need another config file
option or some plugin way of retrieving the short name. Also I want to
have the TX power information available if the chip supports it.

The rest of the space can be used for UUIDs in whatever way fits. The
more UUIDs are in the list the better actually.

Regards

Marcel



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2010-03-30  1:21 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-26 22:54 [PATCH v2 1/2] Report local services(UUIDs) through DBus Francisco Alecrim
2010-03-26 22:54 ` [PATCH v2 2/2] Emit Adapter.PropertyChanged when UUIDs change Francisco Alecrim
2010-03-29  7:45   ` Johan Hedberg
2010-03-29  8:29     ` Marcel Holtmann
2010-03-29 18:48       ` Luiz Augusto von Dentz
2010-03-29 21:52         ` Johan Hedberg
2010-03-29 22:12           ` Francisco Alecrim
2010-03-29 22:56             ` Johan Hedberg
2010-03-30  1:21               ` Marcel Holtmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.