* [PATCH BlueZ] build: Remove left over of gstreamer removal
From: Luiz Augusto von Dentz @ 2012-12-10 12:02 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
profiles/audio/rtp.h | 76 ----------------------------------------------------
1 file changed, 76 deletions(-)
delete mode 100644 profiles/audio/rtp.h
diff --git a/profiles/audio/rtp.h b/profiles/audio/rtp.h
deleted file mode 100644
index 45fddcf..0000000
--- a/profiles/audio/rtp.h
+++ /dev/null
@@ -1,76 +0,0 @@
-/*
- *
- * BlueZ - Bluetooth protocol stack for Linux
- *
- * Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
- *
- *
- * This library is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation; either
- * version 2.1 of the License, or (at your option) any later version.
- *
- * This library is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this library; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- *
- */
-
-#if __BYTE_ORDER == __LITTLE_ENDIAN
-
-struct rtp_header {
- unsigned cc:4;
- unsigned x:1;
- unsigned p:1;
- unsigned v:2;
-
- unsigned pt:7;
- unsigned m:1;
-
- uint16_t sequence_number;
- uint32_t timestamp;
- uint32_t ssrc;
- uint32_t csrc[0];
-} __attribute__ ((packed));
-
-struct rtp_payload {
- unsigned frame_count:4;
- unsigned rfa0:1;
- unsigned is_last_fragment:1;
- unsigned is_first_fragment:1;
- unsigned is_fragmented:1;
-} __attribute__ ((packed));
-
-#elif __BYTE_ORDER == __BIG_ENDIAN
-
-struct rtp_header {
- unsigned v:2;
- unsigned p:1;
- unsigned x:1;
- unsigned cc:4;
-
- unsigned m:1;
- unsigned pt:7;
-
- uint16_t sequence_number;
- uint32_t timestamp;
- uint32_t ssrc;
- uint32_t csrc[0];
-} __attribute__ ((packed));
-
-struct rtp_payload {
- unsigned is_fragmented:1;
- unsigned is_first_fragment:1;
- unsigned is_last_fragment:1;
- unsigned rfa0:1;
- unsigned frame_count:4;
-} __attribute__ ((packed));
-
-#else
-#error "Unknown byte order"
-#endif
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH BlueZ] build: Remove left over of gstreamer removal
From: Johan Hedberg @ 2012-12-10 12:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1355140947-13636-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Dec 10, 2012, Luiz Augusto von Dentz wrote:
> ---
> profiles/audio/rtp.h | 76 ----------------------------------------------------
> 1 file changed, 76 deletions(-)
> delete mode 100644 profiles/audio/rtp.h
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 0/9] Remove redundant struct audio_device members
From: Luiz Augusto von Dentz @ 2012-12-10 12:50 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1354702224-15895-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Dec 5, 2012 at 12:10 PM, Szymon Janc <szymon.janc@tieto.com> wrote:
> Both src and dst addresses can be obtained from struct btd_device
> reference and used when needed.
>
> Szymon Janc (9):
> avdtp: Convert avdtp_get to accept audio_device
> avdtp: Convert avdtp_is_connected to accept audio_device
> avctp: Convert avctp_connect to accept audio_device
> avctp: Convert avctp_get to accept audio_device
> avctp: Don't use audio_device src and dst in avctp_control_confirm
> avdtp: Don't use audio_device src and dst fields in avdtp_confirm_cb
> audio: Don't use audio_device src and dst in manager_find_devices
> avrcp: Don't use audio_device src field
> audio: Remove src and dst from struct audio_device
>
> profiles/audio/avctp.c | 23 ++++++++++++++++++++---
> profiles/audio/avctp.h | 4 ++--
> profiles/audio/avdtp.c | 16 +++++++++++++---
> profiles/audio/avdtp.h | 4 ++--
> profiles/audio/avrcp.c | 16 +++++++++++-----
> profiles/audio/control.c | 4 ++--
> profiles/audio/device.c | 13 ++++---------
> profiles/audio/device.h | 7 +------
> profiles/audio/manager.c | 11 ++++++++---
> profiles/audio/sink.c | 2 +-
> profiles/audio/source.c | 2 +-
> profiles/audio/transport.c | 3 +--
> 12 files changed, 66 insertions(+), 39 deletions(-)
>
> --
> 1.7.9.5
Pushed upstream, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [RFC] HCI commands flow fix
From: Szymon Janc @ 2012-12-10 14:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
Hi,
I'm seeing issues with some of BT dongles. With mgmt interface this results
in not being able to further communicate with chip due to state mismatch in
kernel e.g. kernel is replying busy for every command that could update CoD.
This can be quite easy reproduced by quickly restarting bluetoothd.
This patch fix 1 issue noticed: sending new commands before CC for reset
is received.
This makes things better on my PC but...
There is still a window for getting stuck: when closing device kernel is not
waiting for last command to complete and (depending on command) this sometimes
(but less frequent comparing to command-reply mismatch without this patch)
result in getting into wrong state and chip stops responding (or maybe commands
don't get to chip..?):
< HCI Command: Write Extended Inquiry Response (0x03|0x0052) plen 241 [hci0] 2078.141360
FEC: Not required (0x00)
Name (complete): uw000953
16-bit Service UUIDs (complete): 0x1801 0x1800
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 2078.143329
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)
< HCI Command: Write Extended Inquiry Response (0x03|0x0052) plen 241 [hci0] 2078.188088
FEC: Not required (0x00)
Name (complete): uw000953
16-bit Service UUIDs (complete): 0x1800
@ New Settings: 0x00d2
connectable pairable ssp br/edr
@ Local Name Changed: uw000953 ()
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 2078.445154
@ Local Name Changed: uw000953 ()
@ Local Name Changed: uw000953 ()
bluetoothd[28619]: Bluetooth Management interface initialized
bluetoothd[28619]: hci0: Set Powered (0x0005) failed: Busy (0x0a)
hciconfig hci0 up
Can't init device hci0: Connection timed out (110)
So, maybe (along with this patch) kernel should not discard last sent command on close but
wait for CC (or tx TO)?
Any comments on how this could be solved are welcome.
Szymon Janc (1):
Bluetooth: Don't send new commands before CC for reset is received
net/bluetooth/hci_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
1.7.9.5
^ permalink raw reply
* [RFC] Bluetooth: Don't send new commands before CC for reset is received
From: Szymon Janc @ 2012-12-10 14:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1355148525-29379-1-git-send-email-szymon.janc@tieto.com>
After sending reset command wait for its command complete event before
sending next command. Some chips sends CC event for command received
before reset if reset was send before chip replied with CC.
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
---
net/bluetooth/hci_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 705078a..81b4448 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2688,7 +2688,7 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
if (ev->opcode != HCI_OP_NOP)
del_timer(&hdev->cmd_timer);
- if (ev->ncmd) {
+ if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) {
atomic_set(&hdev->cmd_cnt, 1);
if (!skb_queue_empty(&hdev->cmd_q))
queue_work(hdev->workqueue, &hdev->cmd_work);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 1/4] sap-u8500: Fix build errors due to unaligned memory access
From: Szymon Janc @ 2012-12-10 14:12 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <1353665354-32178-1-git-send-email-szymon.janc@tieto.com>
On Friday 23 of November 2012 12:09:11 Janc Szymon wrote:
> This fix following compilation error on ARM.
>
> CC profiles/sap/sap-u8500.o
> profiles/sap/sap-u8500.c: In function recv_card_status:
> profiles/sap/sap-u8500.c:323:16: error: cast increases required
> alignment of target type [-Werror=cast-align]
> profiles/sap/sap-u8500.c: In function recv_response:
> profiles/sap/sap-u8500.c:423:12: error: cast increases required
> alignment of target type [-Werror=cast-align]
> cc1: all warnings being treated as errors
> ---
> profiles/sap/sap-u8500.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/profiles/sap/sap-u8500.c b/profiles/sap/sap-u8500.c
> index f07209d..b1aee57 100644
> --- a/profiles/sap/sap-u8500.c
> +++ b/profiles/sap/sap-u8500.c
> @@ -313,16 +313,16 @@ static void recv_status(uint32_t status)
>
> static void recv_card_status(uint32_t status, uint8_t *param)
> {
> - uint32_t *card_status;
> + uint32_t card_status;
> uint8_t result;
> uint8_t iccrs;
>
> if (status != STE_STATUS_OK)
> return;
>
> - card_status = (uint32_t *)param;
> + memcpy(&card_status, param, sizeof(card_status));
>
> - if (get_sap_reader_status(*card_status, &iccrs) < 0)
> + if (get_sap_reader_status(card_status, &iccrs) < 0)
> result = SAP_RESULT_ERROR_NO_REASON;
> else
> result = get_sap_result(STE_GET_STATUS_MSG, status);
> @@ -420,7 +420,7 @@ static void recv_response(struct ste_message *msg)
> }
>
> param = msg->payload;
> - status = *(uint32_t *)param;
> + memcpy(&status, param, sizeof(status));
> param += sizeof(status);
>
> SAP_VDBG("status 0x%x", status);
>
ping
^ permalink raw reply
* Re: BLE issue: Start_LE_Encryption fails
From: Anderson Lizardo @ 2012-12-10 15:18 UTC (permalink / raw)
To: Ajay; +Cc: linux-bluetooth
In-Reply-To: <50C3F088.2090203@globaledgesoft.com>
Hi,
On Sat, Dec 8, 2012 at 9:59 PM, Ajay <ajay.kv@globaledgesoft.com> wrote:
> I tried "gatttool -i hci0 -b <remote bdaddr> --primary " on master
> side ,which creates LE link and very next moment disconnects . How can i
> change the security level of the link to medium?. still struggling to pair
> the device (atleast "smp just works") ) . Is my kernel supportive (3.2.5)
You can try using the --sec-level medium option.
> Every time on LE create connection process i
> ,smp_conn_security() getting called from hci layer .
> But if(host_le_capable(hcon->hdev))
> return 1;
> condition returns without even checking the security level . so kindly show
> me the right way..
I suspect this check has been added recently to the kernel. Try
running bluetoothd oh the master side as well, it should then enable
host LE support through mgmt API and this check should pass.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH BlueZ] audio: remove unused field from audio_device
From: João Paulo Rechi Vita @ 2012-12-10 18:52 UTC (permalink / raw)
To: linux-bluetooth; +Cc: João Paulo Rechi Vita
---
profiles/audio/device.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/profiles/audio/device.h b/profiles/audio/device.h
index a45ef21..2c98355 100644
--- a/profiles/audio/device.h
+++ b/profiles/audio/device.h
@@ -39,7 +39,6 @@ struct audio_device {
struct sink *sink;
struct source *source;
struct control *control;
- struct target *target;
struct dev_priv *priv;
};
--
1.7.11.7
^ permalink raw reply related
* [PATCH BlueZ] build: Fix 'hcitool' and 'bdaddr' compilation
From: Vinicius Costa Gomes @ 2012-12-10 19:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
Now with the addition of src/oui.c that depends on udev, these tools
should also be linked against libudev, in case libudev includes the
function udev_hwdb_new().
---
Makefile.tools | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.tools b/Makefile.tools
index 36b43dc..d6532b8 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -32,7 +32,7 @@ tools_hciconfig_SOURCES = tools/hciconfig.c tools/csr.h tools/csr.c
tools_hciconfig_LDADD = lib/libbluetooth-private.la
tools_hcitool_SOURCES = tools/hcitool.c src/oui.h src/oui.c
-tools_hcitool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@
+tools_hcitool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@ @UDEV_LIBS@
tools_sdptool_SOURCES = tools/sdptool.c src/sdp-xml.h src/sdp-xml.c
tools_sdptool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@
@@ -107,7 +107,7 @@ tools_bccmd_LDADD += @USB_LIBS@
endif
tools_bdaddr_SOURCES = tools/bdaddr.c src/oui.h src/oui.c
-tools_bdaddr_LDADD = lib/libbluetooth-private.la
+tools_bdaddr_LDADD = lib/libbluetooth-private.la @UDEV_LIBS@
dist_man_MANS += tools/rfcomm.1 tools/l2ping.1 tools/rctest.1 \
tools/hciattach.1 tools/hciconfig.1 \
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH BlueZ] audio: remove unused field from audio_device
From: Johan Hedberg @ 2012-12-10 19:59 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth
In-Reply-To: <1355165546-20587-1-git-send-email-jprvita@openbossa.org>
Hi João Paulo,
On Mon, Dec 10, 2012, João Paulo Rechi Vita wrote:
> ---
> profiles/audio/device.h | 1 -
> 1 file changed, 1 deletion(-)
Applied. Thanks.
Johan
^ permalink raw reply
* [PATCH BlueZ v2] build: Fix 'hcitool' and 'bdaddr' compilation
From: Vinicius Costa Gomes @ 2012-12-10 20:24 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
Now with the addition of src/oui.c that depends on udev, these tools
should also be linked against libudev, in case libudev includes the
function udev_hwdb_new().
Build error:
CCLD tools/hcitool
CCLD tools/sdptool
CCLD tools/ciptool
CCLD tools/bccmd
src/oui.o: In function `batocomp':
/home/vinicius/work/bluez/src/oui.c:42: undefined reference to `udev_new'
/home/vinicius/work/bluez/src/oui.c:46: undefined reference to `udev_hwdb_new'
/home/vinicius/work/bluez/src/oui.c:50: undefined reference to `udev_hwdb_get_properties_list_entry'
/home/vinicius/work/bluez/src/oui.c:53: undefined reference to `udev_list_entry_get_name'
/home/vinicius/work/bluez/src/oui.c:52: undefined reference to `udev_list_entry_get_next'
/home/vinicius/work/bluez/src/oui.c:61: undefined reference to `udev_hwdb_unref'
/home/vinicius/work/bluez/src/oui.c:64: undefined reference to `udev_unref'
/home/vinicius/work/bluez/src/oui.c:56: undefined reference to `udev_list_entry_get_value'
collect2: error: ld returned 1 exit status
make[1]: *** [tools/hcitool] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
---
Makefile.tools | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile.tools b/Makefile.tools
index 36b43dc..d6532b8 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -32,7 +32,7 @@ tools_hciconfig_SOURCES = tools/hciconfig.c tools/csr.h tools/csr.c
tools_hciconfig_LDADD = lib/libbluetooth-private.la
tools_hcitool_SOURCES = tools/hcitool.c src/oui.h src/oui.c
-tools_hcitool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@
+tools_hcitool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@ @UDEV_LIBS@
tools_sdptool_SOURCES = tools/sdptool.c src/sdp-xml.h src/sdp-xml.c
tools_sdptool_LDADD = lib/libbluetooth-private.la @GLIB_LIBS@
@@ -107,7 +107,7 @@ tools_bccmd_LDADD += @USB_LIBS@
endif
tools_bdaddr_SOURCES = tools/bdaddr.c src/oui.h src/oui.c
-tools_bdaddr_LDADD = lib/libbluetooth-private.la
+tools_bdaddr_LDADD = lib/libbluetooth-private.la @UDEV_LIBS@
dist_man_MANS += tools/rfcomm.1 tools/l2ping.1 tools/rctest.1 \
tools/hciattach.1 tools/hciconfig.1 \
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH BlueZ v2] build: Fix 'hcitool' and 'bdaddr' compilation
From: Johan Hedberg @ 2012-12-10 20:39 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1355171052-9218-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Mon, Dec 10, 2012, Vinicius Costa Gomes wrote:
> Now with the addition of src/oui.c that depends on udev, these tools
> should also be linked against libudev, in case libudev includes the
> function udev_hwdb_new().
>
> Build error:
> CCLD tools/hcitool
> CCLD tools/sdptool
> CCLD tools/ciptool
> CCLD tools/bccmd
> src/oui.o: In function `batocomp':
> /home/vinicius/work/bluez/src/oui.c:42: undefined reference to `udev_new'
> /home/vinicius/work/bluez/src/oui.c:46: undefined reference to `udev_hwdb_new'
> /home/vinicius/work/bluez/src/oui.c:50: undefined reference to `udev_hwdb_get_properties_list_entry'
> /home/vinicius/work/bluez/src/oui.c:53: undefined reference to `udev_list_entry_get_name'
> /home/vinicius/work/bluez/src/oui.c:52: undefined reference to `udev_list_entry_get_next'
> /home/vinicius/work/bluez/src/oui.c:61: undefined reference to `udev_hwdb_unref'
> /home/vinicius/work/bluez/src/oui.c:64: undefined reference to `udev_unref'
> /home/vinicius/work/bluez/src/oui.c:56: undefined reference to `udev_list_entry_get_value'
> collect2: error: ld returned 1 exit status
> make[1]: *** [tools/hcitool] Error 1
> make[1]: *** Waiting for unfinished jobs....
> make: *** [all] Error 2
> ---
> Makefile.tools | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* [PATCH BlueZ] hog: Rename prepend_id variable
From: Andre Guedes @ 2012-12-10 20:54 UTC (permalink / raw)
To: linux-bluetooth
This patch renames the hog_device prepend_id field by has_report_id
as long as it is more suitable.
This variable indicates if we should consider the report id (adding
or removing it) before sending it to device or uhid driver.
---
profiles/input/hog_device.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/profiles/input/hog_device.c b/profiles/input/hog_device.c
index a873eac..06dab6d 100644
--- a/profiles/input/hog_device.c
+++ b/profiles/input/hog_device.c
@@ -79,7 +79,7 @@ struct hog_device {
struct gatt_primary *hog_primary;
GSList *reports;
int uhid_fd;
- gboolean prepend_id;
+ gboolean has_report_id;
guint uhid_watch_id;
uint16_t bcdhid;
uint8_t bcountrycode;
@@ -120,7 +120,7 @@ static void report_value_cb(const uint8_t *pdu, uint16_t len,
ev.u.input.size = MIN(report_size, UHID_DATA_MAX);
buf = ev.u.input.data;
- if (hogdev->prepend_id) {
+ if (hogdev->has_report_id) {
*buf = report->id;
buf++;
ev.u.input.size++;
@@ -362,7 +362,7 @@ static void report_map_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
case 0x85:
case 0x86:
case 0x87:
- hogdev->prepend_id = TRUE;
+ hogdev->has_report_id = TRUE;
}
if (i % 2 == 0) {
@@ -549,7 +549,7 @@ static void forward_report(struct hog_device *hogdev,
int size;
guint type;
- if (hogdev->prepend_id) {
+ if (hogdev->has_report_id) {
data = ev->u.output.data + 1;
size = ev->u.output.size - 1;
} else {
--
1.8.0.1
^ permalink raw reply related
* input-headset driver probe failed for device
From: Kevin Wilson @ 2012-12-10 21:23 UTC (permalink / raw)
To: linux-bluetooth
Hell,
I am not sure whether this is the right list, I hope somebody can advice.
I have two machines, both with bt devices; hciconfig shows both
devices as UP and
RUNNING with bt addresses.
I run server on one side:
pand --listen --role GN
On the second, I try to connect with:
pand -c serverBtAddress --service GN
I see this message (twice) on the server log:
bluetoothd[1392]: input-headset driver probe failed for device
Any ideas why ? can it be avoided ?
And on the client side I see: "Connect to serverBtAddress failed"
AND "hcitool con" shows no connections:
Connections:
any idea?
rgs,
Kevin
^ permalink raw reply
* [PATCH] Bluetooth: Add support for IMC Networks [13d3:3393]
From: AceLan Kao @ 2012-12-11 3:41 UTC (permalink / raw)
To: linux-bluetooth, Gustavo F. Padovan, Marcel Holtmann,
Johan Hedberg
Add support for the AR9462 chip
T: Bus=02 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3393 Rev=00.01
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
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
Signed-off-by: AceLan Kao <acelan.kao@canonical.com>
---
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 fc2de55..73b1c30 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -80,6 +80,7 @@ static struct usb_device_id ath3k_table[] = {
{ USB_DEVICE(0x0CF3, 0xE004) },
{ USB_DEVICE(0x0930, 0x0219) },
{ USB_DEVICE(0x0489, 0xe057) },
+ { USB_DEVICE(0x13d3, 0x3393) },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE02C) },
@@ -107,6 +108,7 @@ static struct usb_device_id ath3k_blist_tbl[] = {
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU22 with sflash firmware */
{ USB_DEVICE(0x0489, 0xE03C), .driver_info = BTUSB_ATH3012 },
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5693b9b..171d42f 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -138,6 +138,7 @@ static struct usb_device_id blacklist_table[] = {
{ USB_DEVICE(0x0cf3, 0xe004), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
{ USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
+ { USB_DEVICE(0x13d3, 0x3393), .driver_info = BTUSB_ATH3012 },
/* Atheros AR5BBU12 with sflash firmware */
{ USB_DEVICE(0x0489, 0xe02c), .driver_info = BTUSB_IGNORE },
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/4] sap-u8500: Fix build errors due to unaligned memory access
From: Johan Hedberg @ 2012-12-11 5:43 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1353665354-32178-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Fri, Nov 23, 2012, Szymon Janc wrote:
> This fix following compilation error on ARM.
>
> CC profiles/sap/sap-u8500.o
> profiles/sap/sap-u8500.c: In function recv_card_status:
> profiles/sap/sap-u8500.c:323:16: error: cast increases required
> alignment of target type [-Werror=cast-align]
> profiles/sap/sap-u8500.c: In function recv_response:
> profiles/sap/sap-u8500.c:423:12: error: cast increases required
> alignment of target type [-Werror=cast-align]
> cc1: all warnings being treated as errors
> ---
> profiles/sap/sap-u8500.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Sorry about the delay with these. All four are now upstream.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ] hog: Rename prepend_id variable
From: Johan Hedberg @ 2012-12-11 5:45 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1355172866-3144-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Mon, Dec 10, 2012, Andre Guedes wrote:
> This patch renames the hog_device prepend_id field by has_report_id
> as long as it is more suitable.
>
> This variable indicates if we should consider the report id (adding
> or removing it) before sending it to device or uhid driver.
> ---
> profiles/input/hog_device.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [RFC] Bluetooth: Don't send new commands before CC for reset is received
From: Johan Hedberg @ 2012-12-11 7:32 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1355148525-29379-2-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Mon, Dec 10, 2012, Szymon Janc wrote:
> After sending reset command wait for its command complete event before
> sending next command. Some chips sends CC event for command received
> before reset if reset was send before chip replied with CC.
>
> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612
> > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850
> Write Extended Inquiry Response (0x03|0x0052) ncmd 1
> Status: Success (0x00)
> < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079
> > HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864
> Reset (0x03|0x0003) ncmd 1
> Status: Success (0x00)
> < HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062
> > HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835
>
> Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
> ---
> net/bluetooth/hci_event.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 705078a..81b4448 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -2688,7 +2688,7 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
> if (ev->opcode != HCI_OP_NOP)
> del_timer(&hdev->cmd_timer);
>
> - if (ev->ncmd) {
> + if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) {
> atomic_set(&hdev->cmd_cnt, 1);
> if (!skb_queue_empty(&hdev->cmd_q))
> queue_work(hdev->workqueue, &hdev->cmd_work);
This looks fine to me though I'd consider adding a Cc: stable tag to it
and rename the summary to "Fix sending commands..." to make clear that
this is a fix.
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Johan
^ permalink raw reply
* [PATCH] Bluetooth: Fix sending HCI commands after reset
From: Szymon Janc @ 2012-12-11 7:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc, stable
After sending reset command wait for its command complete event before
sending next command. Some chips sends CC event for command received
before reset if reset was send before chip replied with CC.
This is also required by specification that host shall not send
additional HCI commands before receiving CC for reset.
< HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 18.404612
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.405850
Write Extended Inquiry Response (0x03|0x0052) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.406079
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 18.407864
Reset (0x03|0x0003) ncmd 1
Status: Success (0x00)
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0 [hci0] 18.408062
> HCI Event: Command Complete (0x0e) plen 12 [hci0] 18.408835
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Cc: stable@vger.kernel.org
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
---
net/bluetooth/hci_event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 705078a..81b4448 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2688,7 +2688,7 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
if (ev->opcode != HCI_OP_NOP)
del_timer(&hdev->cmd_timer);
- if (ev->ncmd) {
+ if (ev->ncmd && !test_bit(HCI_RESET, &hdev->flags)) {
atomic_set(&hdev->cmd_cnt, 1);
if (!skb_queue_empty(&hdev->cmd_q))
queue_work(hdev->workqueue, &hdev->cmd_work);
--
1.7.9.5
^ permalink raw reply related
* RE: [RFC BlueZ v1] media-api: Add org.bluez.MediaLibrary1
From: Oleksandr.Domin @ 2012-12-11 12:57 UTC (permalink / raw)
To: luiz.dentz, linux-bluetooth
In-Reply-To: <1354891631-17994-1-git-send-email-luiz.dentz@gmail.com>
Hi Luis,
>From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
>This interface adds support for browsing and searching in the player's
>storage using AVRCP 1.4/1.5.
>
>Some remarks about the design:
>
> - Exposing UIDCounter and UIDs was considered, but the spec seems to have
> missed to define the player's id persistency. There are also the fact
>that
> UIDCounter alone does not guarantee persistency across sessions and do
>not
> provide what exact items have changed, so in the end exposing these
> details will bring almost no value.
In case UIDCounter I agree we have no value, but we need to expose UIDs
for found and browsed media items. I am thinking about IVI use cases like
"search", "file browsing" and "content browsing". In this case you have
not only AVRCP device but also USB and other devices you would like to
run you use cases. And you would like to combine results in to one
global list and initiate playback.
I know we cannot rely on this UIDs but in case we get UIDCounter changed
application has to delete all UIDs and start from the beginning.
> - Indexing or caching the whole media library is not recommended,
>Bluetooth
> is too slow for that and even vendors such as Apple do not recommend
>doing
> it, so the only items keep in cache are the current listed ones.
Question is why do we need this cache on D-Bus (Object manager)? If we
return this information it's up to the application to do whatever
it wants.
> - Addressed vs Browsed player is done implicitly when accessed, this was
>done
> to simplify the API and avoid confusions between applications and
>players.
>---
>v1: Rename to MediaLibrary and add versioning, also rename Properties filter
>to attributes and don't use camel case for values.
>
> doc/media-api.txt | 173
>++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 173 insertions(+)
>
>diff --git a/doc/media-api.txt b/doc/media-api.txt
>index 1865df9..0926e43 100644
>--- a/doc/media-api.txt
>+++ b/doc/media-api.txt
>@@ -219,6 +219,179 @@ Properties string Equalizer [readwrite]
> possible to signal its end by setting position to the
> maximum uint32 value.
As I see we have properties like "Equalizer", "Repeat" "Shuffle"
and "Scan" per player. But I think from the application point of view
it's good to set it once and to lat BlueZ handle this state's internally.
In this case we would also reduce calls on D-Bus and simplify the logic
in the application above.
>
>+ string Name [readonly]
>+
>+ Player name
>+
>+ boolean Browsable [readonly]
>+
>+ If present indicates the player can be browsed using
>+ MediaLibrary interface.
>+
>+ Possible values:
>+
>+ True: Supported and active
>+ False: Supported but inactive
Is it possible to change to: Supported while active and supported while
inactive? In case of active we are talking about while addressed player.
>+
>+ Note: If supported but inactive clients can enable it
>+ by using MediaLibrary interface but it might interfere
>+ in the playback of other players.
>+
>+
>+ boolean Searchable [readonly]
>+
>+ If present indicates the player can be searched using
>+ MediaLibrary interface.
>+
>+ Possible values:
>+
>+ True: Supported and active
>+ False: Supported but inactive
>+
>+ Note: If supported but inactive clients can enable it
>+ by using MediaLibrary interface but it might interfere
>+ in the playback of other players.
>+
>+ array{string} Buttons [readonly]
>+
>+ If available indicates the buttons supported by the
>+ player.
>+
>+ Possible values:
>+
>+ "Play", "Pause", "Stop", "Next", "Previous",
>+ "FastForward" and "Rewind"
>+
>+ Default value: All
Do we return the enum ALL or to we return all values?
In addition I miss the Media Player Type and Player Subtype properties.
In case MediaPlayerType we have:
Audio
Video
Broadcastingaudio
Broadcastingvideo
In case PlayerSubType we have:
AudioBook
Podcast
>+
>+MediaLibrary1 hierarchy
>+=======================
>+
>+Service unique name (Target role)
>+ org.bluez (Controller role)
>+Interface org.bluez.MediaLibrary1
>+Object path freely definable (Target role)
>+ [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/player
Are you talking about
[variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/MediaLibraryX
>+ (Controller role)
>+
>+Methods array{objects, properties} Search(string value, dict
>filter)
>+
>+ Return a list of MediaItem found
I think in this case we need to return only the number of media items
found by the search method. In the second step you can ask the stack
to list all items (ListItems).
>+
>+ array{objects, properties} ListItems(dict filter)
>+
>+ Return a list of MediaItem found
Also here we need a numberOfItems parameter instead of the filter.
If you have to search you would like also to set the filter if you
want to browse (and we are talking about file browsing) we have
to return all results in the folder. We have to use the filter
other in Search or in ListItem but not in both.
I am also not a freand of returning objects. I think we need to
return a dict with the media item ID and meta data.
>+
>+ void ChangeFolder(string path)
>+
>+ Change current folder, support both relative or
>+ absolute paths.
>+
>+Properties uint32 NumberOfItems:
>+
>+ Number of items in the current folder
I think we need this property as a return value. Result of the
Search and ChangeFolder return different values. For example you
do start search and the system will update the number of items
and in the second step you execute ChangeFolder and BleuZ is
updating the number of items. How do you know now how mach items
do you have in search? So we need for Search and ChangeFolder
different properties.
>+
>+ string Path:
>+
>+ Current path:
>+
>+ Possible values: "/root/folder" or "/NowPlaying"
>+
>+ Note: /NowPlaying might not be listed if player is
>+ stopped
It's good to have this property but I think we also need
ListNowPlaing method without changing the paht to /NowPlaying.
Requests ChangeFolder and ListNowPlaying are addressed to
different players the one to the browsed and the second to the
addressed player
>+
>+Filters uint32 Start:
>+
>+ Offset of the first item.
>+
>+ Default value: 0
>+
>+ uint32 End:
>+
>+ Offset of the last item.
>+
>+ Default value: NumbeOfItems
In case we use NumberOfItems we also need one value not only for the
ChangeFolder but even for Search.
>+
>+ array{string} Attributes
>+
>+ Item properties that should be included in the list.
>+
>+ Possible Values:
>+
>+ "title", "artist", "album", "genre",
>+ "number-of-tracks", "number", "duration"
>+
>+ Default Value: All
>+
>+MediaItem1 hierarchy
>+====================
>+
>+Service unique name (Target role)
>+ org.bluez (Controller role)
>+Interface org.bluez.MediaItem1
>+Object path freely definable (Target role)
>+ [variable
>+ prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/playerX/itemX
>+ (Controller role)
In fact I do not like this Item representation as object in D-Bus.
In this case we have 1000 D-Bus calls and more if you are trying to
remove and add items from D-Bus.
The second limitation is on IVI you cannot create your own lists to
play. And I think the API should be as generic as possible in this
case.
>+
>+Methods void Play()
>+
>+ Play item
>+
>+ void AddtoNowPlaying()
>+
>+ Add item to now playing list
>+
>+Properties string Name [readonly]
>+
>+ Item displayable name
>+
>+ boolean Folder [readonly]
>+
>+ Indicates whether the item is a folder
>+
>+ string Type [readonly]
>+
>+ Item type
>+
>+ Possible values:
>+
>+ Folder: "Mixed", "Titles", "Albums", "Artists"
>+ Other Items: "Video", "Audio"
>+
>+ boolean Playable [readonly]
>+
>+ Indicates if the item can be played
>+
>+ string Title:
>+
>+ Item title name
>+
>+ string Artist:
>+
>+ Item artist name
>+
>+ string Album:
>+
>+ Item album name
>+
>+ string Genre:
>+
>+ Item genre name
>+
>+ uint32 NumberOfTracks:
>+
>+ Item album number of tracks in total
>+
>+ uint32 Number:
>+
>+ Item album number
>+
>+ uint32 Duration:
>+
>+ Item duration in milliseconds
>+
>+
> MediaEndpoint1 hierarchy
> ========================
>
>--
>1.7.11.7
>
>--
>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: [RFC BlueZ v1] media-api: Add org.bluez.MediaLibrary1
From: Luiz Augusto von Dentz @ 2012-12-11 14:35 UTC (permalink / raw)
To: Oleksandr.Domin; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <9F89C4B87365E4408446E7FF5C4AE97115A0CB9A78@SMUCM17V.europe.bmw.corp>
Hi Oleksandr,
On Tue, Dec 11, 2012 at 2:57 PM, <Oleksandr.Domin@bmw.de> wrote:
> Hi Luis,
>
>>From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>>
>>This interface adds support for browsing and searching in the player's
>>storage using AVRCP 1.4/1.5.
>>
>>Some remarks about the design:
>>
>> - Exposing UIDCounter and UIDs was considered, but the spec seems to have
>> missed to define the player's id persistency. There are also the fact
>>that
>> UIDCounter alone does not guarantee persistency across sessions and do
>>not
>> provide what exact items have changed, so in the end exposing these
>> details will bring almost no value.
>
> In case UIDCounter I agree we have no value, but we need to expose UIDs
> for found and browsed media items. I am thinking about IVI use cases like
> "search", "file browsing" and "content browsing". In this case you have
> not only AVRCP device but also USB and other devices you would like to
> run you use cases. And you would like to combine results in to one
> global list and initiate playback.
If you need to cache any information, which is not recommended, you
are in your own to assume the player id or name are persistent, but if
you do so you can also assume the folder are persistent as well then
just cache them. The important part is that you have to rediscover
them to find out what is the current UID for the item.
> I know we cannot rely on this UIDs but in case we get UIDCounter changed
> application has to delete all UIDs and start from the beginning.
Yes, and that would be done automatically by ObjectManager for the
current listed items.
>> - Indexing or caching the whole media library is not recommended,
>>Bluetooth
>> is too slow for that and even vendors such as Apple do not recommend
>>doing
>> it, so the only items keep in cache are the current listed ones.
>
> Question is why do we need this cache on D-Bus (Object manager)? If we
> return this information it's up to the application to do whatever
> it wants.
To track the item's UID, otherwise we always have to access by path
and discover the UID in the background since the UID is unreliable.
>> - Addressed vs Browsed player is done implicitly when accessed, this was
>>done
>> to simplify the API and avoid confusions between applications and
>>players.
>>---
>>v1: Rename to MediaLibrary and add versioning, also rename Properties filter
>>to attributes and don't use camel case for values.
>>
>> doc/media-api.txt | 173
>>++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 173 insertions(+)
>>
>>diff --git a/doc/media-api.txt b/doc/media-api.txt
>>index 1865df9..0926e43 100644
>>--- a/doc/media-api.txt
>>+++ b/doc/media-api.txt
>>@@ -219,6 +219,179 @@ Properties string Equalizer [readwrite]
>> possible to signal its end by setting position to the
>> maximum uint32 value.
>
> As I see we have properties like "Equalizer", "Repeat" "Shuffle"
> and "Scan" per player. But I think from the application point of view
> it's good to set it once and to lat BlueZ handle this state's internally.
> In this case we would also reduce calls on D-Bus and simplify the logic
> in the application above.
This is per player, if you want to replicate your status to each
player you can do it but I don't think BlueZ should assume all of them
have the same setting.
>
>>
>>+ string Name [readonly]
>>+
>>+ Player name
>>+
>>+ boolean Browsable [readonly]
>>+
>>+ If present indicates the player can be browsed using
>>+ MediaLibrary interface.
>>+
>>+ Possible values:
>>+
>>+ True: Supported and active
>>+ False: Supported but inactive
>
> Is it possible to change to: Supported while active and supported while
> inactive? In case of active we are talking about while addressed player.
Sure that can be done.
>>+
>>+ Note: If supported but inactive clients can enable it
>>+ by using MediaLibrary interface but it might interfere
>>+ in the playback of other players.
>>+
>>+
>>+ boolean Searchable [readonly]
>>+
>>+ If present indicates the player can be searched using
>>+ MediaLibrary interface.
>>+
>>+ Possible values:
>>+
>>+ True: Supported and active
>>+ False: Supported but inactive
>>+
>>+ Note: If supported but inactive clients can enable it
>>+ by using MediaLibrary interface but it might interfere
>>+ in the playback of other players.
>>+
>>+ array{string} Buttons [readonly]
>>+
>>+ If available indicates the buttons supported by the
>>+ player.
>>+
>>+ Possible values:
>>+
>>+ "Play", "Pause", "Stop", "Next", "Previous",
>>+ "FastForward" and "Rewind"
>>+
>>+ Default value: All
>
> Do we return the enum ALL or to we return all values?
>
> In addition I miss the Media Player Type and Player Subtype properties.
> In case MediaPlayerType we have:
> Audio
> Video
> Broadcastingaudio
> Broadcastingvideo
>
> In case PlayerSubType we have:
> AudioBook
> Podcast
If that is useful I can add it no problem, but note that since you can
only play items from its own media library Im not sure this will be
useful for anything except maybe for filtering what player you display
to the user.
>>+
>>+MediaLibrary1 hierarchy
>>+=======================
>>+
>>+Service unique name (Target role)
>>+ org.bluez (Controller role)
>>+Interface org.bluez.MediaLibrary1
>>+Object path freely definable (Target role)
>>+ [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/player
>
> Are you talking about
> [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/MediaLibraryX
>
>>+ (Controller role)
>>+
>>+Methods array{objects, properties} Search(string value, dict
>>filter)
>>+
>>+ Return a list of MediaItem found
>
> I think in this case we need to return only the number of media items
> found by the search method. In the second step you can ask the stack
> to list all items (ListItems).
Well the underlining protocol is designed like this so to get the
number of items you have to search anyway so why not return the items
too? Perhaps you are suggesting to join this with ListItems so we
could in theory have a search string as filter which will do just the
same.
>>+
>>+ array{objects, properties} ListItems(dict filter)
>>+
>>+ Return a list of MediaItem found
>
> Also here we need a numberOfItems parameter instead of the filter.
> If you have to search you would like also to set the filter if you
> want to browse (and we are talking about file browsing) we have
> to return all results in the folder. We have to use the filter
> other in Search or in ListItem but not in both.
You can provide Start and End as filter with that you can select how
many items you want in the return.
> I am also not a freand of returning objects. I think we need to
> return a dict with the media item ID and meta data.
The object is an id and the metadata is the properties and they both
are returned.
>>+
>>+ void ChangeFolder(string path)
>>+
>>+ Change current folder, support both relative or
>>+ absolute paths.
>>+
>>+Properties uint32 NumberOfItems:
>>+
>>+ Number of items in the current folder
>
> I think we need this property as a return value. Result of the
> Search and ChangeFolder return different values. For example you
> do start search and the system will update the number of items
> and in the second step you execute ChangeFolder and BleuZ is
> updating the number of items. How do you know now how mach items
> do you have in search? So we need for Search and ChangeFolder
> different properties.
What do you mean how many items you have in the search, we return a
list which the application will have to iterate, the number of items
is only interesting if you are not listen them, we could perhaps even
have it as return to ChangeFolder but anyway the property will be
updated everytime you change the folder.
>>+
>>+ string Path:
>>+
>>+ Current path:
>>+
>>+ Possible values: "/root/folder" or "/NowPlaying"
>>+
>>+ Note: /NowPlaying might not be listed if player is
>>+ stopped
>
> It's good to have this property but I think we also need
> ListNowPlaing method without changing the paht to /NowPlaying.
> Requests ChangeFolder and ListNowPlaying are addressed to
> different players the one to the browsed and the second to the
> addressed player
But that is exactly the purpose to expose NowPlaying as a folder, the
application has to request it explicitly which may not be there if the
player is not addressed and in addition we list the items there. Btw,
you can still do browse one player and list NowPlaying on other the
only thing that we are limiting is browsing both NowPlaying and
filesystem together which anyway is not possible since that would be
to the same device and the requests are no done in parallel
>>+
>>+Filters uint32 Start:
>>+
>>+ Offset of the first item.
>>+
>>+ Default value: 0
>>+
>>+ uint32 End:
>>+
>>+ Offset of the last item.
>>+
>>+ Default value: NumbeOfItems
>
> In case we use NumberOfItems we also need one value not only for the
> ChangeFolder but even for Search.
Search return a list of items found, NumberOfItems represents the
items in the folder just so the application can know in advance how
much traffic it would cause and possible download them in windowing
mode.
>>+
>>+ array{string} Attributes
>>+
>>+ Item properties that should be included in the list.
>>+
>>+ Possible Values:
>>+
>>+ "title", "artist", "album", "genre",
>>+ "number-of-tracks", "number", "duration"
>>+
>>+ Default Value: All
>>+
>>+MediaItem1 hierarchy
>>+====================
>>+
>>+Service unique name (Target role)
>>+ org.bluez (Controller role)
>>+Interface org.bluez.MediaItem1
>>+Object path freely definable (Target role)
>>+ [variable
>>+ prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/playerX/itemX
>>+ (Controller role)
>
> In fact I do not like this Item representation as object in D-Bus.
> In this case we have 1000 D-Bus calls and more if you are trying to
> remove and add items from D-Bus.
You don't remove or add, you list them, if you want to list only 10
items you can do that and only 10 objects would be created.
> The second limitation is on IVI you cannot create your own lists to
> play. And I think the API should be as generic as possible in this
> case.
You can create your own list, you just have to list them to refresh
the UID, btw if you use the NowPlaying list that should be persistent.
It the mixing of different sources that would be a problem, since with
that you cannot use NowPlaying, or perhaps you can by stopping the
playing when switching to another source but this could racy.
--
Luiz Augusto von Dentz
^ permalink raw reply
* RE: [RFC BlueZ v1] media-api: Add org.bluez.MediaLibrary1
From: Oleksandr.Domin @ 2012-12-11 16:53 UTC (permalink / raw)
To: luiz.dentz; +Cc: linux-bluetooth
In-Reply-To: <CABBYNZ+1PR_M+G=g8iFp19-sokNWoCkE7Mk+xV5KqNkb7Qk-9A@mail.gmail.com>
Hi Luiz
>
>Hi Oleksandr,
>
>On Tue, Dec 11, 2012 at 2:57 PM, <Oleksandr.Domin@bmw.de> wrote:
>> Hi Luiz,
>>
>>>From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>>>
>>>This interface adds support for browsing and searching in the player's
>>>storage using AVRCP 1.4/1.5.
>>>
>>>Some remarks about the design:
>>>
>>> - Exposing UIDCounter and UIDs was considered, but the spec seems to
>have
>>> missed to define the player's id persistency. There are also the fact
>>>that
>>> UIDCounter alone does not guarantee persistency across sessions and do
>>>not
>>> provide what exact items have changed, so in the end exposing these
>>> details will bring almost no value.
>>
>> In case UIDCounter I agree we have no value, but we need to expose UIDs
>> for found and browsed media items. I am thinking about IVI use cases like
>> "search", "file browsing" and "content browsing". In this case you have
>> not only AVRCP device but also USB and other devices you would like to
>> run you use cases. And you would like to combine results in to one
>> global list and initiate playback.
>
>If you need to cache any information, which is not recommended, you
>are in your own to assume the player id or name are persistent, but if
>you do so you can also assume the folder are persistent as well then
>just cache them. The important part is that you have to rediscover
>them to find out what is the current UID for the item.
>
>> I know we cannot rely on this UIDs but in case we get UIDCounter changed
>> application has to delete all UIDs and start from the beginning.
>
>Yes, and that would be done automatically by ObjectManager for the
>current listed items.
>
>>> - Indexing or caching the whole media library is not recommended,
>>>Bluetooth
>>> is too slow for that and even vendors such as Apple do not recommend
>>>doing
>>> it, so the only items keep in cache are the current listed ones.
>>
>> Question is why do we need this cache on D-Bus (Object manager)? If we
>> return this information it's up to the application to do whatever
>> it wants.
>
>To track the item's UID, otherwise we always have to access by path
>and discover the UID in the background since the UID is unreliable.
So I see. We have the an Item represented as an object. This item has
internally the UID to be able to send it to the target for playing. In case
UIDCounter will be updated the object will be deleted. But if UIDCounter
is unchanged you can use only PlayItem(UID) ignoring the Item object?
>
>>> - Addressed vs Browsed player is done implicitly when accessed, this was
>>>done
>>> to simplify the API and avoid confusions between applications and
>>>players.
>>>---
>>>v1: Rename to MediaLibrary and add versioning, also rename Properties
>filter
>>>to attributes and don't use camel case for values.
>>>
>>> doc/media-api.txt | 173
>>>++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 173 insertions(+)
>>>
>>>diff --git a/doc/media-api.txt b/doc/media-api.txt
>>>index 1865df9..0926e43 100644
>>>--- a/doc/media-api.txt
>>>+++ b/doc/media-api.txt
>>>@@ -219,6 +219,179 @@ Properties string Equalizer [readwrite]
>>> possible to signal its end by setting position to
>the
>>> maximum uint32 value.
>>
>> As I see we have properties like "Equalizer", "Repeat" "Shuffle"
>> and "Scan" per player. But I think from the application point of view
>> it's good to set it once and to lat BlueZ handle this state's internally.
>> In this case we would also reduce calls on D-Bus and simplify the logic
>> in the application above.
>
>This is per player, if you want to replicate your status to each
>player you can do it but I don't think BlueZ should assume all of them
>have the same setting.
I think we what design our applications as simple as possible. Please think
about the following use case:
1. The customer is changing the player configuration.
2. This configuration will be applied for each media source
Bluetooth AVRCP is in our case one audio source but with several players.
But still I would expect BlueZ can handle this. I also agree if I
change the player I can first of all read settings by the upper application
and set it to the customer settings. But you need to do this every time
you changing the player ;-)
>
>>
>>>
>>>+ string Name [readonly]
>>>+
>>>+ Player name
>>>+
>>>+ boolean Browsable [readonly]
>>>+
>>>+ If present indicates the player can be browsed
>using
>>>+ MediaLibrary interface.
>>>+
>>>+ Possible values:
>>>+
>>>+ True: Supported and active
>>>+ False: Supported but inactive
>>
>> Is it possible to change to: Supported while active and supported while
>> inactive? In case of active we are talking about while addressed player.
>
>Sure that can be done.
>
>>>+
>>>+ Note: If supported but inactive clients can enable
>it
>>>+ by using MediaLibrary interface but it might
>interfere
>>>+ in the playback of other players.
>>>+
>>>+
>>>+ boolean Searchable [readonly]
>>>+
>>>+ If present indicates the player can be searched
>using
>>>+ MediaLibrary interface.
>>>+
>>>+ Possible values:
>>>+
>>>+ True: Supported and active
>>>+ False: Supported but inactive
>>>+
>>>+ Note: If supported but inactive clients can enable
>it
>>>+ by using MediaLibrary interface but it might
>interfere
>>>+ in the playback of other players.
>>>+
>>>+ array{string} Buttons [readonly]
>>>+
>>>+ If available indicates the buttons supported by the
>>>+ player.
>>>+
>>>+ Possible values:
>>>+
>>>+ "Play", "Pause", "Stop", "Next",
>"Previous",
>>>+ "FastForward" and "Rewind"
>>>+
>>>+ Default value: All
>>
>> Do we return the enum ALL or to we return all values?
>>
>> In addition I miss the Media Player Type and Player Subtype properties.
>> In case MediaPlayerType we have:
>> Audio
>> Video
>> Broadcastingaudio
>> Broadcastingvideo
>>
>> In case PlayerSubType we have:
>> AudioBook
>> Podcast
>
>If that is useful I can add it no problem, but note that since you can
>only play items from its own media library Im not sure this will be
>useful for anything except maybe for filtering what player you display
>to the user.
I am not sure, but I think this information could be useful.
>
>>>+
>>>+MediaLibrary1 hierarchy
>>>+=======================
>>>+
>>>+Service unique name (Target role)
>>>+ org.bluez (Controller role)
>>>+Interface org.bluez.MediaLibrary1
>>>+Object path freely definable (Target role)
>>>+ [variable
>prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/player
>>
>> Are you talking about
>> [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/MediaLibraryX
>>
>>>+ (Controller role)
>>>+
>>>+Methods array{objects, properties} Search(string value,
>dict
>>>filter)
>>>+
>>>+ Return a list of MediaItem found
>>
>> I think in this case we need to return only the number of media items
>> found by the search method. In the second step you can ask the stack
>> to list all items (ListItems).
>
>Well the underlining protocol is designed like this so to get the
>number of items you have to search anyway so why not return the items
>too? Perhaps you are suggesting to join this with ListItems so we
>could in theory have a search string as filter which will do just the
>same.
No, in case you are searching you will get the number of items
found by the search. You need to call getFolderItems and the
number of items you would like to download. And if you remember our
discussion, if we have low budget IVI system you could download only
the first 100 items. If you do it in one call you will return all items.
The second reason is if you use only one function to download item
by calling ListItems you can easily cancel the previous initiated
ListItems call (canceling previous item download).
>
>>>+
>>>+ array{objects, properties} ListItems(dict filter)
>>>+
>>>+ Return a list of MediaItem found
>>
>> Also here we need a numberOfItems parameter instead of the filter.
>> If you have to search you would like also to set the filter if you
>> want to browse (and we are talking about file browsing) we have
>> to return all results in the folder. We have to use the filter
>> other in Search or in ListItem but not in both.
>
>You can provide Start and End as filter with that you can select how
>many items you want in the return.
You will know the start and end items only if you know the number of
items before you start ListItems
>
>> I am also not a freand of returning objects. I think we need to
>> return a dict with the media item ID and meta data.
>
>The object is an id and the metadata is the properties and they both
>are returned.
Yes, I agree but I think in our case it's not what we want.
>
>>>+
>>>+ void ChangeFolder(string path)
>>>+
>>>+ Change current folder, support both relative or
>>>+ absolute paths.
>>>+
>>>+Properties uint32 NumberOfItems:
>>>+
>>>+ Number of items in the current folder
>>
>> I think we need this property as a return value. Result of the
>> Search and ChangeFolder return different values. For example you
>> do start search and the system will update the number of items
>> and in the second step you execute ChangeFolder and BleuZ is
>> updating the number of items. How do you know now how mach items
>> do you have in search? So we need for Search and ChangeFolder
>> different properties.
>
>What do you mean how many items you have in the search, we return a
>list which the application will have to iterate, the number of items
>is only interesting if you are not listen them, we could perhaps even
>have it as return to ChangeFolder but anyway the property will be
>updated everytime you change the folder.
No the use case is as followed:
1. initiate ChangeFolder "/"
2. NumberOfItems will be set to 20
3. initiate Search
4. NumberOfItems will be set to 50
5. How do I get the number of items in the "/" directory know?
>
>>>+
>>>+ string Path:
>>>+
>>>+ Current path:
>>>+
>>>+ Possible values: "/root/folder" or "/NowPlaying"
>>>+
>>>+ Note: /NowPlaying might not be listed if player is
>>>+ stopped
>>
>> It's good to have this property but I think we also need
>> ListNowPlaing method without changing the paht to /NowPlaying.
>> Requests ChangeFolder and ListNowPlaying are addressed to
>> different players the one to the browsed and the second to the
>> addressed player
>
>But that is exactly the purpose to expose NowPlaying as a folder, the
>application has to request it explicitly which may not be there if the
>player is not addressed and in addition we list the items there. Btw,
>you can still do browse one player and list NowPlaying on other the
>only thing that we are limiting is browsing both NowPlaying and
>filesystem together which anyway is not possible since that would be
>to the same device and the requests are no done in parallel
This is something I would like to understand. I think you can do
Change folder "path" for the browsed player and list know playing
For the addressed player in parallel. But please correct me If I am wrong.
>
>>>+
>>>+Filters uint32 Start:
>>>+
>>>+ Offset of the first item.
>>>+
>>>+ Default value: 0
>>>+
>>>+ uint32 End:
>>>+
>>>+ Offset of the last item.
>>>+
>>>+ Default value: NumbeOfItems
>>
>> In case we use NumberOfItems we also need one value not only for the
>> ChangeFolder but even for Search.
>
>Search return a list of items found, NumberOfItems represents the
>items in the folder just so the application can know in advance how
>much traffic it would cause and possible download them in windowing
>mode.
>
>>>+
>>>+ array{string} Attributes
>>>+
>>>+ Item properties that should be included in the
>list.
>>>+
>>>+ Possible Values:
>>>+
>>>+ "title", "artist", "album", "genre",
>>>+ "number-of-tracks", "number", "duration"
>>>+
>>>+ Default Value: All
>>>+
>>>+MediaItem1 hierarchy
>>>+====================
>>>+
>>>+Service unique name (Target role)
>>>+ org.bluez (Controller role)
>>>+Interface org.bluez.MediaItem1
>>>+Object path freely definable (Target role)
>>>+ [variable
>>>+ prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/playerX/itemX
>>>+ (Controller role)
>>
>> In fact I do not like this Item representation as object in D-Bus.
>> In this case we have 1000 D-Bus calls and more if you are trying to
>> remove and add items from D-Bus.
>
>You don't remove or add, you list them, if you want to list only 10
>items you can do that and only 10 objects would be created.
>
>> The second limitation is on IVI you cannot create your own lists to
>> play. And I think the API should be as generic as possible in this
>> case.
>
>You can create your own list, you just have to list them to refresh
>the UID, btw if you use the NowPlaying list that should be persistent.
>It the mixing of different sources that would be a problem, since with
>that you cannot use NowPlaying, or perhaps you can by stopping the
>playing when switching to another source but this could racy.
I think in IVI do use our own global item list to play and not the
NowPlaing one from the phone. Because we have already different
Interpretations of the implementation with Iphone and the Windows 8.
If you select on the Iphone any item in a folder to play all folder
Items will be added to the NowPlaying list. In case on Windows 8 only
this item will be added to the NowPlaing list and this item will play
in a loop.
Thank you for your feedback
Regards
Oleksandr
^ permalink raw reply
* [RFC v2 0/5] sco: SCO socket option for mode
From: Frédéric Dalleau @ 2012-12-11 16:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
Hi,
This is v2 of the patch for codec option on SCO sockets. Some people asked
for more generic behavior, so I renamed the 'codec' field as 'mode' in order to
provide some way to extend the socket option. So it is still an RFC. Feel
free to comment the API in patch 1.
Since previous version, the patch is now able to use T2 codec settings and
switch to T1 if T2 fails (see HFP 1.6 p.102). The fallback is implemented by
using the connection attempt counter to determine what settings to use. I did
so because the fallback mechanism is more generic in this case, and this can be
reused for S3, S2, S1! However, one bit is still needed in the hci flags, and
it is likely that one bit will be needed for each supported 'modes'.
The fallback mechanism is only available on outgoing connections. For incoming
connections, the only to be sure to accept T2 is to call AcceptSyncConnReq with
2EV3 packet type only. But if an incoming connection was done with T1 (EV3)
then we cannot accept it at all: it is not possible to retry an AcceptSyncConn
Req. We can't guess in advance whether some third party wants to connect T2 or
T1. So currently, all supported packets type are accepted.
I also took Andrei comment into account exporting hci_connect_sco. This really
simplifies.
Let me know what you think.
Best regards,
Frédéric
Frédéric Dalleau (5):
Bluetooth: Add option for SCO socket mode
Bluetooth: Add setsockopt for SCO socket mode
Bluetooth: Use codec to create SCO connection
Bluetooth: Set parameters for outgoing connections
Bluetooth: Fallback transparent SCO from T2 to T1
include/net/bluetooth/hci_core.h | 5 +++-
include/net/bluetooth/sco.h | 19 ++++++++++++++
net/bluetooth/hci_conn.c | 30 +++++++++++++++++----
net/bluetooth/hci_event.c | 22 +++++++++++++---
net/bluetooth/sco.c | 53 +++++++++++++++++++++++++++++++++++---
5 files changed, 116 insertions(+), 13 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [RFC v2 1/5] Bluetooth: Add option for SCO socket mode
From: Frédéric Dalleau @ 2012-12-11 16:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1355244832-2729-1-git-send-email-frederic.dalleau@linux.intel.com>
This patch extends the current SCO socket option to add a 'mode' field. This
field is intended to choose data type at runtime. Current modes are CVSD and
transparent SCO, but adding new modes could allow support for CSA2 and fine
tuning a sco connection, for example latency, bandwith, voice setting. Incoming
connections will be setup during defered setup. Outgoing connections have to
be setup before connect(). The selected type is stored in the sco socket info.
This patch declares needed members and implements getsockopt().
---
include/net/bluetooth/sco.h | 19 +++++++++++++++++++
net/bluetooth/sco.c | 3 +++
2 files changed, 22 insertions(+)
diff --git a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h
index 1e35c43..1798fd3 100644
--- a/include/net/bluetooth/sco.h
+++ b/include/net/bluetooth/sco.h
@@ -41,8 +41,26 @@ struct sockaddr_sco {
/* SCO socket options */
#define SCO_OPTIONS 0x01
+
+#define SCO_MODE_CVSD 0x00
+#define SCO_MODE_TRANSPARENT 0x01
+#define SCO_MODE_ENHANCED 0x02
struct sco_options {
__u16 mtu;
+ __u8 mode;
+};
+
+struct sco_coding {
+ __u8 format;
+ __u16 vid;
+ __u16 cid;
+};
+
+struct sco_options_enhanced {
+ __u16 mtu;
+ __u8 mode;
+ struct sco_coding host;
+ struct sco_coding air;
};
#define SCO_CONNINFO 0x02
@@ -73,6 +91,7 @@ struct sco_conn {
struct sco_pinfo {
struct bt_sock bt;
__u32 flags;
+ __u8 mode;
struct sco_conn *conn;
};
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 531a93d..bdb21b2 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -418,6 +418,8 @@ static struct sock *sco_sock_alloc(struct net *net, struct socket *sock, int pro
sk->sk_protocol = proto;
sk->sk_state = BT_OPEN;
+ sco_pi(sk)->mode = SCO_MODE_CVSD;
+
setup_timer(&sk->sk_timer, sco_sock_timeout, (unsigned long)sk);
bt_sock_link(&sco_sk_list, sk);
@@ -736,6 +738,7 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname, char __user
}
opts.mtu = sco_pi(sk)->conn->mtu;
+ opts.mode = sco_pi(sk)->mode;
BT_DBG("mtu %d", opts.mtu);
--
1.7.9.5
^ permalink raw reply related
* [RFC v2 2/5] Bluetooth: Add setsockopt for SCO socket mode
From: Frédéric Dalleau @ 2012-12-11 16:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1355244832-2729-1-git-send-email-frederic.dalleau@linux.intel.com>
This patch implements setsockopt().
---
net/bluetooth/sco.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index bdb21b2..22ad5fa 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -678,6 +678,47 @@ static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
return bt_sock_recvmsg(iocb, sock, msg, len, flags);
}
+static int sco_sock_setsockopt_old(struct socket *sock, int optname,
+ char __user *optval, unsigned int optlen)
+{
+ struct sock *sk = sock->sk;
+ struct sco_options opts;
+ int len, err = 0;
+
+ BT_DBG("sk %p", sk);
+
+ lock_sock(sk);
+
+ switch (optname) {
+ case SCO_OPTIONS:
+ if (sk->sk_state != BT_OPEN &&
+ sk->sk_state != BT_BOUND &&
+ sk->sk_state != BT_CONNECT2) {
+ err = -EINVAL;
+ break;
+ }
+
+ opts.mode = SCO_MODE_CVSD;
+
+ len = min_t(unsigned int, sizeof(opts), optlen);
+ if (copy_from_user((char *) &opts, optval, len)) {
+ err = -EFAULT;
+ break;
+ }
+
+ sco_pi(sk)->mode = opts.mode;
+ BT_DBG("mode %d", opts.mode);
+ break;
+
+ default:
+ err = -ENOPROTOOPT;
+ break;
+ }
+
+ release_sock(sk);
+ return err;
+}
+
static int sco_sock_setsockopt(struct socket *sock, int level, int optname, char __user *optval, unsigned int optlen)
{
struct sock *sk = sock->sk;
@@ -686,6 +727,9 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname, char
BT_DBG("sk %p", sk);
+ if (level == SOL_SCO)
+ return sco_sock_setsockopt_old(sock, optname, optval, optlen);
+
lock_sock(sk);
switch (optname) {
--
1.7.9.5
^ 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