* Re: [PATCH 4/5] adaptername: Remove not needed empty remove callback
From: Johan Hedberg @ 2012-11-26 11:26 UTC (permalink / raw)
To: Szymon Janc; +Cc: Anderson Lizardo, linux-bluetooth@vger.kernel.org
In-Reply-To: <7243377.vN3q5Zuh5I@uw000953>
Hi Szymon,
On Mon, Nov 26, 2012, Szymon Janc wrote:
> On Monday 26 of November 2012 12:45:30 Anderson Lizardo wrote:
> > Hi Szymon,
>
> Hi Anderson,
>
> >
> > On Mon, Nov 26, 2012 at 5:07 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> > > static struct btd_adapter_driver adaptername_driver = {
> > > .name = "adaptername",
> > > .probe = adaptername_probe,
> > > - .remove = adaptername_remove,
> > > + .remove = NULL,
> > > };
> >
> > This variable is static, so not explicitly initialized members will be NULL.
>
> Yes, yet according to code style for bluez statics should be initialized
> explicitly, right? Or this does not count for struct members?
I've left this out for struct members at least in new code so I'd say
that it's not needed.
Johan
^ permalink raw reply
* Re: [PATCH 4/5] adaptername: Remove not needed empty remove callback
From: Szymon Janc @ 2012-11-26 10:52 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CAJdJm_OLsmmxvLddeT2T=Xg427=ADNNdmfSRre5+jB-inTiGBw@mail.gmail.com>
On Monday 26 of November 2012 12:45:30 Anderson Lizardo wrote:
> Hi Szymon,
Hi Anderson,
>
> On Mon, Nov 26, 2012 at 5:07 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> > static struct btd_adapter_driver adaptername_driver = {
> > .name = "adaptername",
> > .probe = adaptername_probe,
> > - .remove = adaptername_remove,
> > + .remove = NULL,
> > };
>
> This variable is static, so not explicitly initialized members will be NULL.
Yes, yet according to code style for bluez statics should be initialized
explicitly, right? Or this does not count for struct members?
--
BR
Szymon Janc
^ permalink raw reply
* [RFC] doc: Split media transport volume into two parts
From: Mikel Astiz @ 2012-11-26 10:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.von.dentz, Mikel Astiz
From: Mikel Astiz <mikel.astiz@bmw-carit.de>
Separate the input and output audio volumes in two independent
properties in order to control both speaker and microphone gains while
doing HSP/HFP.
---
This property was introduced quite recently but never implemented. Shouldn't we split it into two separate properties?
It wouldn't do much harm for the A2DP transports and it would be needed for HSP/HFP.
doc/media-api.txt | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/doc/media-api.txt b/doc/media-api.txt
index b4f2fc6..6515e5f 100644
--- a/doc/media-api.txt
+++ b/doc/media-api.txt
@@ -375,10 +375,18 @@ Properties object Device [readonly]
Possible Values: "HCI" or "PCM"
- uint16 Volume [readwrite]
+ uint16 InputVolume [readwrite] [optional]
- Optional. Indicates volume level of the transport,
- this property is only writeable when the transport was
- acquired by the sender.
+ Indicates volume level of the transport's incoming
+ audio stream, if any. This property is only writeable
+ when the transport was acquired by the sender.
+
+ Possible Values: 0-127
+
+ uint16 OutputVolume [readwrite] [optional]
+
+ Indicates volume level of the transport's outgoing
+ audio stream, if any. This property is only writeable
+ when the transport was acquired by the sender.
Possible Values: 0-127
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 4/5] adaptername: Remove not needed empty remove callback
From: Anderson Lizardo @ 2012-11-26 10:45 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1353920860-14912-4-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Mon, Nov 26, 2012 at 5:07 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> static struct btd_adapter_driver adaptername_driver = {
> .name = "adaptername",
> .probe = adaptername_probe,
> - .remove = adaptername_remove,
> + .remove = NULL,
> };
This variable is static, so not explicitly initialized members will be NULL.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 5/5] formfactor: Remove not needed empty remove callback
From: Szymon Janc @ 2012-11-26 9:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1353920860-14912-1-git-send-email-szymon.janc@tieto.com>
Remove callback is called only if it is not NULL so there is no need to
register empty callback function.
---
plugins/formfactor.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/plugins/formfactor.c b/plugins/formfactor.c
index 0e19ac6..41f9c2a 100644
--- a/plugins/formfactor.c
+++ b/plugins/formfactor.c
@@ -124,14 +124,10 @@ static int formfactor_probe(struct btd_adapter *adapter)
return 0;
}
-static void formfactor_remove(struct btd_adapter *adapter)
-{
-}
-
static struct btd_adapter_driver formfactor_driver = {
.name = "formfactor",
.probe = formfactor_probe,
- .remove = formfactor_remove,
+ .remove = NULL,
};
static int formfactor_init(void)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] adaptername: Remove not needed empty remove callback
From: Szymon Janc @ 2012-11-26 9:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1353920860-14912-1-git-send-email-szymon.janc@tieto.com>
Remove callback is called only if it is not NULL so there is no need to
register empty callback function.
---
plugins/adaptername.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/plugins/adaptername.c b/plugins/adaptername.c
index 353f11c..745238a 100644
--- a/plugins/adaptername.c
+++ b/plugins/adaptername.c
@@ -261,14 +261,10 @@ fail:
return FALSE;
}
-static void adaptername_remove(struct btd_adapter *adapter)
-{
-}
-
static struct btd_adapter_driver adaptername_driver = {
.name = "adaptername",
.probe = adaptername_probe,
- .remove = adaptername_remove,
+ .remove = NULL,
};
static int adaptername_init(void)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] adapter: Call driver remove callback when unregistering driver
From: Szymon Janc @ 2012-11-26 9:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1353920860-14912-1-git-send-email-szymon.janc@tieto.com>
This seems to be what plugins expect as only dbusoob explicite called
its remove function before unregistering adapter drivers.
This results in cleaner shutdown path:
Without patch:
bluetoothd[13563]: src/mgmt.c:mgmt_remove_uuid() index 0
bluetoothd[13563]: src/adapter.c:btd_adapter_unref() 0x606b2a0: ref=4
bluetoothd[13563]: src/adapter.c:btd_adapter_unref() 0x606b2a0: ref=3
bluetoothd[13563]: Stopping SDP server
bluetoothd[13563]: Exit
==13563==
==13563== HEAP SUMMARY:
==13563== in use at exit: 64,908 bytes in 395 blocks
==13563== total heap usage: 7,035 allocs, 6,640 frees, 4,432,371 bytes allocated
==13563==
==13563== LEAK SUMMARY:
==13563== definitely lost: 0 bytes in 0 blocks
==13563== indirectly lost: 0 bytes in 0 blocks
==13563== possibly lost: 17,429 bytes in 169 blocks
==13563== still reachable: 47,479 bytes in 226 blocks
==13563== suppressed: 0 bytes in 0 blocks
With patch:
bluetoothd[13301]: src/mgmt.c:mgmt_remove_uuid() index 0
bluetoothd[13301]: src/adapter.c:btd_adapter_unref() 0x606b2a0: ref=1
bluetoothd[13301]: src/adapter.c:btd_adapter_unref() 0x606b2a0: ref=0
bluetoothd[13301]: src/adapter.c:adapter_free() 0x606b2a0
bluetoothd[13301]: Stopping SDP server
bluetoothd[13301]: Exit
==13301==
==13301== HEAP SUMMARY:
==13301== in use at exit: 64,954 bytes in 348 blocks
==13301== total heap usage: 7,247 allocs, 6,899 frees, 4,625,672 bytes allocated
==13301==
==13301== LEAK SUMMARY:
==13301== definitely lost: 0 bytes in 0 blocks
==13301== indirectly lost: 0 bytes in 0 blocks
==13301== possibly lost: 17,334 bytes in 150 blocks
==13301== still reachable: 47,620 bytes in 198 blocks
==13301== suppressed: 0 bytes in 0 blocks
---
plugins/dbusoob.c | 2 --
src/adapter.c | 5 +++++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/plugins/dbusoob.c b/plugins/dbusoob.c
index e58b353..7d9a858 100644
--- a/plugins/dbusoob.c
+++ b/plugins/dbusoob.c
@@ -346,8 +346,6 @@ static void dbusoob_exit(void)
{
DBG("Cleanup dbusoob plugin");
- manager_foreach_adapter((adapter_cb) oob_remove, NULL);
-
btd_unregister_adapter_driver(&oob_driver);
}
diff --git a/src/adapter.c b/src/adapter.c
index 0d1dfea..163360f 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3291,6 +3291,11 @@ int btd_register_adapter_driver(struct btd_adapter_driver *driver)
static void unload_driver(struct btd_adapter *adapter, gpointer data)
{
+ struct btd_adapter_driver *driver = data;
+
+ if (driver->remove)
+ driver->remove(adapter);
+
adapter->drivers = g_slist_remove(adapter->drivers, data);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] service: Remove not needed initialization
From: Szymon Janc @ 2012-11-26 9:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1353920860-14912-1-git-send-email-szymon.janc@tieto.com>
serv_adapter is allocated with g_try_new0 so there is no need to
explicite initialize its pending_list to NULL.
---
plugins/service.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/plugins/service.c b/plugins/service.c
index d70c515..af24839 100644
--- a/plugins/service.c
+++ b/plugins/service.c
@@ -509,8 +509,6 @@ static int register_interface(const char *path, struct btd_adapter *adapter)
if (serv_adapter == NULL)
return -ENOMEM;
- serv_adapter->pending_list = NULL;
-
if (g_dbus_register_interface(btd_get_dbus_connection(),
path, SERVICE_INTERFACE,
service_methods, NULL, NULL, serv_adapter,
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/5] service: Fix not unreferencing adapter in case of error
From: Szymon Janc @ 2012-11-26 9:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
If g_dbus_register_interface failed adapter reference was not dropped.
Move getting reference after succesful g_dbus_register_interface call.
---
plugins/service.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/plugins/service.c b/plugins/service.c
index ba7a693..d70c515 100644
--- a/plugins/service.c
+++ b/plugins/service.c
@@ -509,9 +509,6 @@ static int register_interface(const char *path, struct btd_adapter *adapter)
if (serv_adapter == NULL)
return -ENOMEM;
- if (adapter != NULL)
- serv_adapter->adapter = btd_adapter_ref(adapter);
-
serv_adapter->pending_list = NULL;
if (g_dbus_register_interface(btd_get_dbus_connection(),
@@ -520,13 +517,16 @@ static int register_interface(const char *path, struct btd_adapter *adapter)
path_unregister) == FALSE) {
error("D-Bus failed to register %s interface",
SERVICE_INTERFACE);
+
g_free(serv_adapter);
return -EIO;
}
DBG("Registered interface %s on path %s", SERVICE_INTERFACE, path);
- if (serv_adapter->adapter == NULL)
+ if (adapter != NULL)
+ serv_adapter->adapter = btd_adapter_ref(adapter);
+ else
serv_adapter_any = serv_adapter;
return 0;
--
1.7.9.5
^ permalink raw reply related
* RE: Sco issue:iogear dongle
From: Bluefrog @ 2012-11-25 11:07 UTC (permalink / raw)
To: 'Deepthi', linux-bluetooth
In-Reply-To: <50AB739F.4080202@globaledgesoft.com>
Well, firstly, u should provide HCIDump log, with "-X -t" option.
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org
[mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Deepthi
Sent: 2012年11月20日 20:12
To: linux-bluetooth@vger.kernel.org
Subject: Sco issue:iogear dongle
Hello,
I 'm facing an issue regarding the sco data transfer in iogear dongle
4.0 in linux-3.2.5 kernel version. sco is connected with sco handle as 1,
but i could see no sco data transfer .
Please help,
--
Thanks & Regards,
Deepthi Elizabeth P V
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
in the body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH BlueZ 1/2] hog: Fix potencial segfault when sending a output report
From: Johan Hedberg @ 2012-11-23 21:28 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1353697709-6497-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Fri, Nov 23, 2012, Vinicius Costa Gomes wrote:
> As UHID is not notified when the device is disconnected, it may be
> possible that an output report is forwarded when the device is not
> connected, one example, would be when the caps lock key is pressed on
> another keyboard.
> ---
> profiles/input/hog_device.c | 3 +++
> 1 file changed, 3 insertions(+)
Both patches have been applied. Thanks.
Johan
^ permalink raw reply
* [RFC BlueZ 3/3] hog: Fix registering HoG devices without vendor information
From: Vinicius Costa Gomes @ 2012-11-23 20:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1353702632-7960-1-git-send-email-vinicius.gomes@openbossa.org>
We use the newly added support for notifying when the PNP ID
information is ready before registering the HoG device.
---
profiles/input/hog_device.c | 75 ++++++++++++++++++++++++++++++++-------------
1 file changed, 53 insertions(+), 22 deletions(-)
diff --git a/profiles/input/hog_device.c b/profiles/input/hog_device.c
index 0a5fb58..28e3b50 100644
--- a/profiles/input/hog_device.c
+++ b/profiles/input/hog_device.c
@@ -78,6 +78,8 @@ struct hog_device {
guint attioid;
struct gatt_primary *hog_primary;
GSList *reports;
+ uint8_t *reportmap;
+ ssize_t reportmap_size;
int uhid_fd;
gboolean prepend_id;
guint uhid_watch_id;
@@ -335,13 +337,54 @@ static void external_report_reference_cb(guint8 status, const guint8 *pdu,
external_service_char_cb, hogdev);
}
+static void create_uhid_device(struct hog_device *hogdev, uint8_t *reportmap,
+ uint16_t rsize)
+{
+ struct uhid_event ev;
+ uint16_t vendor_src, vendor, product, version;
+
+ vendor_src = btd_device_get_vendor_src(hogdev->device);
+ vendor = btd_device_get_vendor(hogdev->device);
+ product = btd_device_get_product(hogdev->device);
+ version = btd_device_get_version(hogdev->device);
+ DBG("DIS information: vendor_src=0x%X, vendor=0x%X, product=0x%X, "
+ "version=0x%X", vendor_src, vendor, product, version);
+
+ /* create uHID device */
+ memset(&ev, 0, sizeof(ev));
+ ev.type = UHID_CREATE;
+ strcpy((char *) ev.u.create.name, "bluez-hog-device");
+ ev.u.create.vendor = vendor;
+ ev.u.create.product = product;
+ ev.u.create.version = version;
+ ev.u.create.country = hogdev->bcountrycode;
+ ev.u.create.bus = BUS_BLUETOOTH;
+ ev.u.create.rd_data = reportmap;
+ ev.u.create.rd_size = rsize;
+
+ if (write(hogdev->uhid_fd, &ev, sizeof(ev)) < 0)
+ error("Failed to create uHID device: %s", strerror(errno));
+}
+
+static void pnpid_ready(gpointer user_data)
+{
+ struct hog_device *hogdev = user_data;
+
+ if (hogdev->reportmap == NULL)
+ return;
+
+ create_uhid_device(hogdev, hogdev->reportmap, hogdev->reportmap_size);
+
+ g_free(hogdev->reportmap);
+ hogdev->reportmap = NULL;
+ hogdev->reportmap_size = 0;
+}
+
static void report_map_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
gpointer user_data)
{
struct hog_device *hogdev = user_data;
uint8_t value[HOG_REPORT_MAP_MAX_SIZE];
- struct uhid_event ev;
- uint16_t vendor_src, vendor, product, version;
ssize_t vlen;
int i;
@@ -373,27 +416,14 @@ static void report_map_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
}
}
- vendor_src = btd_device_get_vendor_src(hogdev->device);
- vendor = btd_device_get_vendor(hogdev->device);
- product = btd_device_get_product(hogdev->device);
- version = btd_device_get_version(hogdev->device);
- DBG("DIS information: vendor_src=0x%X, vendor=0x%X, product=0x%X, "
- "version=0x%X", vendor_src, vendor, product, version);
-
- /* create uHID device */
- memset(&ev, 0, sizeof(ev));
- ev.type = UHID_CREATE;
- strcpy((char *) ev.u.create.name, "bluez-hog-device");
- ev.u.create.vendor = vendor;
- ev.u.create.product = product;
- ev.u.create.version = version;
- ev.u.create.country = hogdev->bcountrycode;
- ev.u.create.bus = BUS_BLUETOOTH;
- ev.u.create.rd_data = value;
- ev.u.create.rd_size = vlen;
+ if (btd_device_register_pnpid_notifier(hogdev->device,
+ pnpid_ready, hogdev)) {
+ hogdev->reportmap = g_memdup(value, vlen);
+ hogdev->reportmap_size = vlen;
+ return;
+ }
- if (write(hogdev->uhid_fd, &ev, sizeof(ev)) < 0)
- error("Failed to create uHID device: %s", strerror(errno));
+ create_uhid_device(hogdev, value, vlen);
}
static void info_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
@@ -706,6 +736,7 @@ static void hog_device_free(struct hog_device *hogdev)
btd_device_unref(hogdev->device);
g_slist_free_full(hogdev->reports, report_free);
g_free(hogdev->hog_primary);
+ g_free(hogdev->reportmap);
g_free(hogdev);
}
--
1.8.0
^ permalink raw reply related
* [RFC BlueZ 2/3] device: Add a way to be notified that PNP information is present
From: Vinicius Costa Gomes @ 2012-11-23 20:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1353702632-7960-1-git-send-email-vinicius.gomes@openbossa.org>
It will be used inside the HoG profile to only create the uhid device
after the PNP information is present, for the HID subsystem may use the
vendor and product ids to load the correct module.
btd_device_register_pnpid_notifier() will return 'false' when the
information is already present.
---
src/device.c | 41 +++++++++++++++++++++++++++++++++++++++++
src/device.h | 5 +++++
2 files changed, 46 insertions(+)
diff --git a/src/device.c b/src/device.c
index a196af4..ec890fa 100644
--- a/src/device.c
+++ b/src/device.c
@@ -132,6 +132,11 @@ struct attio_data {
gpointer user_data;
};
+struct pnpid_notifier {
+ pnpid_ready_func func;
+ void *user_data;
+};
+
typedef void (*attio_error_cb) (const GError *gerr, gpointer user_data);
typedef void (*attio_success_cb) (gpointer user_data);
@@ -195,6 +200,8 @@ struct btd_device {
GIOChannel *att_io;
guint cleanup_id;
guint store_id;
+
+ GSList *pnpid_notifiers;
};
static uint16_t uuid_list[] = {
@@ -347,6 +354,7 @@ static void device_free(gpointer user_data)
g_slist_free_full(device->primaries, g_free);
g_slist_free_full(device->attios, g_free);
g_slist_free_full(device->attios_offline, g_free);
+ g_slist_free_full(device->pnpid_notifiers, g_free);
attio_cleanup(device);
@@ -4105,10 +4113,43 @@ void btd_device_set_pnpid(struct btd_device *device, uint8_t vendor_id_src,
uint16_t vendor_id, uint16_t product_id,
uint16_t product_ver)
{
+ GSList *l;
+
device_set_vendor(device, vendor_id);
device_set_vendor_src(device, vendor_id_src);
device_set_product(device, product_id);
device_set_version(device, product_ver);
store_device_info(device);
+
+ for (l = device->pnpid_notifiers; l; l = l->next) {
+ struct pnpid_notifier *notifier = l->data;
+
+ notifier->func(notifier->user_data);
+ g_free(notifier);
+ }
+
+ g_slist_free_full(device->pnpid_notifiers, g_free);
+ device->pnpid_notifiers = NULL;
+}
+
+bool btd_device_register_pnpid_notifier(struct btd_device *device,
+ pnpid_ready_func notify, void *user_data)
+{
+ struct pnpid_notifier *notifier;
+
+ if (btd_device_get_vendor(device) ||
+ btd_device_get_vendor_src(device) ||
+ btd_device_get_product(device) ||
+ btd_device_get_version(device))
+ return false;
+
+ notifier = g_new0(struct pnpid_notifier, 1);
+
+ notifier->func = notify;
+ notifier->user_data = user_data;
+
+ device->pnpid_notifiers = g_slist_append(device->pnpid_notifiers,
+ notifier);
+ return true;
}
diff --git a/src/device.h b/src/device.h
index 703dfcf..914ee38 100644
--- a/src/device.h
+++ b/src/device.h
@@ -119,4 +119,9 @@ int device_unblock(struct btd_device *device, gboolean silent,
void btd_device_set_pnpid(struct btd_device *device, uint8_t vendor_id_src,
uint16_t vendor_id, uint16_t product_id,
uint16_t product_ver);
+
+typedef void (*pnpid_ready_func) (void *user_data);
+
+bool btd_device_register_pnpid_notifier(struct btd_device *device,
+ pnpid_ready_func notify, void *user_data);
GIOChannel *device_att_connect(gpointer user_data);
--
1.8.0
^ permalink raw reply related
* [RFC BlueZ 1/3] device: Add btd_ prefix to device_set_pnpid()
From: Vinicius Costa Gomes @ 2012-11-23 20:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1353702632-7960-1-git-send-email-vinicius.gomes@openbossa.org>
As device_set_pnpid() is used inside a plugin it should have the btd_
prefix.
---
profiles/deviceinfo/deviceinfo.c | 2 +-
src/device.c | 4 ++--
src/device.h | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/profiles/deviceinfo/deviceinfo.c b/profiles/deviceinfo/deviceinfo.c
index 9910533..da27df8 100644
--- a/profiles/deviceinfo/deviceinfo.c
+++ b/profiles/deviceinfo/deviceinfo.c
@@ -106,7 +106,7 @@ static void read_pnpid_cb(guint8 status, const guint8 *pdu, guint16 len,
return;
}
- device_set_pnpid(ch->d->dev, value[0], att_get_u16(&value[1]),
+ btd_device_set_pnpid(ch->d->dev, value[0], att_get_u16(&value[1]),
att_get_u16(&value[3]), att_get_u16(&value[5]));
}
diff --git a/src/device.c b/src/device.c
index f0223c8..a196af4 100644
--- a/src/device.c
+++ b/src/device.c
@@ -2349,7 +2349,7 @@ static void update_bredr_services(struct browse_req *req, sdp_list_t *recs)
version = pdlist ? pdlist->val.uint16 : 0x0000;
if (source || vendor || product || version)
- device_set_pnpid(device, source, vendor,
+ btd_device_set_pnpid(device, source, vendor,
product, version);
}
@@ -4101,7 +4101,7 @@ gboolean btd_device_remove_attio_callback(struct btd_device *device, guint id)
return TRUE;
}
-void device_set_pnpid(struct btd_device *device, uint8_t vendor_id_src,
+void btd_device_set_pnpid(struct btd_device *device, uint8_t vendor_id_src,
uint16_t vendor_id, uint16_t product_id,
uint16_t product_ver)
{
diff --git a/src/device.h b/src/device.h
index 3715698..703dfcf 100644
--- a/src/device.h
+++ b/src/device.h
@@ -116,7 +116,7 @@ void btd_device_unref(struct btd_device *device);
int device_block(struct btd_device *device, gboolean update_only);
int device_unblock(struct btd_device *device, gboolean silent,
gboolean update_only);
-void device_set_pnpid(struct btd_device *device, uint8_t vendor_id_src,
+void btd_device_set_pnpid(struct btd_device *device, uint8_t vendor_id_src,
uint16_t vendor_id, uint16_t product_id,
uint16_t product_ver);
GIOChannel *device_att_connect(gpointer user_data);
--
1.8.0
^ permalink raw reply related
* [RFC BlueZ 0/3] Only create the uhid device when PNP info is available
From: Vinicius Costa Gomes @ 2012-11-23 20:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
Hi,
Some input drivers require that the input device is created with the
correct product and vendor ids.
So we have a race condition between the DIS (Device Information)
profile and the HoG profile, this series aims to solve this particular
problem by adding a mechanism to notify the interested parties that
PNP information is ready, the HoG plugin uses this to only create the
uhid device when that information arrives.
Patch 1/3 should be considered for inclusion even if this idea doesn't
make sense.
Cheers,
Vinicius Costa Gomes (3):
device: Add btd_ prefix to device_set_pnpid()
device: Add a way to be notified that PNP information is present
hog: Fix registering HoG devices without vendor information
profiles/deviceinfo/deviceinfo.c | 2 +-
profiles/input/hog_device.c | 75 ++++++++++++++++++++++++++++------------
src/device.c | 45 ++++++++++++++++++++++--
src/device.h | 7 +++-
4 files changed, 103 insertions(+), 26 deletions(-)
--
1.8.0
^ permalink raw reply
* [PATCH BlueZ 2/2] hog: Fix output report
From: Vinicius Costa Gomes @ 2012-11-23 19:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1353697709-6497-1-git-send-email-vinicius.gomes@openbossa.org>
Even if we receive the output report with the report id included, we
must send the output report without the report id, as the remote side
is able to infer it using the handle.
---
profiles/input/hog_device.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/profiles/input/hog_device.c b/profiles/input/hog_device.c
index 994437f..0a5fb58 100644
--- a/profiles/input/hog_device.c
+++ b/profiles/input/hog_device.c
@@ -549,8 +549,13 @@ static void forward_report(struct hog_device *hogdev,
int size;
guint type;
- data = ev->u.output.data;
- size = ev->u.output.size;
+ if (hogdev->prepend_id) {
+ data = ev->u.output.data + 1;
+ size = ev->u.output.size - 1;
+ } else {
+ data = ev->u.output.data;
+ size = ev->u.output.size;
+ }
switch (ev->type) {
case UHID_OUTPUT:
--
1.8.0
^ permalink raw reply related
* [PATCH BlueZ 1/2] hog: Fix potencial segfault when sending a output report
From: Vinicius Costa Gomes @ 2012-11-23 19:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
As UHID is not notified when the device is disconnected, it may be
possible that an output report is forwarded when the device is not
connected, one example, would be when the caps lock key is pressed on
another keyboard.
---
profiles/input/hog_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/profiles/input/hog_device.c b/profiles/input/hog_device.c
index d231e00..994437f 100644
--- a/profiles/input/hog_device.c
+++ b/profiles/input/hog_device.c
@@ -573,6 +573,9 @@ static void forward_report(struct hog_device *hogdev,
DBG("Sending report type %d to device 0x%04X handle 0x%X", type,
hogdev->id, report->decl->value_handle);
+ if (hogdev->attrib == NULL)
+ return;
+
if (report->decl->properties & ATT_CHAR_PROPER_WRITE)
gatt_write_char(hogdev->attrib, report->decl->value_handle,
data, size, output_written_cb, hogdev);
--
1.8.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] Bluetooth: Implement deferred sco socket setup
From: Gustavo Padovan @ 2012-11-23 18:55 UTC (permalink / raw)
To: Frédéric Dalleau; +Cc: linux-bluetooth
In-Reply-To: <1353491473-3789-3-git-send-email-frederic.dalleau@linux.intel.com>
Hi Frédéric,
* Frédéric Dalleau <frederic.dalleau@linux.intel.com> [2012-11-21 10:51:12 +0100]:
> In order to authenticate and configure an incoming SCO connection, the
> BT_DEFER_SETUP option was added. This option is intended to defer reply
> to Connect Request on SCO sockets.
> When a connection is requested, the listening socket is unblocked but
> the effective connection setup happens only on first recv. Any send
> between accept and recv fails with -ENOTCONN.
>
> Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
> ---
> include/net/bluetooth/hci_core.h | 9 ++++---
> net/bluetooth/hci_event.c | 52 +++++++++++++++++++++++++++++++++++---
> net/bluetooth/sco.c | 35 ++++++++++++++++++++++---
> 3 files changed, 86 insertions(+), 10 deletions(-)
The 2 patches have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: Query regarding device discovery
From: Luiz Augusto von Dentz @ 2012-11-23 14:06 UTC (permalink / raw)
To: Jaganath Kanakkassery; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1D52C441D64244F0ABA8B962523624AC@sisodomain.com>
Hi,
On Fri, Nov 23, 2012 at 3:24 PM, Jaganath Kanakkassery
<jaganath.k@samsung.com> wrote:
> Hi Luiz,
>
> --------------------------------------------------
> From: "Luiz Augusto von Dentz" <luiz.dentz@gmail.com>
> Sent: Friday, November 23, 2012 3:24 PM
> To: "Jaganath" <jaganath.k@samsung.com>
> Cc: <linux-bluetooth@vger.kernel.org>
> Subject: Re: Query regarding device discovery
>
>
>> Hi,
>>
>> On Fri, Nov 23, 2012 at 11:27 AM, JAGANATH KANAKKASSERY
>> <jaganath.k@samsung.com> wrote:
>>>
>>> Hello,
>>>
>>> I have a doubt with current discovery mechanism.
>>>
>>> Suppose application 1 calls "StartDiscovery". for which "Discovering =
>>> TRUE" comes
>>> and then deviceFound signals starts coming.
>>> In the mean time application 2 calls "StartDiscovery" which will be
>>> queued in BlueZ.
>>> Then "discovering = FALSE" comes for the discovery initiated from
>>> application 1.
>>> Then as per BlueZ design, it will restart discovery for application 1
>>> since it has not
>>> called "StopDiscovery" yet. So "discovering = TRUE" comes again, which
>>> application 2
>>> thinks that it belongs to him.
>>> Then if application 1 calls "StopDiscovery" immediately, discovery will
>>> be stopped
>>> and "Discovering = FALSE" comes with which application 2 too thinks that
>>> discovery
>>> initiated by him is also done.
>>> So eventually application 2 will not get any devices.
>>> So I think with current design, applications that are interested only in
>>> one complete
>>> inquiry session will be in trouble.
>>>
>>> So can we disable the automatic reinitiating of device discovery?
>>> Or is there any way to handle this scenario?
>>
>>
>>
>> StartDiscovery doesn't queue the sessions, it actually increase the
>> reference to the same discovery session which became shared between
>> the callers, it should not interfere with the ongoing discovery nor
>> change how we emit Discovering. That being said the concept of one
>> shot inquiry is flawed since it can miss devices, with addition of LE
>> this is even more visible because each inquiry is only 5.12 sec., you
>> can still detect when an inquiry is active just check when Discovering
>> is TRUE and nope it should not matter if there is 1 or 20 application
>> listening to it once Discovery switch to TRUE we are inquiring/scan
>> when it switch to FALSE it has stopped and is probably doing name
>> resolving.
>
>
> With this concept even if inquiry is completed, Discovery = FALSE should not
> be sent. Because anyway BlueZ will start a new Discovery on its own.
> So application gets Discovery = FALSE and then immediately Discovery = TRUE.
> So I think until application calls "StopDiscovery", Discovery = FALSE should
> not be sent
StartDiscovery processing with 3 instances is like this:
StartDiscovery #1
org.bluez.Adapter.Discovering=TRUE
Inquiry
name resolving
org.bluez.Adapter.Discovering=FALSE
org.bluez.Adapter.Discovering=TRUE
Inquiry
name resolving
org.bluez.Adapter.Discovering=FALSE
StartDiscovery #2
org.bluez.Adapter.Discovering=TRUE
Inquiry
StartDiscovery #3
name resolving
org.bluez.Adapter.Discovering=FALSE
...
org.bluez.Adapter.Discovering=TRUE
StopDiscovery #3
Inquiry
StopDiscovery #2
StopDiscovery #1
org.bluez.Adapter.Discovering=FALSE
So org.bluez.Adapter.Discovering=TRUE will track each individual round
of the inquiry+name resolving, org.bluez.Adapter.Discovering=FALSE is
there just to let you know when another round is about to start in
case anyones cares about each individual round or want to do a single
round of discovery.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH v2 3/3] Doco: List the read codecs operation
From: Michael Knudsen @ 2012-11-23 13:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michael Knudsen
In-Reply-To: <1353679170-3738-1-git-send-email-m.knudsen@samsung.com>
---
doc/mgmt-api.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 202c055..42af2d6 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -847,6 +847,26 @@ Set Device ID Command
a Command Status event on failure.
+Read Codecs Command
+====================
+
+ Command Code: 0x0029
+ Controller Index: <controller id>
+ Command Parameters:
+ Return Parameters:
+ Num_Of_Codecs (1 Octet)
+ Codec1 (1 Octet)
+ Codec2 (1 Octet)
+ ...
+
+ This command is used to read out the list of codecs that are
+ supported by the given controller.
+
+ This command generates a Command Complete event on success
+ or failure.
+
+
+
Command Complete Event
======================
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/3] Bluetooth: Support the read codecs operation
From: Michael Knudsen @ 2012-11-23 13:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michael Knudsen
In-Reply-To: <1353679170-3738-1-git-send-email-m.knudsen@samsung.com>
---
lib/mgmt.h | 8 ++++++
tools/btmgmt.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+)
diff --git a/lib/mgmt.h b/lib/mgmt.h
index 6c7e44a..f1950b2 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -318,6 +318,13 @@ struct mgmt_cp_set_device_id {
uint16_t version;
} __packed;
+#define MGMT_OP_READ_CODECS 0x0029
+struct mgmt_rp_read_codecs {
+ uint8_t count;
+ uint8_t codec[0];
+} __packed;
+
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
uint16_t opcode;
@@ -496,6 +503,7 @@ static const char *mgmt_op[] = {
"Block Device",
"Unblock Device",
"Set Device ID",
+ "Read Codecs",
};
static const char *mgmt_ev[] = {
diff --git a/tools/btmgmt.c b/tools/btmgmt.c
index ff6a46a..857c3a8 100644
--- a/tools/btmgmt.c
+++ b/tools/btmgmt.c
@@ -993,6 +993,79 @@ static void cmd_info(int mgmt_sk, uint16_t index, int argc, char **argv)
}
}
+struct codecs_map {
+ int codec;
+ char *name;
+} codecs_map[] = {
+ { HCI_FORMAT_ULAW, "uLAW" },
+ { HCI_FORMAT_ALAW, "aLAW" },
+ { HCI_FORMAT_CVSD, "CVSD" },
+ { HCI_FORMAT_TRANSPARENT, "transparent" },
+ { HCI_FORMAT_PCM, "PCM" },
+ { HCI_FORMAT_MSBC, "mSBC" },
+ { HCI_FORMAT_VENDOR, "vendor" },
+ { -1 },
+};
+
+static void codecs_rsp(int mgmt_sk, uint16_t op, uint16_t id, uint8_t status,
+ void *rsp, uint16_t len, void *user_data)
+{
+ struct mgmt_rp_read_codecs *rp = rsp;
+ char addr[18];
+ int i, count;
+
+ if (status != 0) {
+ fprintf(stderr,
+ "Reading hci%u info failed with status 0x%02x (%s)\n",
+ id, status, mgmt_errstr(status));
+ exit(EXIT_FAILURE);
+ }
+
+ if (len < sizeof(*rp)) {
+ fprintf(stderr, "Too small codecs reply (%u bytes)\n", len);
+ exit(EXIT_FAILURE);
+ }
+
+ count = rp->count;
+
+ printf("hci%u:\tnumber of codecs: %u\n", id, count);
+
+ for (i = 0; i < count; i++) {
+ int entry;
+ struct codecs_map *p;
+
+ entry = rp->codec[i];
+
+ p = codecs_map;
+
+ while (p->codec != -1) {
+ if (entry == p->codec)
+ break;
+ else
+ p++;
+ }
+
+ if (p->codec != -1)
+ printf("\t%s (0x%x)\n", p->name, p->codec);
+ else
+ printf("\tunknown (0x%x)\n", p->codec);
+ }
+
+ exit(EXIT_SUCCESS);
+}
+
+static void cmd_codecs(int mgmt_sk, uint16_t index, int argc, char **argv)
+{
+ if (index == MGMT_INDEX_NONE)
+ index = 0;
+
+ if (mgmt_send_cmd(mgmt_sk, MGMT_OP_READ_CODECS, index, NULL,
+ 0, codecs_rsp, NULL) < 0) {
+ fprintf(stderr, "Unable to send read_info cmd\n");
+ exit(EXIT_FAILURE);
+ }
+}
+
static void setting_rsp(int mgmt_sk, uint16_t op, uint16_t id, uint8_t status,
void *rsp, uint16_t len, void *user_data)
{
@@ -1824,6 +1897,7 @@ static struct {
{ "version", cmd_version, "Get the MGMT Version" },
{ "commands", cmd_commands, "List supported commands" },
{ "info", cmd_info, "Show controller info" },
+ { "codecs", cmd_codecs, "List supported codecs" },
{ "power", cmd_power, "Toggle powered state" },
{ "discov", cmd_discov, "Toggle discoverable state" },
{ "connectable",cmd_connectable,"Toggle connectable state" },
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/3] Bluetooth: Add HCI Coding Format definitions
From: Michael Knudsen @ 2012-11-23 13:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michael Knudsen
In-Reply-To: <1353679170-3738-1-git-send-email-m.knudsen@samsung.com>
---
lib/hci.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/lib/hci.h b/lib/hci.h
index 2f18ec8..5e5f6b5 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -295,6 +295,15 @@ enum {
#define HCI_LM_RELIABLE 0x0010
#define HCI_LM_SECURE 0x0020
+/* Coding Format */
+#define HCI_FORMAT_ULAW 0x00
+#define HCI_FORMAT_ALAW 0x01
+#define HCI_FORMAT_CVSD 0x02
+#define HCI_FORMAT_TRANSPARENT 0x03
+#define HCI_FORMAT_PCM 0x04
+#define HCI_FORMAT_MSBC 0x05
+#define HCI_FORMAT_VENDOR 0xff
+
/* Link Key types */
#define HCI_LK_COMBINATION 0x00
#define HCI_LK_LOCAL_UNIT 0x01
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 0/3] mgmt: read supported codecs
From: Michael Knudsen @ 2012-11-23 13:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Michael Knudsen
This implements the user space side of the read codecs command.
Whitespace issue pointed out by Kim Schulz should be fixed.
Michael Knudsen (3):
Bluetooth: Add HCI Coding Format definitions
Bluetooth: Support the read codecs operation
Doco: List the read codecs operation
doc/mgmt-api.txt | 20 +++++++++++++++
lib/hci.h | 9 +++++++
lib/mgmt.h | 8 ++++++
tools/btmgmt.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 111 insertions(+)
--
1.7.9.5
^ permalink raw reply
* Re: Query regarding device discovery
From: Jaganath Kanakkassery @ 2012-11-23 13:24 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZ+-2YWROExMEoMxSfYTyXT1oeOpHjJECNs-xA7vtaAx_g@mail.gmail.com>
Hi Luiz,
--------------------------------------------------
From: "Luiz Augusto von Dentz" <luiz.dentz@gmail.com>
Sent: Friday, November 23, 2012 3:24 PM
To: "Jaganath" <jaganath.k@samsung.com>
Cc: <linux-bluetooth@vger.kernel.org>
Subject: Re: Query regarding device discovery
> Hi,
>
> On Fri, Nov 23, 2012 at 11:27 AM, JAGANATH KANAKKASSERY
> <jaganath.k@samsung.com> wrote:
>> Hello,
>>
>> I have a doubt with current discovery mechanism.
>>
>> Suppose application 1 calls "StartDiscovery". for which "Discovering =
>> TRUE" comes
>> and then deviceFound signals starts coming.
>> In the mean time application 2 calls "StartDiscovery" which will be
>> queued in BlueZ.
>> Then "discovering = FALSE" comes for the discovery initiated from
>> application 1.
>> Then as per BlueZ design, it will restart discovery for application 1
>> since it has not
>> called "StopDiscovery" yet. So "discovering = TRUE" comes again, which
>> application 2
>> thinks that it belongs to him.
>> Then if application 1 calls "StopDiscovery" immediately, discovery will
>> be stopped
>> and "Discovering = FALSE" comes with which application 2 too thinks that
>> discovery
>> initiated by him is also done.
>> So eventually application 2 will not get any devices.
>> So I think with current design, applications that are interested only in
>> one complete
>> inquiry session will be in trouble.
>>
>> So can we disable the automatic reinitiating of device discovery?
>> Or is there any way to handle this scenario?
>
>
> StartDiscovery doesn't queue the sessions, it actually increase the
> reference to the same discovery session which became shared between
> the callers, it should not interfere with the ongoing discovery nor
> change how we emit Discovering. That being said the concept of one
> shot inquiry is flawed since it can miss devices, with addition of LE
> this is even more visible because each inquiry is only 5.12 sec., you
> can still detect when an inquiry is active just check when Discovering
> is TRUE and nope it should not matter if there is 1 or 20 application
> listening to it once Discovery switch to TRUE we are inquiring/scan
> when it switch to FALSE it has stopped and is probably doing name
> resolving.
With this concept even if inquiry is completed, Discovery = FALSE should not
be sent. Because anyway BlueZ will start a new Discovery on its own.
So application gets Discovery = FALSE and then immediately Discovery = TRUE.
So I think until application calls "StopDiscovery", Discovery = FALSE should
not be sent
Thanks,
Jaganath
^ permalink raw reply
* Re: [PATCH 0/3] mgmt: read supported codecs
From: Kim Schulz @ 2012-11-23 10:10 UTC (permalink / raw)
To: Michael Knudsen; +Cc: linux-bluetooth, Michael Knudsen
In-Reply-To: <1353588468-28711-1-git-send-email-m.knudsen@samsung.com>
Den 2012-11-22 13:47, Michael Knudsen skrev:
> This implements the user space side of the read codecs command.
>
> Michael Knudsen (3):
> Bluetooth: Add HCI Coding Format definitions
> Bluetooth: Support the read codecs operation
> Doco: List the read codecs operation
>
> doc/mgmt-api.txt | 20 +++++++++++++++
> lib/hci.h | 9 +++++++
> lib/mgmt.h | 8 ++++++
> tools/btmgmt.c | 74
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 111 insertions(+)
Looks like the codein these patches have some indentation problems
(mixes tab and spaces).
--
Kim Schulz
^ permalink raw reply
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