* [PATCHv1 03/26] Bluetooth: Add HCI logical link cmds definitions
From: Andrei Emeltchenko @ 2012-08-17 14:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1345214001-7053-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
include/net/bluetooth/hci.h | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 0f28f70..42aae18 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -556,12 +556,46 @@ struct hci_cp_accept_phy_link {
__u8 key[HCI_AMP_LINK_KEY_SIZE];
} __packed;
-#define HCI_OP_DISCONN_PHY_LINK 0x0437
+#define HCI_OP_DISCONN_PHY_LINK 0x0437
struct hci_cp_disconn_phy_link {
__u8 phy_handle;
__u8 reason;
} __packed;
+struct ext_flow_spec {
+ __u8 id;
+ __u8 stype;
+ __le16 msdu;
+ __le32 sdu_itime;
+ __le32 acc_lat;
+ __le32 flush_to;
+} __packed;
+
+#define HCI_OP_CREATE_LOGICAL_LINK 0x0438
+#define HCI_OP_ACCEPT_LOGICAL_LINK 0x0439
+struct hci_cp_create_accept_logical_link {
+ __u8 phy_handle;
+ struct ext_flow_spec tx_flow_spec;
+ struct ext_flow_spec rx_flow_spec;
+} __packed;
+
+#define HCI_OP_DISCONN_LOGICAL_LINK 0x043a
+struct hci_cp_disconn_logical_link {
+ __le16 log_handle;
+} __packed;
+
+#define HCI_OP_LOGICAL_LINK_CANCEL 0x043b
+struct hci_cp_logical_link_cancel {
+ __u8 phy_handle;
+ __u8 flow_spec_id;
+} __packed;
+
+struct hci_rp_logical_link_cancel {
+ __u8 status;
+ __u8 phy_handle;
+ __u8 flow_spec_id;
+} __packed;
+
#define HCI_OP_SNIFF_MODE 0x0803
struct hci_cp_sniff_mode {
__le16 handle;
--
1.7.9.5
^ permalink raw reply related
* [PATCHv1 02/26] Bluetooth: trivial: Remove empty line
From: Andrei Emeltchenko @ 2012-08-17 14:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1345214001-7053-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/hci_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 28bab9d..42c00d18 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -268,7 +268,6 @@ static void hci_init_req(struct hci_dev *hdev, unsigned long opt)
BT_ERR("Unknown device type %d", hdev->dev_type);
break;
}
-
}
static void hci_le_init_req(struct hci_dev *hdev, unsigned long opt)
--
1.7.9.5
^ permalink raw reply related
* [PATCHv1 01/26] Bluetooth: debug: Print refcnt for hci_dev
From: Andrei Emeltchenko @ 2012-08-17 14:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1345214001-7053-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
include/net/bluetooth/hci_core.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 1bbc109..5354e7b 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -612,11 +612,17 @@ static inline void hci_conn_put(struct hci_conn *conn)
/* ----- HCI Devices ----- */
static inline void hci_dev_put(struct hci_dev *d)
{
+ BT_DBG("%s orig refcnt %d", d->name,
+ atomic_read(&d->dev.kobj.kref.refcount));
+
put_device(&d->dev);
}
static inline struct hci_dev *hci_dev_hold(struct hci_dev *d)
{
+ BT_DBG("%s orig refcnt %d", d->name,
+ atomic_read(&d->dev.kobj.kref.refcount));
+
get_device(&d->dev);
return d;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCHv1 00/26] Bluetooth: Create AMP physical link
From: Andrei Emeltchenko @ 2012-08-17 14:32 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1340981212-21709-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
This set of patches enhances A2MP protocol and creates physical
link between AMP controllers. This is further iteration towards
Bluetooth High Speed.
Changes:
* p1: Fixed locking issues, added basic logical link preparation.
* v3: Remove workqueue from callback processing; change callback functions
names according to reviewers recommendations; create global amp_mgr_list to
have lookup to amp manager, physical and logical links so for those HCI events
which might be identified by __handler__ we have lookup; remove extensive
hexdump from gen_amp_key.
* v2: Fix typos and bugs, add functionality: now physical connection
might be established.
* v1: Fix typos, change debug prints, refactor code for better
splitting functionality.
Andrei Emeltchenko (25):
Bluetooth: debug: Print refcnt for hci_dev
Bluetooth: trivial: Remove empty line
Bluetooth: Add HCI logical link cmds definitions
Bluetooth: General HCI callback implementation
Bluetooth: Add callback clear to ops->teardown
Bluetooth: AMP: Use HCI callback for Read AMP Info
Bluetooth: AMP: Use HCI callback to Read Loc AMP Assoc
Bluetooth: A2MP: Process Discover Response
Bluetooth: AMP: Physical link struct definitions
Bluetooth: AMP: Remote AMP ctrl definitions
Bluetooth: AMP: Use phylink in create/disc phylink req
Bluetooth: A2MP: Process A2MP Getinfo Rsp
Bluetooth: A2MP: Process A2MP Get AMP Assoc Rsp
Bluetooth: A2MP: Create A2MP workqueue
Bluetooth: Choose connection based on capabilities
Bluetooth: AMP: Add AMP key calculation
Bluetooth: AMP: Create Physical Link
Bluetooth: AMP: Write remote AMP Assoc
Bluetooth: A2MP: Add fallback to normal l2cap init sequence
Bluetooth: A2MP: Create amp_mgr global list
Bluetooth: AMP: Process Chan Selected event
Bluetooth: AMP: Process physical link complete event
Bluetooth: AMP: Send Create Chan Req
Bluetooth: Set Exended Flowspec flag for HS chan
Bluetooth: Add logical link create function
Dmitry Kasatkin (1):
Bluetooth: Add function to derive AMP key using hmac
include/net/bluetooth/a2mp.h | 16 ++
include/net/bluetooth/amp.h | 28 +++
include/net/bluetooth/hci.h | 39 ++++-
include/net/bluetooth/hci_core.h | 48 ++++++
include/net/bluetooth/l2cap.h | 3 +
include/net/bluetooth/pal.h | 58 +++++++
net/bluetooth/Kconfig | 1 +
net/bluetooth/Makefile | 2 +-
net/bluetooth/a2mp.c | 346 +++++++++++++++++++++++++++++++++++---
net/bluetooth/amp.c | 339 +++++++++++++++++++++++++++++++++++++
net/bluetooth/hci_core.c | 106 +++++++++++-
net/bluetooth/hci_event.c | 166 +++++++++++++++++-
net/bluetooth/l2cap_core.c | 75 ++++++++-
net/bluetooth/pal.c | 330 ++++++++++++++++++++++++++++++++++++
14 files changed, 1526 insertions(+), 31 deletions(-)
create mode 100644 include/net/bluetooth/amp.h
create mode 100644 include/net/bluetooth/pal.h
create mode 100644 net/bluetooth/amp.c
create mode 100644 net/bluetooth/pal.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH BlueZ v1 00/10] GATT Plugin
From: Claudio Takahasi @ 2012-08-17 14:04 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <20120817082916.GB31481@x220>
Hi Johan,
On Fri, Aug 17, 2012 at 5:29 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Thu, Aug 16, 2012, Claudio Takahasi wrote:
>> This patch series adds a new GATT based plugin for GAP and GATT service.
>> The objective is cleanup: moving some GATT related operations from the
>> device(core) to a GATT based plugin.
>>
>> This first part is related to GAP appearance characteristic. A second
>> patch will be sent soon to manage Service Changed and GATT/ATT MTU.
>>
>> Claudio Takahasi (10):
>> gatt: Add Generic Access/Attribute Profile plugin
>> gatt: Add GAP/GATT device registration
>> gatt: Add read Appearance characteristic
>> gatt: Add storing Appearance
>> core: Remove Appearance characteristic read
>> gatt: Emit PropertyChanged for Appearance
>> core: PropertyChanged signal for Icon/class
>> core: PropertyChanged signal for Icon/Appearance
>> gatt: Map Appearance value 0x0000 to "unknown"
>> gatt: Don't store Appearance if value is "unknown"
>>
>> Makefile.am | 8 ++-
>> profiles/gatt/gas.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++
>> profiles/gatt/gas.h | 25 +++++++
>> profiles/gatt/main.c | 52 ++++++++++++++
>> profiles/gatt/manager.c | 82 +++++++++++++++++++++
>> profiles/gatt/manager.h | 24 ++++++
>> src/dbus-common.c | 2 +
>> src/device.c | 74 +++++--------------
>> src/device.h | 1 +
>> 9 files changed, 390 insertions(+), 57 deletions(-)
>> create mode 100644 profiles/gatt/gas.c
>> create mode 100644 profiles/gatt/gas.h
>> create mode 100644 profiles/gatt/main.c
>> create mode 100644 profiles/gatt/manager.c
>> create mode 100644 profiles/gatt/manager.h
>
> Besides the one comment I already sent about this patch set it looks
> more or less ok to me. Would it also make sense to move the server-side
> GAP functionality into this plugin?
>
> Johan
Probably yes. If we don't find impediments we will send patches to
move this code.
BR,
Claudio
^ permalink raw reply
* Re: [PATCH BlueZ v1 04/10] gatt: Add storing Appearance
From: Claudio Takahasi @ 2012-08-17 14:00 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <20120817082830.GA31481@x220>
Hi Johan:
On Fri, Aug 17, 2012 at 5:28 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Thu, Aug 16, 2012, Claudio Takahasi wrote:
>> This patch stores the Appearance characteristic value read from the
>> remote GAP service.
>> ---
>> profiles/gatt/gas.c | 8 ++++++++
>> 1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/profiles/gatt/gas.c b/profiles/gatt/gas.c
>> index 2fb12ce..bf603e8 100644
>> --- a/profiles/gatt/gas.c
>> +++ b/profiles/gatt/gas.c
>> @@ -68,8 +68,11 @@ static gint cmp_device(gconstpointer a, gconstpointer b)
>> static void gap_appearance_cb(guint8 status, const guint8 *pdu, guint16 plen,
>> gpointer user_data)
>> {
>> + struct gas *gas = user_data;
>> struct att_data_list *list = NULL;
>> + bdaddr_t src, dst;
>> uint16_t app;
>> + uint8_t type;
>> uint8_t *atval;
>>
>> if (status != 0) {
>> @@ -92,6 +95,11 @@ static void gap_appearance_cb(guint8 status, const guint8 *pdu, guint16 plen,
>>
>> DBG("GAP Appearance: 0x%04x", app);
>>
>> + adapter_get_address(device_get_adapter(gas->device), &src);
>> + device_get_address(gas->device, &dst, &type);
>> +
>> + write_remote_appearance(&src, &dst, type, app);
>
> I'm not so sure it's a good idea to have plugins use the storage
> functions directly. Instead I'd put this into the device_set_appearance
> function which you add later in this patch set. If there really is a
> need to access storage functions from within plugins (which there isn't
> for this particular case) then we need to prefix all of the storage
> functions with btd_* since those are the only types of symbols that
> should be exported from the core daemon to plugins.
>
> Johan
ok. Wait for a new patch series, write_remote_appearance call will be
moved to device_set_appearance.
BR,
Claudio
^ permalink raw reply
* Re: [PATCH obexd] MAP: Fix invalid oflag check
From: Luiz Augusto von Dentz @ 2012-08-17 13:49 UTC (permalink / raw)
To: Sunil Kumar Behera; +Cc: linux-bluetooth
In-Reply-To: <1345196026-6873-1-git-send-email-sunil.behera@samsung.com>
Hi Sunil,
On Fri, Aug 17, 2012 at 12:33 PM, Sunil Kumar Behera
<sunil.behera@samsung.com> wrote:
> Change logic to check for O_WRONLY, as oflag is
> created by an OR operation of O_WRONLY, O_CREAT and
> O_TRUNC.
> Message update is a PUT function, this check returns
> bad response if GET is received.
> ---
> plugins/mas.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/plugins/mas.c b/plugins/mas.c
> index 30e529f..57d9611 100644
> --- a/plugins/mas.c
> +++ b/plugins/mas.c
> @@ -632,7 +632,7 @@ static void *message_update_open(const char *name, int oflag, mode_t mode,
>
> DBG("");
>
> - if (oflag != O_WRONLY) {
> + if (oflag == O_RDONLY) {
> *err = -EBADR;
> return NULL;
> }
> --
> 1.7.9.5
Pushed upstream, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCHv2 hcidump 2/2] l2cap: clean l2cap chan create/move dump
From: Andrei Emeltchenko @ 2012-08-17 13:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1345211179-3761-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Print psm as hex, add "chan" to create, move req/rsp.
---
parser/l2cap.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/parser/l2cap.c b/parser/l2cap.c
index 8dc825b..45968e8 100644
--- a/parser/l2cap.c
+++ b/parser/l2cap.c
@@ -972,7 +972,8 @@ static inline void create_req(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
if (p_filter(FILT_L2CAP))
return;
- printf("Create req: psm %d scid 0x%4.4x id %d\n", psm, scid, h->id);
+ printf("Create chan req: psm 0x%4.4x scid 0x%4.4x ctrl id %d\n",
+ psm, scid, h->id);
}
static inline void create_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
@@ -986,7 +987,8 @@ static inline void create_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
if (p_filter(FILT_L2CAP))
return;
- printf("Create rsp: dcid 0x%4.4x scid 0x%4.4x result %d status %d\n", dcid, scid, result, status);
+ printf("Create chan rsp: dcid 0x%4.4x scid 0x%4.4x result %d status %d\n",
+ dcid, scid, result, status);
}
static inline void move_req(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
@@ -997,7 +999,7 @@ static inline void move_req(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
if (p_filter(FILT_L2CAP))
return;
- printf("Move req: icid 0x%4.4x id %d\n", icid, h->id);
+ printf("Move chan req: icid 0x%4.4x ctrl id %d\n", icid, h->id);
}
static inline void move_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
@@ -1009,7 +1011,7 @@ static inline void move_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
if (p_filter(FILT_L2CAP))
return;
- printf("Move rsp: icid 0x%4.4x result %d\n", icid, result);
+ printf("Move chan rsp: icid 0x%4.4x result %d\n", icid, result);
}
static inline void move_cfm(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
@@ -1021,7 +1023,7 @@ static inline void move_cfm(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
if (p_filter(FILT_L2CAP))
return;
- printf("Move cfm: icid 0x%4.4x result %d\n", icid, result);
+ printf("Move chan cfm: icid 0x%4.4x result %d\n", icid, result);
}
static inline void move_cfm_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm)
@@ -1032,7 +1034,7 @@ static inline void move_cfm_rsp(int level, l2cap_cmd_hdr *cmd, struct frame *frm
if (p_filter(FILT_L2CAP))
return;
- printf("Move cfm rsp: icid 0x%4.4x\n", icid);
+ printf("Move chan cfm rsp: icid 0x%4.4x\n", icid);
}
static inline void a2mp_command_rej(int level, struct frame *frm)
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 hcidump 1/2] amp: Fix printing link handle
From: Andrei Emeltchenko @ 2012-08-17 13:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1342782918-4224-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Print logical link handle as 0x%4.4x and physical link handle
as 0x%2.2x
---
parser/hci.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/parser/hci.c b/parser/hci.c
index 920b973..115cf1e 100644
--- a/parser/hci.c
+++ b/parser/hci.c
@@ -1128,7 +1128,7 @@ static inline void create_physical_link_dump(int level, struct frame *frm)
int i;
p_indent(level, frm);
- printf("handle %d key length %d key type %d\n",
+ printf("phy handle 0x%2.2x key length %d key type %d\n",
cp->handle, cp->key_length, cp->key_type);
p_indent(level, frm);
printf("key ");
@@ -1143,7 +1143,7 @@ static inline void create_logical_link_dump(int level, struct frame *frm)
int i;
p_indent(level, frm);
- printf("handle %d\n", cp->handle);
+ printf("phy handle 0x%2.2x\n", cp->handle);
p_indent(level, frm);
printf("tx_flow ");
@@ -3317,7 +3317,7 @@ static inline void flow_spec_complete_dump(int level, struct frame *frm)
evt_flow_spec_complete *evt = frm->ptr;
p_indent(level, frm);
- printf("status 0x%2.2x handle %d flags %d %s\n",
+ printf("status 0x%2.2x handle 0x%4.4x flags %d %s\n",
evt->status, btohs(evt->handle), evt->flags,
evt->direction == 0 ? "outgoing" : "incoming");
@@ -3650,7 +3650,7 @@ static inline void phys_link_complete_dump(int level, struct frame *frm)
evt_physical_link_complete *evt = frm->ptr;
p_indent(level, frm);
- printf("status 0x%2.2x handle %d\n", evt->status, evt->handle);
+ printf("status 0x%2.2x phy handle 0x%2.2x\n", evt->status, evt->handle);
if (evt->status > 0) {
p_indent(level, frm);
@@ -3663,7 +3663,7 @@ static inline void disconn_phys_link_complete_dump(int level, struct frame *frm)
evt_disconn_physical_link_complete *evt = frm->ptr;
p_indent(level, frm);
- printf("status 0x%2.2x handle %d reason 0x%2.2x\n",
+ printf("status 0x%2.2x handle 0x%2.2x reason 0x%2.2x\n",
evt->status, evt->handle, evt->reason);
if (evt->status > 0) {
@@ -3680,7 +3680,7 @@ static inline void phys_link_loss_warning_dump(int level, struct frame *frm)
evt_physical_link_loss_warning *evt = frm->ptr;
p_indent(level, frm);
- printf("handle %d reason 0x%2.2x\n", evt->handle, evt->reason);
+ printf("phy handle 0x%2.2x reason 0x%2.2x\n", evt->handle, evt->reason);
}
static inline void phys_link_handle_dump(int level, struct frame *frm)
@@ -3688,7 +3688,7 @@ static inline void phys_link_handle_dump(int level, struct frame *frm)
evt_physical_link_recovery *evt = frm->ptr;
p_indent(level, frm);
- printf("handle %d\n", evt->handle);
+ printf("phy handle 0x%2.2x\n", evt->handle);
}
static inline void logical_link_complete_dump(int level, struct frame *frm)
@@ -3696,7 +3696,8 @@ static inline void logical_link_complete_dump(int level, struct frame *frm)
evt_logical_link_complete *evt = frm->ptr;
p_indent(level, frm);
- printf("status 0x%2.2x log_handle %d handle %d tx_flow_id %d\n",
+ printf("status 0x%2.2x log handle 0x%4.4x phy handle 0x%2.2x"
+ " tx_flow_id %d\n",
evt->status, btohs(evt->log_handle), evt->handle,
evt->tx_flow_id);
@@ -3711,7 +3712,8 @@ static inline void flow_spec_modify_dump(int level, struct frame *frm)
evt_flow_spec_modify_complete *evt = frm->ptr;
p_indent(level, frm);
- printf("status 0x%2.2x handle %d\n", evt->status, btohs(evt->handle));
+ printf("status 0x%2.2x handle 0x%4.4x\n",
+ evt->status, btohs(evt->handle));
if (evt->status > 0) {
p_indent(level, frm);
--
1.7.9.5
^ permalink raw reply related
* Setting up an A2DP server
From: Niklas Claesson @ 2012-08-17 11:30 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I would like to use a computer as an A2DP sink (bluetooth devices
should be able to play through the computers speakers). So far I can
manually connect from the computer using dbus signals with bluez/pulse
(org.bluez.AudioSource). But what I really want is for the external
device to connect to my service. The goal is to let anyone with
bluetooth play music in our common space at the university.
What would be the most straight forward way to implement this?
Med vänliga hälsningar
Niklas Claesson
^ permalink raw reply
* Re: BLE - multiple connections
From: Anderson Lizardo @ 2012-08-17 10:57 UTC (permalink / raw)
To: Ajay KV; +Cc: Andre Guedes, linux-bluetooth
In-Reply-To: <502E56DF.3020103@globaledgesoft.com>
Hi,
On Fri, Aug 17, 2012 at 10:36 AM, Ajay KV <ajay.kv@globaledgesoft.com> wrote:
> 1: suppose device A and B is in connected state (B as initiator and A as
> advertising mode) , so obviously role change happens and A switches to
> slave mode . meanwhile i wanted to connect device C to A (C as initiator
> and A as advertising mode) , since A has switched to slave mode , it cant
> able to advertise again ( controller returns error message " command
> disallowed") . Even i tried to change the role forcefully through hcitool
> command , the result was same.
> My intention is to make the device A as a server with multiple
> clients. Currently im not using any of the profiles(ATT , GATT) . i want
> it to be done using L2CAP sockets
You need to check if your controller supports the LE state
combinations you are trying to use. Run "hciconfig hci0 lestates" And
check the supported states. Also see Core Spec v4.0 page 1096 for more
details.
Some controllers don't support LE scanning and LE advertising at the
same time, so make sure you don't have LE scanning enabled in "A"
while trying to re-enable advertising.
> 2. Is it possible to change the imtu of the LE connection other than
> 23bits( which is hardcoded in L2cap driver)
I think this was fixed on more recent kernel releases. See patches
from Andre Guedes around May 31st (which are already upstream).
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH obexd] MAP: Fix invalid oflag check
From: Sunil Kumar Behera @ 2012-08-17 9:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sunil Kumar Behera
Change logic to check for O_WRONLY, as oflag is
created by an OR operation of O_WRONLY, O_CREAT and
O_TRUNC.
Message update is a PUT function, this check returns
bad response if GET is received.
---
plugins/mas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/plugins/mas.c b/plugins/mas.c
index 30e529f..57d9611 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -632,7 +632,7 @@ static void *message_update_open(const char *name, int oflag, mode_t mode,
DBG("");
- if (oflag != O_WRONLY) {
+ if (oflag == O_RDONLY) {
*err = -EBADR;
return NULL;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC v3] mgmt-api: Add reason to device disconnect event
From: Johan Hedberg @ 2012-08-17 9:27 UTC (permalink / raw)
To: Mikel Astiz; +Cc: linux-bluetooth, Mikel Astiz
In-Reply-To: <1345194655-8453-1-git-send-email-mikel.astiz.oss@gmail.com>
Hi Mikel,
On Fri, Aug 17, 2012, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>
> Extend the management API with the disconnect reason, as now reported
> by the Kernel in MGMT_EV_DEVICE_DISCONNECTED.
> ---
> v3 integrates the changes suggested by Johan with the exception of the type change between uint16_t and size_t in mgmt_device_disconnected().
>
> doc/mgmt-api.txt | 16 ++++++++++++++++
> lib/mgmt.h | 6 ++++++
> monitor/control.c | 19 +++++++++++++++----
> src/mgmt.c | 16 +++++++++++-----
> tools/btmgmt.c | 18 +++++++++++++-----
> 5 files changed, 61 insertions(+), 14 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* [RFC v3] mgmt-api: Add reason to device disconnect event
From: Mikel Astiz @ 2012-08-17 9:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Mikel Astiz
From: Mikel Astiz <mikel.astiz@bmw-carit.de>
Extend the management API with the disconnect reason, as now reported
by the Kernel in MGMT_EV_DEVICE_DISCONNECTED.
---
v3 integrates the changes suggested by Johan with the exception of the type change between uint16_t and size_t in mgmt_device_disconnected().
doc/mgmt-api.txt | 16 ++++++++++++++++
lib/mgmt.h | 6 ++++++
monitor/control.c | 19 +++++++++++++++----
src/mgmt.c | 16 +++++++++++-----
tools/btmgmt.c | 18 +++++++++++++-----
5 files changed, 61 insertions(+), 14 deletions(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 51c9b46..c25f377 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -973,12 +973,28 @@ Event Code 0x000C
Controller Index: <controller id>
Event Parameters Address (6 Octets)
Address_Type (1 Octet)
+ Reason (1 Octet)
Possible values for the Address_Type parameter:
0 BR/EDR
1 LE Public
2 LE Random
+ Possible values for the Reason parameter:
+ 0 Unspecified
+ 1 Connection timeout
+ 2 Connection terminated by local host
+ 3 Connection terminated by remote host
+
+ Note that the local/remote distinction just determines which side
+ terminated the low-level connection, regardless of the
+ disconnection of the higher-level profiles.
+
+ This can sometimes be misleading and thus must be used with care.
+ For example, some hardware combinations would report a locally
+ initiated disconnection even if the user turned Bluetooth off in
+ the remote side.
+
Connect Failed Event
====================
diff --git a/lib/mgmt.h b/lib/mgmt.h
index 83dcd84..a2648bc 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -373,9 +373,15 @@ struct mgmt_ev_device_connected {
uint8_t eir[0];
} __packed;
+#define MGMT_DEV_DISCONN_UNKNOWN 0x00
+#define MGMT_DEV_DISCONN_TIMEOUT 0x01
+#define MGMT_DEV_DISCONN_LOCAL_HOST 0x02
+#define MGMT_DEV_DISCONN_REMOTE 0x03
+
#define MGMT_EV_DEVICE_DISCONNECTED 0x000C
struct mgmt_ev_device_disconnected {
struct mgmt_addr_info addr;
+ uint8_t reason;
} __packed;
#define MGMT_EV_CONNECT_FAILED 0x000D
diff --git a/monitor/control.c b/monitor/control.c
index 3f5b990..c300ae9 100644
--- a/monitor/control.c
+++ b/monitor/control.c
@@ -226,18 +226,29 @@ static void mgmt_device_disconnected(uint16_t len, const void *buf)
{
const struct mgmt_ev_device_disconnected *ev = buf;
char str[18];
+ uint8_t reason;
+ uint16_t consumed_len;
- if (len < sizeof(*ev)) {
+ if (len < sizeof(struct mgmt_addr_info)) {
printf("* Malformed Device Disconnected control\n");
return;
}
+ if (len < sizeof(*ev)) {
+ reason = MGMT_DEV_DISCONN_UNKNOWN;
+ consumed_len = len;
+ } else {
+ reason = ev->reason;
+ consumed_len = sizeof(*ev);
+ }
+
ba2str(&ev->addr.bdaddr, str);
- printf("@ Device Disconnected: %s (%d)\n", str, ev->addr.type);
+ printf("@ Device Disconnected: %s (%d) reason %u\n", str, ev->addr.type,
+ reason);
- buf += sizeof(*ev);
- len -= sizeof(*ev);
+ buf += consumed_len;
+ len -= consumed_len;
packet_hexdump(buf, len);
}
diff --git a/src/mgmt.c b/src/mgmt.c
index 94b2a04..58aab2d 100644
--- a/src/mgmt.c
+++ b/src/mgmt.c
@@ -510,18 +510,24 @@ static void mgmt_device_connected(int sk, uint16_t index, void *buf, size_t len)
static void mgmt_device_disconnected(int sk, uint16_t index, void *buf,
size_t len)
{
- struct mgmt_addr_info *ev = buf;
+ struct mgmt_ev_device_disconnected *ev = buf;
struct controller_info *info;
char addr[18];
+ uint8_t reason;
- if (len < sizeof(*ev)) {
+ if (len < sizeof(struct mgmt_addr_info)) {
error("Too small device_disconnected event");
return;
}
- ba2str(&ev->bdaddr, addr);
+ if (len < sizeof(*ev))
+ reason = MGMT_DEV_DISCONN_UNKNOWN;
+ else
+ reason = ev->reason;
+
+ ba2str(&ev->addr.bdaddr, addr);
- DBG("hci%u device %s disconnected", index, addr);
+ DBG("hci%u device %s disconnected reason %u", index, addr, reason);
if (index > max_index) {
error("Unexpected index %u in device_disconnected event", index);
@@ -530,7 +536,7 @@ static void mgmt_device_disconnected(int sk, uint16_t index, void *buf,
info = &controllers[index];
- btd_event_disconn_complete(&info->bdaddr, &ev->bdaddr);
+ btd_event_disconn_complete(&info->bdaddr, &ev->addr.bdaddr);
}
static void mgmt_connect_failed(int sk, uint16_t index, void *buf, size_t len)
diff --git a/tools/btmgmt.c b/tools/btmgmt.c
index c6d48d3..f06f0bf 100644
--- a/tools/btmgmt.c
+++ b/tools/btmgmt.c
@@ -343,9 +343,10 @@ static int mgmt_connected(int mgmt_sk, uint16_t index,
}
static int mgmt_disconnected(int mgmt_sk, uint16_t index,
- struct mgmt_addr_info *ev, uint16_t len)
+ struct mgmt_ev_device_disconnected *ev,
+ uint16_t len)
{
- if (len != sizeof(*ev)) {
+ if (len < sizeof(struct mgmt_addr_info)) {
fprintf(stderr,
"Invalid disconnected event length (%u bytes)\n", len);
return -EINVAL;
@@ -353,9 +354,16 @@ static int mgmt_disconnected(int mgmt_sk, uint16_t index,
if (monitor) {
char addr[18];
- ba2str(&ev->bdaddr, addr);
- printf("hci%u %s type %s disconnected\n", index, addr,
- typestr(ev->type));
+ uint8_t reason;
+
+ if (len < sizeof(*ev))
+ reason = MGMT_DEV_DISCONN_UNKNOWN;
+ else
+ reason = ev->reason;
+
+ ba2str(&ev->addr.bdaddr, addr);
+ printf("hci%u %s type %s disconnected with reason %u\n",
+ index, addr, typestr(ev->addr.type), reason);
}
return 0;
--
1.7.7.6
^ permalink raw reply related
* Re: [RFC BlueZ v2] mgmt-api: Add reason to device disconnect event
From: Mikel Astiz @ 2012-08-17 9:07 UTC (permalink / raw)
To: linux-bluetooth, Mikel Astiz
In-Reply-To: <20120816122510.GA23760@x220>
Hi Johan,
On Thu, Aug 16, 2012 at 2:25 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Mikel,
>
> On Thu, Aug 09, 2012, Mikel Astiz wrote:
>> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>>
>> Extend the management API with the disconnect reason, as now reported
>> by the Kernel in MGMT_EV_DEVICE_DISCONNECTED.
>> ---
>> Updated userland patch to test the recently submitted Kernel patches regarding ACL disconnect reason.
>>
>> doc/mgmt-api.txt | 16 ++++++++++++++++
>> lib/mgmt.h | 6 ++++++
>> monitor/control.c | 19 +++++++++++++++----
>> src/mgmt.c | 13 ++++++++-----
>> 4 files changed, 45 insertions(+), 9 deletions(-)
>
> Seems like you're missing an update to tools/btmgmt.c?
Indeed. I will integrate the changes in the next version of the patch.
>> --- a/monitor/control.c
>> +++ b/monitor/control.c
>> @@ -226,18 +226,29 @@ static void mgmt_device_disconnected(uint16_t len, const void *buf)
>> {
>> const struct mgmt_ev_device_disconnected *ev = buf;
>> char str[18];
>> + uint8_t reason;
>> + uint16_t l;
>
> I suppose size_t would be more appropriate instead of uint16_t as that's
> the return type of sizeof(). The variable name is also a bit
> uninformative and I'd have used something like consumed_len or
> parsed_len, but if this the convention in rest of the btmon code then I
> wont object to it.
I will rename the variable to consumed_len but I would rather leave it
as uint16_t in order to match the type of len.
>> --- a/src/mgmt.c
>> +++ b/src/mgmt.c
>> @@ -510,18 +510,21 @@ static void mgmt_device_connected(int sk, uint16_t index, void *buf, size_t len)
>> static void mgmt_device_disconnected(int sk, uint16_t index, void *buf,
>> size_t len)
>> {
>> - struct mgmt_addr_info *ev = buf;
>> + struct mgmt_ev_device_disconnected *ev = buf;
>> struct controller_info *info;
>> char addr[18];
>>
>> - if (len < sizeof(*ev)) {
>> + if (len < sizeof(struct mgmt_addr_info)) {
>> error("Too small device_disconnected event");
>> return;
>> }
>>
>> - ba2str(&ev->bdaddr, addr);
>> + if (len < sizeof(*ev))
>> + memset((char *) buf + len, 0, sizeof(*ev) - len);
>
> I don't like how this assumes that there is usable space after the end
> of the buffer given to this function. Could you instead use a temporary
> "uint8_t reason" variable like you do for btmon?
I will change this one too.
Cheers,
Mikel
^ permalink raw reply
* obexd client API
From: Patrick Ohly @ 2012-08-17 9:06 UTC (permalink / raw)
To: Bluez; +Cc: Mikel Astiz, Von Dentz, Luiz
Hello all!
Luiz was so kind to discuss the client-api.txt in obexd 0.47 with me, in
particular the usage of temporary files and the Transfer objects. The
goal was to understand how to use that API correctly, so that race
conditions are avoided and errors are handled gracefully. This is
relevant for others, so let me summarize here.
Some relevant aspects of the API are not documented at the moment:
1. The Transfer objects only exist as long as the transfer is still
active.
2. When a transfer fails before the data was transferred
completely, the temporary file gets deleted by obexd. I am still
a bit fuzzy whether that is the case for file names chosen by
the client and for those chosen by obexd.
3. When a client disconnects, obexd aborts the transfer and thus
deletes an incomplete temporary file.
Because of point 1, a client has to listen to org.bluez.obex.Transfer
signals for all object paths and record that information. Otherwise
there is the following race condition:
1. The client asks for a transfer.
2. obexd replies with "transfer in progress" and the Transfer
object path.
3. Before the client gets a chance register a signal watch for that
path, obexd sends the Complete() signal and destroys the object.
4. If the client now waits for the signals of the object, it will
wait forever.
To avoid this, the client could explicitly check properties of the
Transfer object. If it gets an error, it can conclude that the transfer
is no longer active. If the file still exists, the transfer must have
succeeded. But if it does not exist, the client doesn't know why the
transfer failed. I also find this kind of checking very speculative. The
error that the client gets for an invalid object path is undocumented.
For example, I believe I have seen errors about "interface not found"
instead of "object not found" (not necessarily in obexd).
A client developer could also decide that this race condition is
unlikely to happen and thus decide to not handle it; I find that a bit
risky.
I'm not sure whether it's worth changing the API. If yes, then how about
extending the life time of the Transfer object? obexd could keep it
alive until either the client quits or explicitly deletes the Transfer
object via a new method call. Then a client can (in this order)
subscribe to signals and query current properties of the object once to
detect state changes that it has missed.
Regarding the temporary files my main concern was about orphaned files
that no-one owns anymore. Here's one error scenario:
1. The client requests a transfer into "foo".
2. obexd finishes the transfer.
3. The client dies before doing anything with the file.
To handle this, the client must ensure that there is some kind of
garbage collection for "foo" (when it is temporary) or that it is okay
to leave the file around (because the user expects that).
Again I can imagine refinements of the API that would help address some
of the concerns (like an explicit transfer of ownership), but short of
transferring file descriptors for files which were already unlinked
there are always error cases left which will leave files around (both
client and obexd might die).
As Luiz explained, using file descriptors was already discussed and
rejected for good reasons, so let's not reopen the discussion.
Would it be useful to extend the API specification with "how to use"
remarks so that users of it don't have to search the mailing list?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
^ permalink raw reply
* Re: [PATCH BlueZ v1 00/10] GATT Plugin
From: Johan Hedberg @ 2012-08-17 8:29 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1345147991-31320-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Aug 16, 2012, Claudio Takahasi wrote:
> This patch series adds a new GATT based plugin for GAP and GATT service.
> The objective is cleanup: moving some GATT related operations from the
> device(core) to a GATT based plugin.
>
> This first part is related to GAP appearance characteristic. A second
> patch will be sent soon to manage Service Changed and GATT/ATT MTU.
>
> Claudio Takahasi (10):
> gatt: Add Generic Access/Attribute Profile plugin
> gatt: Add GAP/GATT device registration
> gatt: Add read Appearance characteristic
> gatt: Add storing Appearance
> core: Remove Appearance characteristic read
> gatt: Emit PropertyChanged for Appearance
> core: PropertyChanged signal for Icon/class
> core: PropertyChanged signal for Icon/Appearance
> gatt: Map Appearance value 0x0000 to "unknown"
> gatt: Don't store Appearance if value is "unknown"
>
> Makefile.am | 8 ++-
> profiles/gatt/gas.c | 179 +++++++++++++++++++++++++++++++++++++++++++++++
> profiles/gatt/gas.h | 25 +++++++
> profiles/gatt/main.c | 52 ++++++++++++++
> profiles/gatt/manager.c | 82 +++++++++++++++++++++
> profiles/gatt/manager.h | 24 ++++++
> src/dbus-common.c | 2 +
> src/device.c | 74 +++++--------------
> src/device.h | 1 +
> 9 files changed, 390 insertions(+), 57 deletions(-)
> create mode 100644 profiles/gatt/gas.c
> create mode 100644 profiles/gatt/gas.h
> create mode 100644 profiles/gatt/main.c
> create mode 100644 profiles/gatt/manager.c
> create mode 100644 profiles/gatt/manager.h
Besides the one comment I already sent about this patch set it looks
more or less ok to me. Would it also make sense to move the server-side
GAP functionality into this plugin?
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v1 04/10] gatt: Add storing Appearance
From: Johan Hedberg @ 2012-08-17 8:28 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1345147991-31320-5-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Aug 16, 2012, Claudio Takahasi wrote:
> This patch stores the Appearance characteristic value read from the
> remote GAP service.
> ---
> profiles/gatt/gas.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/profiles/gatt/gas.c b/profiles/gatt/gas.c
> index 2fb12ce..bf603e8 100644
> --- a/profiles/gatt/gas.c
> +++ b/profiles/gatt/gas.c
> @@ -68,8 +68,11 @@ static gint cmp_device(gconstpointer a, gconstpointer b)
> static void gap_appearance_cb(guint8 status, const guint8 *pdu, guint16 plen,
> gpointer user_data)
> {
> + struct gas *gas = user_data;
> struct att_data_list *list = NULL;
> + bdaddr_t src, dst;
> uint16_t app;
> + uint8_t type;
> uint8_t *atval;
>
> if (status != 0) {
> @@ -92,6 +95,11 @@ static void gap_appearance_cb(guint8 status, const guint8 *pdu, guint16 plen,
>
> DBG("GAP Appearance: 0x%04x", app);
>
> + adapter_get_address(device_get_adapter(gas->device), &src);
> + device_get_address(gas->device, &dst, &type);
> +
> + write_remote_appearance(&src, &dst, type, app);
I'm not so sure it's a good idea to have plugins use the storage
functions directly. Instead I'd put this into the device_set_appearance
function which you add later in this patch set. If there really is a
need to access storage functions from within plugins (which there isn't
for this particular case) then we need to prefix all of the storage
functions with btd_* since those are the only types of symbols that
should be exported from the core daemon to plugins.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v3 06/14] core: mutually exclude concurrent connections
From: Johan Hedberg @ 2012-08-17 7:51 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth
In-Reply-To: <1345152524-13404-7-git-send-email-jprvita@openbossa.org>
Hi,
On Thu, Aug 16, 2012, João Paulo Rechi Vita wrote:
> @@ -133,8 +133,10 @@ struct btd_adapter {
> + GSList *connecting_list; /* Pending connects */
> + gboolean connecting; /* Connect active */
What's the relationship with the above two? Isn't connecting always true
when g_slist_length(connecting_list) > 0 and false when the list is
empty?
> static gboolean connect_pending_cb(gpointer user_data)
> {
> struct btd_device *device = user_data;
> struct btd_adapter *adapter = device_get_adapter(device);
> + GIOChannel *io;
>
> /* in the future we may want to check here if the controller supports
> * scanning and connecting at the same time */
> if (adapter->discovering)
> return TRUE;
>
> - device_att_connect(device);
> + if (adapter->connecting)
> + return TRUE;
> +
> + adapter->connecting = TRUE;
> + io = device_att_connect(device);
> + g_io_add_watch(io, G_IO_OUT | G_IO_ERR, clean_connecting_state,
> + btd_device_ref(device));
>
> return FALSE;
> }
Since you're not storing "io" after the function returns you should be
doing a g_io_channel_unref() after calling g_io_add_watch(). Looking at
device_att_connect it seems like it's missing a g_io_channel_ref (either
when assigning to device->att_io or when returning from the function).
> + adapter->connecting_list = g_slist_append(
> + adapter->connecting_list, device);
>
Missing btd_device_unref()?
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v3 04/14] core: Add a list of LE devices to connect
From: Johan Hedberg @ 2012-08-17 7:42 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth
In-Reply-To: <1345152524-13404-5-git-send-email-jprvita@openbossa.org>
Hi,
On Thu, Aug 16, 2012, João Paulo Rechi Vita wrote:
> +void adapter_connect_list_add(struct btd_adapter *adapter,
> + struct btd_device *device)
> +{
> + if (g_slist_find(adapter->connect_list, device)) {
> + DBG("trying to add device %s which is already in the connect "
> + "list, ignoring", device_get_path(device));
> + return;
> + }
If possible could you try to avoid split message strings. Since the
context (function name, line number) is anyway logged with DBG you could
just have e.g. "ignoring already added device %s"
> + adapter->connect_list = g_slist_append(adapter->connect_list, device);
Looks like there's a missing btd_device_ref here.
> +void adapter_connect_list_remove(struct btd_adapter *adapter,
> + struct btd_device *device)
> +{
> + adapter->connect_list = g_slist_remove(adapter->connect_list, device);
And a missing btd_device_unref here.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ v3 13/14] core: Disable unnecessary auto connections
From: Johan Hedberg @ 2012-08-17 7:39 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth, Paulo Alcantara
In-Reply-To: <1345152524-13404-14-git-send-email-jprvita@openbossa.org>
Hi,
On Thu, Aug 16, 2012, João Paulo Rechi Vita wrote:
> BlueZ host disconnects the link when encryption fails. ECONNABORTED
> error is returned by the kernel when the connection is terminated by the
> local host. This scenario commonly happens when authentication fails due
> PIN or Key Missing.
> ---
> src/device.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/device.c b/src/device.c
> index 645a2b7..5490e37 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -1956,6 +1956,9 @@ static void att_error_cb(const GError *gerr, gpointer user_data)
> struct att_callbacks *attcb = user_data;
> struct btd_device *device = attcb->user_data;
>
> + if (gerr->code == ECONNABORTED)
> + return;
> +
I think it'd be more appropriate to use g_error_matches() here.
Johan
^ permalink raw reply
* Re: Bluez 4.101
From: Andrei Emeltchenko @ 2012-08-17 7:07 UTC (permalink / raw)
Cc: linux-bluetooth
In-Reply-To: <CAJdJm_OgdkmcXxFh_0pA3n+-RbPkWKB4ZZrsnDyndYrSGZ=rog@mail.gmail.com>
Hi,
On Thu, Aug 16, 2012 at 11:57:46AM -0400, Anderson Lizardo wrote:
> On Thu, Aug 16, 2012 at 11:38 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
> > Hi Anderson,
> >
> > Thanks for the info.
> > May I know the difference between bluetooth.git and bluetooth-next.git repo?.
>
> I may be wrong, but I think it is like this:
>
> bluetooth-next.git contains what is going to the next kernel release
> cycle. E.g. if we are on 3.6-rc1, what is currently on bluetooth-next
BTW: Gustavo, when we rebase to 3.6-rc1 ?
Best regards
Andrei Emeltchenko
^ permalink raw reply
* [PATCH v3] Add device ID for Bluetooth on Macbook Pro 2012
From: Daniel J Blueman @ 2012-08-17 5:44 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo Padovan, Johan Hedberg, linux-bluetooth, linux-kernel,
Henrik Rydberg, Daniel J Blueman
Add the device ID for supporting the Macbook Pro 2012 'MacBookPro10,1'.
The bluetooth device presents itself as:
T: Bus=02 Lev=04 Prnt=04 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8286 Rev=00.86
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none)
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
Patch originally written and tested by clipcarl (forums.opensuse.org).
Signed-off-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Henrik Rydberg <rydberg@euromail.se>
---
drivers/bluetooth/btusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index e272214..61f4eb7 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -76,6 +76,9 @@ static struct usb_device_id btusb_table[] = {
/* Apple MacMini5,1 */
{ USB_DEVICE(0x05ac, 0x8281) },
+ /* Apple MacBookPro10,1 */
+ { USB_DEVICE(0x05ac, 0x8286) },
+
/* AVM BlueFRITZ! USB v2.0 */
{ USB_DEVICE(0x057c, 0x3800) },
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] bluetooth.h: fix compile issue when using in C++
From: W. Trevor King @ 2012-08-17 5:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Patrick Ohly, Pacho Ramos
In-Reply-To: <1330953167.3457.13.camel@pohly-mobl1.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]
On Mon, Mar 05, 2012 at 01:12:47PM -0000, Patrick Ohly wrote:
> On Mon, 2012-03-05 at 09:31 +0100, Markus Rathgeb wrote:
> > Before you are applying the patch, could you also have a look at:
> > http://permalink.gmane.org/gmane.linux.bluez.kernel/22294
>
[snip]
>
> Updated patch attached.
>
> Note that Debian seems to have picked the older
> http://marc.info/?l=linux-bluetooth&m=132644289619172&w=2 patch, the one
> which removes __attribute__((packed)) and replaces the (void *) cast
> with (struct __s *).
>
> I think that shows that it is important that upstream includes a
> solution, because otherwise distros will pick one randomly.
On Fri, Jul 27, 2012 at 12:38:53PM -0400, W. Trevor King wrote:
> This patch seems to have never made it into bluez,
[snip]
> Is there any chance of getting it accepted?
On Wed, Aug 01, 2012 at 04:41:33PM +0200, Pacho Ramos wrote:
> El dom, 29-07-2012 a las 09:52 +0200, Pacho Ramos escribió:
> > Today I got a report downstream showing that old problem:
> > http://permalink.gmane.org/gmane.linux.bluez.kernel/22306
> >
> > is still not fixed.
> >
> > Could you please commit debian patch to fix this?
> > http://patch-tracker.debian.org/patch/series/view/bluez/4.101-1/09_fix_ftbfs_with_c99.patch
>
> Any news about this? Thanks
Bump :)
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Moving bluetooth plugin to gstreamer
From: Marcel Holtmann @ 2012-08-17 3:13 UTC (permalink / raw)
To: Tim-Philipp Müller
Cc: Discussion of the development of and with GStreamer,
linux-bluetooth, Thiago Sousa Santos
In-Reply-To: <1345136955.28588.5.camel@zingle>
Hi Tim,
> > Since we now have a proper library for SBC codec
> > (http://git.kernel.org/?p=bluetooth/sbc.git;a=summary) and its patent
> > has expired June 2, 2010. (source:
> > http://en.wikipedia.org/wiki/SBC_(codec)), I wonder if it wouldn't be
> > a good idea to move the plugin to gstreamer tree?
> >
> > The plugin has the following elements:
> >
> > bluetooth: sbcenc: Bluetooth SBC encoder
> > bluetooth: sbcdec: Bluetooth SBC decoder
> > bluetooth: sbcparse: Bluetooth SBC parser
> > bluetooth: avdtpsink: Bluetooth AVDTP sink
> > bluetooth: a2dpsink: Bluetooth A2DP sink
> > bluetooth: rtpsbcpay: RTP packet payloader
>
> Sounds like a good idea to me.
>
> We'd probably add them to gst-plugins-bad first though, since that's
> where new plugins are usually added before they get moved to -good or
> elsewhere. And probably only to git master (ie. for the upcoming
> 0.11/1.0 API version).
>
> Would the idea be that you'd turn libsbc from noinst into a proper
> library, or would we just move that over into the plugin as well?
as Luiz pointed out, that has already been done. It is standalone now
with its own GIT tree and a released 1.0 tarball for distributions to
package.
Regards
Marcel
^ 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