* Re: CSP implementation for MCAP
From: Elvis Pfützenreuter @ 2010-09-02 20:36 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100902202806.GA8391@jh-x301>
On Sep 2, 2010, at 5:28 PM, Johan Hedberg wrote:
> Hi Elvis,
>
> On Thu, Sep 02, 2010, Elvis Pfützenreuter wrote:
>> This is the repository for the CSP implementation, rebased over the
>> recently accepted MCAP, for your appreciation:
>>
>> git://gitorious.org/bluez-epx/bluez-epx.git csp
>
> A couple of quick comments:
>
> - Several of the commits in the tree have the author as
> "epx <epx@xenicall.(none)>". That needs fixing.
Ouch :(
> - I'm not so happy about all the ifdefs in the code and the way that
> they are used. So this may need some rethinking. Probably we could
> have the code always compiled in and have a runtime variable to
> disable its use.
Such variable already exists, and starts turned off. So could I remove the --enable-mcap-csp flag altogether?
> Johan
^ permalink raw reply
* Re: CSP implementation for MCAP
From: Johan Hedberg @ 2010-09-02 20:28 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <4A11989E-5448-43B7-887F-217C54977E22@epx.com.br>
Hi Elvis,
On Thu, Sep 02, 2010, Elvis Pfützenreuter wrote:
> This is the repository for the CSP implementation, rebased over the
> recently accepted MCAP, for your appreciation:
>
> git://gitorious.org/bluez-epx/bluez-epx.git csp
A couple of quick comments:
- Several of the commits in the tree have the author as
"epx <epx@xenicall.(none)>". That needs fixing.
- I'm not so happy about all the ifdefs in the code and the way that
they are used. So this may need some rethinking. Probably we could
have the code always compiled in and have a runtime variable to
disable its use.
Johan
^ permalink raw reply
* Re: [PATCH] Remember fake devices for the daemon's lifetime
From: Johan Hedberg @ 2010-09-02 20:16 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development, rufferson
In-Reply-To: <1283446547.2361.68.camel@localhost.localdomain>
Hi Bastien,
On Thu, Sep 02, 2010, Bastien Nocera wrote:
> Here's a rework of Ruslan's patch. This should make PS3 BD remotes
> faster to reconnect, by not having to setup uinput every time.
Thanks. This one has also been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix MTU L2CAP configuration parameter
From: Gustavo F. Padovan @ 2010-09-02 19:49 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1283343445-9328-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-09-01 15:17:25 +0300]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> When receiving L2CAP negative configuration response with respect
> to MTU parameter we modify wrong field. MTU here means proposed
> value of MTU that the remote device intends to transmit. So for local
> L2CAP socket it is pi->imtu.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* CSP implementation for MCAP
From: Elvis Pfützenreuter @ 2010-09-02 18:58 UTC (permalink / raw)
To: johan.hedberg, linux-bluetooth
This is the repository for the CSP implementation, rebased over the recently accepted MCAP, for your appreciation:
git://gitorious.org/bluez-epx/bluez-epx.git csp
or
http://www.gitorious.org/bluez-epx/bluez-epx/commits/csp
^ permalink raw reply
* [PATCH] Remember fake devices for the daemon's lifetime
From: Bastien Nocera @ 2010-09-02 16:55 UTC (permalink / raw)
To: BlueZ development; +Cc: rufferson
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Hello,
Here's a rework of Ruslan's patch. This should make PS3 BD remotes
faster to reconnect, by not having to setup uinput every time.
Next I'll look at implementing idle for that particular remote, as well
as being able to turn it off from the remote itself.
I won't make the keymap or the idle timeout configurable as in the
original patches.
Cheers
[-- Attachment #2: 0001-Remember-fake-devices-for-the-daemon-s-lifetime.patch --]
[-- Type: text/x-patch, Size: 4084 bytes --]
>From 67177f5fc4750960dde9af9ec57f5e50f2770581 Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Thu, 2 Sep 2010 17:09:37 +0100
Subject: [PATCH] Remember fake devices for the daemon's lifetime
This would allow faster reconnection of already known devices,
so that no keypresses would be lost when reconnecting.
We only setup uinput the first time around, which will avoid
problems with devices not disappearing when disconnected.
Based on patch by Ruslan N. Marchenko <rufferson@gmail.com>
---
input/device.c | 8 ++++++--
input/device.h | 1 +
input/fakehid.c | 32 +++++++++++++++++++++++++++-----
input/fakehid.h | 3 ++-
4 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/input/device.c b/input/device.c
index 0bcbbdb..b2885c4 100644
--- a/input/device.c
+++ b/input/device.c
@@ -635,12 +635,16 @@ static int hidp_add_connection(const struct input_device *idev,
fake_hid = get_fake_hid(req->vendor, req->product);
if (fake_hid) {
+ err = 0;
fake = g_new0(struct fake_input, 1);
fake->connect = fake_hid_connect;
fake->disconnect = fake_hid_disconnect;
fake->priv = fake_hid;
- err = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
- if (err == 0)
+ fake->idev = idev;
+ fake = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
+ if (fake == NULL)
+ err = -ENOMEM;
+ else
fake->flags |= FI_FLAG_CONNECTED;
goto cleanup;
}
diff --git a/input/device.h b/input/device.h
index 3390a0b..14c0f97 100644
--- a/input/device.h
+++ b/input/device.h
@@ -39,6 +39,7 @@ struct fake_input {
gboolean (*connect) (struct input_conn *iconn, GError **err);
int (*disconnect) (struct input_conn *iconn);
void *priv;
+ const struct input_device *idev;
};
int fake_input_register(DBusConnection *conn, struct btd_device *device,
diff --git a/input/fakehid.c b/input/fakehid.c
index ee1f77a..6346a3e 100644
--- a/input/fakehid.c
+++ b/input/fakehid.c
@@ -348,6 +348,7 @@ static struct fake_hid fake_hid_table[] = {
.disconnect = fake_hid_common_disconnect,
.event = ps3remote_event,
.setup_uinput = ps3remote_setup_uinput,
+ .devices = NULL,
},
{ },
@@ -370,12 +371,33 @@ struct fake_hid *get_fake_hid(uint16_t vendor, uint16_t product)
return NULL;
}
-int fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
+struct fake_input *fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
struct fake_hid *fake_hid)
{
- if (fake_hid->setup_uinput(fake, fake_hid)) {
- error("Error setting up uinput");
- return ENOMEM;
+ GList *l;
+ struct fake_input *old = NULL;
+
+ /* Look for an already setup device */
+ for (l = fake_hid->devices; l != NULL; l = l->next) {
+ old = l->data;
+ if (old->idev == fake->idev) {
+ g_free (fake);
+ fake = old;
+ fake_hid->connect(fake, NULL);
+ break;
+ }
+ old = NULL;
+ }
+
+ /* New device? Add it to the list of known devices,
+ * and create the uinput necessary */
+ if (old == NULL) {
+ if (fake_hid->setup_uinput(fake, fake_hid)) {
+ error("Error setting up uinput");
+ g_free(fake);
+ return NULL;
+ }
+ fake_hid->devices = g_list_append(fake_hid->devices, fake);
}
fake->io = g_io_channel_ref(intr_io);
@@ -383,5 +405,5 @@ int fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
g_io_add_watch(fake->io, G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
(GIOFunc) fake_hid->event, fake);
- return 0;
+ return fake;
}
diff --git a/input/fakehid.h b/input/fakehid.h
index 33b1e70..3a5d7c4 100644
--- a/input/fakehid.h
+++ b/input/fakehid.h
@@ -31,9 +31,10 @@ struct fake_hid {
int (*disconnect) (struct fake_input *fake_input);
gboolean (*event) (GIOChannel *chan, GIOCondition cond, gpointer data);
int (*setup_uinput) (struct fake_input *fake, struct fake_hid *fake_hid);
+ GList *devices;
};
struct fake_hid *get_fake_hid(uint16_t vendor, uint16_t product);
-int fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
+struct fake_input *fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
struct fake_hid *fake_hid);
--
1.7.0.1
^ permalink raw reply related
* Re: [PATCH] Fix Connected status when PS3 BD remote connects
From: Johan Hedberg @ 2010-09-02 16:09 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1283443172.2361.63.camel@localhost.localdomain>
Hi Bastien,
On Thu, Sep 02, 2010, Bastien Nocera wrote:
> This fixes a problem where the BD remote didn't appear as connected even
> though it was.
Thanks! The patch is now in the upstream tree.
Johan
^ permalink raw reply
* [PATCH] Fix Connected status when PS3 BD remote connects
From: Bastien Nocera @ 2010-09-02 15:59 UTC (permalink / raw)
To: BlueZ development
[-- Attachment #1: Type: text/plain, Size: 102 bytes --]
Hey,
This fixes a problem where the BD remote didn't appear as connected even
though it was.
Cheers
[-- Attachment #2: 0001-Fix-Connected-status-when-PS3-BD-remote-connects.patch --]
[-- Type: text/x-patch, Size: 1009 bytes --]
>From 5e636f5633c1af92880a249b50bf60f78a4350bb Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Thu, 2 Sep 2010 16:55:30 +0100
Subject: [PATCH] Fix Connected status when PS3 BD remote connects
The PS3 BD remote isn't connectable from the outside,
so the only way to use it with BlueZ is to make it connect. But
the code to create a new connection was never setting the
connected flags on the fake connection, so the remote wrongly
appeared as disconnected even though it was present.
---
input/device.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/input/device.c b/input/device.c
index 5187f41..0bcbbdb 100644
--- a/input/device.c
+++ b/input/device.c
@@ -640,6 +640,8 @@ static int hidp_add_connection(const struct input_device *idev,
fake->disconnect = fake_hid_disconnect;
fake->priv = fake_hid;
err = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
+ if (err == 0)
+ fake->flags |= FI_FLAG_CONNECTED;
goto cleanup;
}
--
1.7.0.1
^ permalink raw reply related
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-09-02 15:30 UTC (permalink / raw)
To: johan.hedberg
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <20100902135108.GA30759@jh-x301>
Hi Johan,
>From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
>Sent: Thursday, September 02, 2010 3:51 PM
>
>
>Thanks. However, the kernel patch and new ioctl will need
>comments at least from Marcel. Once we add an ioctl we're
>stuck with it for quite some time and have to maintain it, no
>matter what kind of newer/better kernel-userspace interfaces
>we come up with. So the choice of accepting a new ioctl isn't so easy.
Ok. Let's wait for Marcel's comment.
>One thing that you'd definitely need to fix in your patches is
>to keep at least the same level of support that the current
>BlueZ has with kernels that don't have the new ioctl. Right
>now your patch would make legacy pairing fail in such cases
>which is not acceptable. Only with a major version change
>(5.x) would it be possible to consider requiring a newer
>kernel version in order to have essential functionality in place.
Right. Will fix this.
/Waldek
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Jiri Kosina @ 2010-09-02 15:25 UTC (permalink / raw)
To: Alan Ott, Marcel Holtmann
Cc: Stefan Achatz, Antonio Ospite, Alexey Dobriyan, Tejun Heo,
Alan Stern, Greg Kroah-Hartman, Stephane Chatty, Michael Poole,
David S. Miller, Bastien Nocera, Eric Dumazet, linux-input,
linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <alpine.LNX.2.00.1008231459370.1019@pobox.suse.cz>
On Mon, 23 Aug 2010, Jiri Kosina wrote:
> > This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
> >
> > Alan Ott (2):
> > HID: Add Support for Setting and Getting Feature Reports from hidraw
> > Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and
> > HIDIOCSFEATURE
> >
> > drivers/hid/hidraw.c | 105 ++++++++++++++++++++++++++++++++++++--
> > drivers/hid/usbhid/hid-core.c | 37 +++++++++++++-
> > include/linux/hid.h | 3 +
> > include/linux/hidraw.h | 3 +
> > net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++--
> > net/bluetooth/hidp/hidp.h | 8 +++
> > 6 files changed, 260 insertions(+), 10 deletions(-)
>
> Marcel, as per our previous discussion -- what is your word on this? I'd
> be glad taking it once you Ack the bluetooth bits (which, as far as I
> understood from your last mail, don't have strong objections against any
> more).
... Marcel?
I'd really like not to miss 2.6.37 merge window with this.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH] Make sure discovery don't interfere with bonding
From: Johan Hedberg @ 2010-09-02 14:43 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1283436253-9850-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Sep 02, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> In situation where the user application keep a discovery session while
> bonding with a device it may cause a delay, or even timeout, due to the
> number of the inquiry responses that the controller has to process.
>
> Since the discovery can be shared between many applications it may not be
> possible to simple require to each application to stop their discovery
> before trying to pair with a device, so to fix this bluetoothd now
> suspends the discovery while bonding, resuming when completed.
> ---
> src/adapter.c | 62 +++++++++++++++++++++++++++++++++++++++++++++-----------
> src/adapter.h | 3 ++
> src/device.c | 4 +++
> 3 files changed, 57 insertions(+), 12 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* [PATCH] Make sure discovery don't interfere with bonding
From: Luiz Augusto von Dentz @ 2010-09-02 14:04 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
In situation where the user application keep a discovery session while
bonding with a device it may cause a delay, or even timeout, due to the
number of the inquiry responses that the controller has to process.
Since the discovery can be shared between many applications it may not be
possible to simple require to each application to stop their discovery
before trying to pair with a device, so to fix this bluetoothd now
suspends the discovery while bonding, resuming when completed.
---
src/adapter.c | 62 +++++++++++++++++++++++++++++++++++++++++++++-----------
src/adapter.h | 3 ++
src/device.c | 4 +++
3 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 173dfbe..25b0671 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -107,7 +107,7 @@ struct btd_adapter {
uint8_t global_mode; /* last valid global mode */
struct session_req *pending_mode;
int state; /* standard inq, periodic inq, name
- * resloving */
+ * resolving, suspended discovery */
GSList *found_devices;
GSList *oor_devices; /* out of range device list */
struct agent *agent; /* For the new API */
@@ -685,6 +685,27 @@ static uint8_t get_needed_mode(struct btd_adapter *adapter, uint8_t mode)
return mode;
}
+static void adapter_stop_inquiry(struct btd_adapter *adapter)
+{
+ pending_remote_name_cancel(adapter);
+
+ /* Clear out of range device list */
+ if (adapter->oor_devices) {
+ g_slist_free(adapter->oor_devices);
+ adapter->oor_devices = NULL;
+ }
+
+ /* Reset if suspended, otherwise remove timer (software scheduler)
+ or request inquiry to stop */
+ if (adapter->state & SUSPENDED_INQUIRY)
+ adapter->state &= ~SUSPENDED_INQUIRY;
+ else if (adapter->scheduler_id) {
+ g_source_remove(adapter->scheduler_id);
+ adapter->scheduler_id = 0;
+ } else
+ adapter_ops->stop_discovery(adapter->dev_id);
+}
+
static void session_remove(struct session_req *req)
{
struct btd_adapter *adapter = req->adapter;
@@ -719,19 +740,9 @@ static void session_remove(struct session_req *req)
DBG("Stopping discovery");
- pending_remote_name_cancel(adapter);
-
clear_found_devices_list(adapter);
- g_slist_free(adapter->oor_devices);
- adapter->oor_devices = NULL;
-
- if (adapter->scheduler_id) {
- g_source_remove(adapter->scheduler_id);
- adapter->scheduler_id = 0;
- }
-
- adapter_ops->stop_discovery(adapter->dev_id);
+ adapter_stop_inquiry(adapter);
}
}
@@ -1219,6 +1230,10 @@ static int adapter_start_inquiry(struct btd_adapter *adapter)
{
gboolean periodic = TRUE;
+ /* Do not start if suspended */
+ if (adapter->state & SUSPENDED_INQUIRY)
+ return 0;
+
if (main_opts.discov_interval)
periodic = FALSE;
@@ -3165,6 +3180,29 @@ gboolean adapter_has_discov_sessions(struct btd_adapter *adapter)
return TRUE;
}
+void adapter_suspend_discovery(struct btd_adapter *adapter)
+{
+ if (adapter->disc_sessions == NULL ||
+ adapter->state & SUSPENDED_INQUIRY)
+ return;
+
+ DBG("Suspending discovery");
+
+ adapter_stop_inquiry(adapter);
+ adapter->state |= SUSPENDED_INQUIRY;
+}
+
+void adapter_resume_discovery(struct btd_adapter *adapter)
+{
+ if (adapter->disc_sessions == NULL)
+ return;
+
+ DBG("Resuming discovery");
+
+ adapter->state &= ~SUSPENDED_INQUIRY;
+ adapter_start_inquiry(adapter);
+}
+
int btd_register_adapter_driver(struct btd_adapter_driver *driver)
{
GSList *adapters;
diff --git a/src/adapter.h b/src/adapter.h
index 5352731..fb52b34 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -33,6 +33,7 @@
#define DISCOVER_TYPE_NONE 0x00
#define STD_INQUIRY 0x01
#define PERIODIC_INQUIRY 0x02
+#define SUSPENDED_INQUIRY 0x04
/* Actions executed after inquiry complete */
#define RESOLVE_NAME 0x10
@@ -133,6 +134,8 @@ void adapter_add_connection(struct btd_adapter *adapter,
void adapter_remove_connection(struct btd_adapter *adapter,
struct btd_device *device, uint16_t handle);
gboolean adapter_has_discov_sessions(struct btd_adapter *adapter);
+void adapter_suspend_discovery(struct btd_adapter *adapter);
+void adapter_resume_discovery(struct btd_adapter *adapter);
struct btd_adapter *btd_adapter_ref(struct btd_adapter *adapter);
void btd_adapter_unref(struct btd_adapter *adapter);
diff --git a/src/device.c b/src/device.c
index 1129e85..9055eca 100644
--- a/src/device.c
+++ b/src/device.c
@@ -1813,6 +1813,8 @@ static void bonding_request_free(struct bonding_req *bonding)
device->bonding = NULL;
+ adapter_resume_discovery(device->adapter);
+
if (!device->agent)
return;
@@ -1879,6 +1881,8 @@ proceed:
bonding->conn = dbus_connection_ref(conn);
bonding->msg = dbus_message_ref(msg);
+ adapter_suspend_discovery(device->adapter);
+
return bonding;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Johan Hedberg @ 2010-09-02 13:51 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480979219655@EXMB04.eu.tieto.com>
Hi Waldek,
On Thu, Sep 02, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> I've completed more tests on the patches and didn't faced any problems
> do far. Legacy paring, ssp, sec mode 3, refresh existing keys and
> security upgrading have finished with success. I did the tests for
> bluez as initiator and again when bluez was an acceptor. All tests
> were done against different controllers CSR (1.1, 2.0, 2.1), Broadcom
> (2.0, 2.1), ST-Ericsson (2.1). I also tried different combinations of
> the controllers in the same use case.
>
> So, I'm pretty sure that it will not introduce any regression.
Ok, that's good to hear.
> Aditionally, we plan to bring this to the UPF and it would be
> appreciated if also other would have that possibility for regression
> testing.
I'll be at the UPF too, so this might be possible.
> If it comes to interaction with the agent I would do this in a
> seperate patch which will contain a new property when 16 digit pin
> code is required.
That's fine.
> I attached slightly updated patches.
Thanks. However, the kernel patch and new ioctl will need comments at
least from Marcel. Once we add an ioctl we're stuck with it for quite
some time and have to maintain it, no matter what kind of newer/better
kernel-userspace interfaces we come up with. So the choice of accepting
a new ioctl isn't so easy.
One thing that you'd definitely need to fix in your patches is to keep
at least the same level of support that the current BlueZ has with
kernels that don't have the new ioctl. Right now your patch would make
legacy pairing fail in such cases which is not acceptable. Only with a
major version change (5.x) would it be possible to consider requiring a
newer kernel version in order to have essential functionality in place.
With all this in mind I'd still prefer it if we postpone the feature
addition until the point where we have a more flexible kernel-userspace
API in place and most of the security logic and information on the
kernel side.
Johan
^ permalink raw reply
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-09-02 13:27 UTC (permalink / raw)
To: johan.hedberg
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <20100827124524.GA9484@jh-x301>
[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]
Johan,
>From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
>Sent: Friday, August 27, 2010 2:45 PM
>So how well have you tested the patches? I.e. how confident
>are you that you're not introducing any regressions? Scenarios
>that would need to be tested before an upstream merge are (and
>I'm probably forgetting several of them):
>
>- legacy pairing acceptor & initiator
>- security mode 3 acceptor & initiator
>- ssp acceptor & initiator
>- renewed link key handling for both debug and normal keys
>- security level upgrading (i.e. connect first to a low security socket
> and then over the same ACL to a higher security socket)
>- complete and partial failure scenarios for all of the above
I've completed more tests on the patches and didn't faced any problems do far.
Legacy paring, ssp, sec mode 3, refresh existing keys and security upgrading have finished with success. I did the tests for bluez as initiator and again when bluez was an acceptor. All tests were done against different controllers CSR (1.1, 2.0, 2.1), Broadcom (2.0, 2.1), ST-Ericsson (2.1). I also tried different combinations of the controllers in the same use case.
So, I'm pretty sure that it will not introduce any regression.
>Additionally all these test should be done against several
>different controllers due to differences in HCI interface
>behavior (event ordering, error codes, etc). In that list I'd
>include at least one CSR, and one Broadcom adapter and any
>other adapters from other manufacturers that you can get hold of.
>
>So how many of these tests do you already have covered? I'm
>not very comfortable with pushing the patches upstream before
>most of the above scenarios have been tested and verified not
>to introduce any regressions.
>
Aditionally, we plan to bring this to the UPF and it would be appreciated if also other would have that possibility for regression testing.
If it comes to interaction with the agent I would do this in a seperate patch which will contain a new property when 16 digit pin code is required.
I attached slightly updated patches.
Regards,
/Waldek
[-- Attachment #2: 0001-BT_SECURITY_HIGH-requires-16-digit-pin-code.patch --]
[-- Type: application/octet-stream, Size: 6043 bytes --]
From 7c1eeda7c1aa5e19c310e965be192f124df7c6fd Mon Sep 17 00:00:00 2001
From: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Date: Mon, 21 Jun 2010 18:53:51 +0200
Subject: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
The security level BT_SECURITY_HIGH expects secure connection
and a minimum 16 digit pin code used for bonding. It's required by the
Sim Access Profile.
Patch on behalf of ST-Ericsson SA.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
lib/hci.h | 8 +++++++-
src/dbus-hci.c | 32 +++++++++++++++++++++++++++-----
src/security.c | 39 +++++++++++++++++++++++++++++++++++----
3 files changed, 69 insertions(+), 10 deletions(-)
diff --git a/lib/hci.h b/lib/hci.h
index 512dab9..a313929 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -96,7 +96,7 @@ enum {
#define HCISETLINKMODE _IOW('H', 226, int)
#define HCISETACLMTU _IOW('H', 227, int)
#define HCISETSCOMTU _IOW('H', 228, int)
-
+#define HCISETCONNINFO _IOW('H', 229, int)
#define HCIBLOCKADDR _IOW('H', 230, int)
#define HCIUNBLOCKADDR _IOW('H', 231, int)
@@ -2326,9 +2326,15 @@ struct hci_conn_info_req {
struct hci_conn_info conn_info[0];
};
+struct hci_set_conn_info_req {
+ bdaddr_t bdaddr;
+ uint8_t pin_len;
+ uint8_t key_type;
+};
struct hci_auth_info_req {
bdaddr_t bdaddr;
uint8_t type;
+ uint8_t level;
};
struct hci_inquiry_req {
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index 9055ffe..fe38e45 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -165,6 +165,8 @@ static void pincode_cb(struct agent *agent, DBusError *err,
{
struct btd_adapter *adapter = device_get_adapter(device);
pin_code_reply_cp pr;
+ struct hci_auth_info_req ar;
+ struct hci_set_conn_info_req cr;
bdaddr_t sba, dba;
size_t len;
int dev;
@@ -180,13 +182,29 @@ static void pincode_cb(struct agent *agent, DBusError *err,
adapter_get_address(adapter, &sba);
device_get_address(device, &dba);
- if (err) {
- hci_send_cmd(dev, OGF_LINK_CTL,
- OCF_PIN_CODE_NEG_REPLY, 6, &dba);
- goto done;
- }
+ if (err)
+ goto reject;
len = strlen(pincode);
+ memset(&ar, 0, sizeof(ar));
+ bacpy(&ar.bdaddr, &dba);
+ if (ioctl(dev, HCIGETAUTHINFO, (unsigned long) &ar) < 0) {
+ error("Can't get auth info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
+
+ if (ar.level == BT_SECURITY_HIGH && len < 16) {
+ error("PIN code is not a 16 digit (%d).", len);
+ goto reject;
+ }
+
+ bacpy(&cr.bdaddr, &dba);
+ cr.pin_len = len;
+ cr.key_type = 0xff;
+ if (ioctl(dev, HCISETCONNINFO, (unsigned long) &cr) < 0) {
+ error("Can't set conn info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
set_pin_length(&sba, len);
@@ -196,7 +214,11 @@ static void pincode_cb(struct agent *agent, DBusError *err,
pr.pin_len = len;
hci_send_cmd(dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
PIN_CODE_REPLY_CP_SIZE, &pr);
+ goto done;
+reject:
+ hci_send_cmd(dev, OGF_LINK_CTL,
+ OCF_PIN_CODE_NEG_REPLY, 6, &dba);
done:
hci_close_dev(dev);
}
diff --git a/src/security.c b/src/security.c
index 667f1f1..a4eedc2 100644
--- a/src/security.c
+++ b/src/security.c
@@ -309,6 +309,7 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
char sa[18], da[18];
uint8_t type;
int err;
+ int pinlen;
if (!get_adapter_and_device(sba, dba, &adapter, &device, FALSE))
device = NULL;
@@ -325,9 +326,11 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
DBG("HCIGETAUTHINFO failed %s (%d)",
strerror(errno), errno);
req.type = 0x00;
+ req.level = BT_SECURITY_LOW;
}
- DBG("kernel auth requirements = 0x%02x", req.type);
+ DBG("kernel auth requirements = 0x%02x and security level = 0x%02x", \
+ req.type, req.level);
if (main_opts.debug_keys && device && device_get_debug_key(device, key))
type = 0x03;
@@ -341,18 +344,35 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
DBG("link key type = 0x%02x", type);
+ pinlen = read_pin_length(sba, dba);
+ DBG("stored link key type = 0x%02x pin_len = %d", type, pinlen);
+
/* Don't use unauthenticated combination keys if MITM is
- * required */
- if (type == 0x04 && req.type != 0xff && (req.type & 0x01))
+ * required and also don't use combination link keys authenticated
+ * with the PIN code len < 16 if security level BT_SECURITY_HIGH
+ * is required */
+ if ((type == 0x04 && req.type != 0xff && (req.type & 0x01)) ||
+ (type == 0x00 && req.level == BT_SECURITY_HIGH && pinlen < 16))
hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY,
6, dba);
else {
link_key_reply_cp lr;
+ struct hci_set_conn_info_req cr;
memcpy(lr.link_key, key, 16);
bacpy(&lr.bdaddr, dba);
- hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_REPLY,
+ bacpy(&cr.bdaddr, dba);
+ cr.pin_len = pinlen;
+ cr.key_type = type;
+
+ if (ioctl(dev, HCISETCONNINFO, (unsigned long) &cr) < 0) {
+ error("Can't set conn info: %s (%d)", strerror(errno),
+ errno);
+ hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY,
+ 6, dba);
+ } else
+ hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_REPLY,
LINK_KEY_REPLY_CP_SIZE, &lr);
}
}
@@ -523,6 +543,7 @@ static void pin_code_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
pin_code_reply_cp pr;
struct hci_conn_info_req *cr;
struct hci_conn_info *ci;
+ struct hci_auth_info_req ar;
char sa[18], da[18], pin[17];
int pinlen;
@@ -542,10 +563,20 @@ static void pin_code_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
}
ci = cr->conn_info;
+ memset(&ar, 0, sizeof(ar));
+ bacpy(&ar.bdaddr, dba);
+ if (ioctl(dev, HCIGETAUTHINFO, (unsigned long) &ar) < 0) {
+ error("Can't get auth info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
memset(pin, 0, sizeof(pin));
pinlen = read_pin_code(sba, dba, pin);
if (pinlen > 0) {
+ if (ar.level == BT_SECURITY_HIGH && pinlen < 16) {
+ error("Not 16 digit pin code.");
+ goto reject;
+ }
set_pin_length(sba, pinlen);
memcpy(pr.pin_code, pin, pinlen);
pr.pin_len = pinlen;
--
1.7.0.4
[-- Attachment #3: 0001-Bluetooth-BT_SECURITY_HIGH-requires-16-digit-pin-cod.patch --]
[-- Type: application/octet-stream, Size: 9554 bytes --]
From acc1dd35f7fd6f9d24c328aef244365ef6716382 Mon Sep 17 00:00:00 2001
From: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Date: Wed, 25 Aug 2010 17:48:32 +0200
Subject: [PATCH] Bluetooth: BT_SECURITY_HIGH requires 16 digit pin code
The security level BT_SECURITY_HIGH expects secure connection
and a minimum 16 digit pin code used for bonding. It's required by the
Sim Access Profile.
Patch on behalf of ST-Ericsson SA.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
include/net/bluetooth/hci.h | 17 +++++++
include/net/bluetooth/hci_core.h | 4 ++
net/bluetooth/hci_conn.c | 97 +++++++++++++++++++++++++++++++-------
net/bluetooth/hci_event.c | 4 ++
net/bluetooth/hci_sock.c | 3 +
net/bluetooth/rfcomm/core.c | 10 ++++-
6 files changed, 116 insertions(+), 19 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index bcbdd6d..32a33c0 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -99,6 +99,7 @@ enum {
#define HCISETLINKMODE _IOW('H', 226, int)
#define HCISETACLMTU _IOW('H', 227, int)
#define HCISETSCOMTU _IOW('H', 228, int)
+#define HCISETCONNINFO _IOW('H', 229, int)
#define HCIBLOCKADDR _IOW('H', 230, int)
#define HCIUNBLOCKADDR _IOW('H', 231, int)
@@ -224,6 +225,15 @@ enum {
#define HCI_AT_GENERAL_BONDING 0x04
#define HCI_AT_GENERAL_BONDING_MITM 0x05
+/* Link Key types */
+#define HCI_LK_COMBINATION 0x00
+#define HCI_LK_LOCAL_UNIT 0x01
+#define HCI_LK_REMOTE_UNIT 0x02
+#define HCI_LK_DEBUG_COMBINATION 0x03
+#define HCI_LK_UNAUTHENTICATED_COMBINATION 0x04
+#define HCI_LK_AUTHENTICATED_COMBINATION 0x05
+#define HCI_LK_CHANGEED_COMBINATION_KEY 0x06
+
/* ----- HCI Commands ---- */
#define HCI_OP_INQUIRY 0x0401
struct hci_cp_inquiry {
@@ -1022,9 +1032,16 @@ struct hci_conn_info_req {
struct hci_conn_info conn_info[0];
};
+struct hci_set_conn_info_req {
+ bdaddr_t bdaddr;
+ __u8 pin_len;
+ __u8 key_type;
+};
+
struct hci_auth_info_req {
bdaddr_t bdaddr;
__u8 type;
+ __u8 level;
};
struct hci_inquiry_req {
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 4568b93..9eb2da3 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -183,6 +183,8 @@ struct hci_conn {
__u32 link_mode;
__u8 auth_type;
__u8 sec_level;
+ __u8 key_type;
+ __u8 pin_len;
__u8 power_save;
__u16 disc_timeout;
unsigned long pend;
@@ -430,6 +432,8 @@ int hci_get_dev_info(void __user *arg);
int hci_get_conn_list(void __user *arg);
int hci_get_conn_info(struct hci_dev *hdev, void __user *arg);
int hci_get_auth_info(struct hci_dev *hdev, void __user *arg);
+int hci_set_conn_info(struct hci_dev *hdev, void __user *arg);
+
int hci_inquiry(void __user *arg);
struct bdaddr_list *hci_blacklist_lookup(struct hci_dev *hdev, bdaddr_t *bdaddr);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 0b1e460..54709fa 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -233,6 +233,8 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->mode = HCI_CM_ACTIVE;
conn->state = BT_OPEN;
conn->auth_type = HCI_AT_GENERAL_BONDING;
+ conn->key_type = 0xff;
+ conn->pin_len = 0;
conn->power_save = 1;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
@@ -433,15 +435,11 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
EXPORT_SYMBOL(hci_conn_check_link_mode);
/* Authenticate remote device */
-static int hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
+static void hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
{
BT_DBG("conn %p", conn);
- if (sec_level > conn->sec_level)
- conn->sec_level = sec_level;
- else if (conn->link_mode & HCI_LM_AUTH)
- return 1;
-
+ conn->sec_level = sec_level;
conn->auth_type = auth_type;
if (!test_and_set_bit(HCI_CONN_AUTH_PEND, &conn->pend)) {
@@ -450,8 +448,20 @@ static int hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
hci_send_cmd(conn->hdev, HCI_OP_AUTH_REQUESTED,
sizeof(cp), &cp);
}
+}
- return 0;
+/* Encrypt the the link */
+static void hci_conn_encrypt(struct hci_conn *conn)
+{
+ BT_DBG("conn %p", conn);
+
+ if (!test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) {
+ struct hci_cp_set_conn_encrypt cp;
+ cp.handle = cpu_to_le16(conn->handle);
+ cp.encrypt = 1;
+ hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT,
+ sizeof(cp), &cp);
+ }
}
/* Enable security */
@@ -459,28 +469,54 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
{
BT_DBG("conn %p", conn);
+ /* For sdp we do not need the link key. */
if (sec_level == BT_SECURITY_SDP)
return 1;
+ /* For non 2.1 devices and low security level we do not need the
+ link key. */
if (sec_level == BT_SECURITY_LOW &&
(!conn->ssp_mode || !conn->hdev->ssp_mode))
return 1;
- if (conn->link_mode & HCI_LM_ENCRYPT)
- return hci_conn_auth(conn, sec_level, auth_type);
-
+ /* For other security levels we need link key. */
+ if (!(conn->link_mode & HCI_LM_AUTH))
+ goto do_auth;
+
+ /* An authenticated combination key has sufficient security for any
+ security level. */
+ if (conn->key_type == HCI_LK_AUTHENTICATED_COMBINATION)
+ goto do_encrypt;
+
+ /* An unauthenticated combination key has sufficient security for
+ security level 1 and 2. */
+ if (conn->key_type == HCI_LK_UNAUTHENTICATED_COMBINATION
+ && (sec_level == BT_SECURITY_MEDIUM
+ || sec_level == BT_SECURITY_LOW))
+ goto do_encrypt;
+
+ /* A combination key has always sufficient security for the security
+ levels 1 or 2. High security level requires that the combination key
+ was generated using the maximum PIN code length (16).
+ For pre 2.1 units. */
+ if ((conn->key_type == HCI_LK_COMBINATION))
+ if ((sec_level != BT_SECURITY_HIGH) || (conn->pin_len >= 16))
+ goto do_encrypt;
+
+do_auth:
if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
return 0;
- if (hci_conn_auth(conn, sec_level, auth_type)) {
- struct hci_cp_set_conn_encrypt cp;
- cp.handle = cpu_to_le16(conn->handle);
- cp.encrypt = 1;
- hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT,
- sizeof(cp), &cp);
- }
-
+ hci_conn_auth(conn, sec_level, auth_type);
return 0;
+
+do_encrypt:
+ if (conn->link_mode & HCI_LM_ENCRYPT)
+ return 1; /* sufficient link key */
+ else{
+ hci_conn_encrypt(conn);
+ return 0; /* auth pending */
+ }
}
EXPORT_SYMBOL(hci_conn_security);
@@ -713,6 +749,30 @@ int hci_get_conn_info(struct hci_dev *hdev, void __user *arg)
return copy_to_user(ptr, &ci, sizeof(ci)) ? -EFAULT : 0;
}
+int hci_set_conn_info(struct hci_dev *hdev, void __user *arg)
+{
+ struct hci_set_conn_info_req req;
+ struct hci_conn *conn;
+
+ if (copy_from_user(&req, arg, sizeof(req))) {
+ BT_DBG("copy from user failed");
+ return -EFAULT;
+ }
+
+ hci_dev_lock_bh(hdev);
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &req.bdaddr);
+ if (conn) {
+ conn->pin_len = req.pin_len;
+ conn->key_type = req.key_type;
+ }
+ hci_dev_unlock_bh(hdev);
+
+ if (!conn)
+ return -ENOENT;
+
+ return 0;
+}
+
int hci_get_auth_info(struct hci_dev *hdev, void __user *arg)
{
struct hci_auth_info_req req;
@@ -725,6 +785,7 @@ int hci_get_auth_info(struct hci_dev *hdev, void __user *arg)
conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &req.bdaddr);
if (conn)
req.type = conn->auth_type;
+ req.level = conn->sec_level;
hci_dev_unlock_bh(hdev);
if (!conn)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index bfef5ba..6d6b04c 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1521,6 +1521,10 @@ static inline void hci_link_key_notify_evt(struct hci_dev *hdev, struct sk_buff
conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
if (conn) {
hci_conn_hold(conn);
+ /* For Changed Combination Link Key the only link key has
+ * been changed, not link key type. */
+ if (conn->key_type != HCI_LK_CHANGEED_COMBINATION_KEY)
+ conn->key_type = ev->key_type;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
hci_conn_put(conn);
}
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 83acd16..502a7b0 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -269,6 +269,9 @@ static inline int hci_sock_bound_ioctl(struct sock *sk, unsigned int cmd, unsign
case HCIGETCONNINFO:
return hci_get_conn_info(hdev, (void __user *) arg);
+ case HCISETCONNINFO:
+ return hci_set_conn_info(hdev, (void __user *) arg);
+
case HCIGETAUTHINFO:
return hci_get_auth_info(hdev, (void __user *) arg);
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 7dca91b..2e248d5 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2086,7 +2086,15 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
continue;
if (!status)
- set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+ if (d->sec_level != BT_SECURITY_HIGH)
+ set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+ else
+ if ((conn->key_type == HCI_LK_AUTHENTICATED_COMBINATION)
+ || (conn->key_type == HCI_LK_COMBINATION
+ && conn->pin_len >= 16))
+ set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+ else
+ set_bit(RFCOMM_AUTH_REJECT, &d->flags);
else
set_bit(RFCOMM_AUTH_REJECT, &d->flags);
}
--
1.7.0.4
^ permalink raw reply related
* Re: AVRCP future
From: Luiz Augusto von Dentz @ 2010-09-02 12:56 UTC (permalink / raw)
To: Sander van Grieken; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <201009021020.50162.sander@outrightsolutions.nl>
Hi,
On Thu, Sep 2, 2010 at 11:20 AM, Sander van Grieken
<sander@outrightsolutions.nl> wrote:
> I'm not in favor of having (multiple) storage plugins. Simply because a storage backend is
> not a player. This distinction is important. MeeGo/tracker is a semantic index, so in
> theory you could browse the media through it, but the player might have 'smart' playlist,
> or is only able to play media of a certain kind. Also the current playlist is a player-
> only thing (and is also a browsable item). So I think browsing should go _through_ the
> player.
>
> I was more thinking of exposing a dbus interface that allows a player (or any TG) to
> register itself as a TG, then acting on signals/sending events/responses.
That could be done, actually this is a similar idea as we are planning
to have[1] for replacing our audio ipc, but for things like progress
we would really need to cache it since most device Ive seem keep
polling this. Another possibility is to use MPRIS and PulseAudio
together, but the spec of MPRIS need some work right now the player
assume some name with a prefix e.g: org.freedesktop.MPRIS which is not
that nice, perhaps making MPRIS a separate daemon would make more
sense.
This means that for freedesktop we have:
BlueZ <-> PulseAudio <-> MPRIS
For the rest:
BlueZ <-> Player/whatever
If that is done in PulseAudio we could probably associate the metadata
directly with the stream using MPRIS, if it is up to the player then
we don't care they can set this information directly via some D-Bus
API that is yet to be defined, which wouldn't require player to
implement MPRIS spec. Joao Paulo has something already so I guess we
can start from there[2].
[1] http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
[2] http://git.profusion.mobi/cgit.cgi/jprvita/bluez/log/?h=avrcp_metadata
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Get IEEE1284 for a single printer
From: Bastien Nocera @ 2010-09-02 10:07 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100901184902.GA30041@jh-x301>
On Wed, 2010-09-01 at 21:49 +0300, Johan Hedberg wrote:
> Hi Bastien,
>
> On Wed, Sep 01, 2010, Bastien Nocera wrote:
> > From: Bastien Nocera <hadess@hadess.net>
> > Date: Sun, 6 Jun 2010 15:48:26 +0100
> > Subject: [PATCH] (cups) Add ability to print IEEE1284 device ID
> >
> > Add ability to print IEEE1284 device ID for Bluetooth
> > printers to allow auto-configuration once paired.
> > ---
> > cups/main.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 83 insertions(+), 0 deletions(-)
>
> Thanks for the updated patch. It's now pushed upstream.
Thanks.
> > I've only fixed the style problems in the patch itself. I'm happy to do
> > the rest of the file, if you have a "indent" magic incantation for it.
>
> In my experience indent can produce quite a mess compared to fixing
> style issues manually. Anyway, I went ahead and did the cleanup myself
> for the issues that I could quickly spot and pushed the fixes as a
> separate patch upstream.
OK. Indent should be able to do this without making a mess as long as
you know the exact parameters. Mind, some of the restrictions feel like
they're from COBOL days (79 characters line width?).
I prefer readable code to mashed-up code that looks that way because of
hard constraints.
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix MTU L2CAP configuration parameter
From: Ville Tervo @ 2010-09-02 9:34 UTC (permalink / raw)
To: ext Emeltchenko Andrei; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1283343445-9328-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
On Wed, Sep 01, 2010 at 02:17:25PM +0200, ext Emeltchenko Andrei wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> When receiving L2CAP negative configuration response with respect
> to MTU parameter we modify wrong field. MTU here means proposed
> value of MTU that the remote device intends to transmit. So for local
> L2CAP socket it is pi->imtu.
>
Yes imtu is negotiated in this phase.
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/l2cap.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index c784703..9fad312 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -2771,10 +2771,10 @@ static int l2cap_parse_conf_rsp(struct sock *sk, void *rsp, int len, void *data,
> case L2CAP_CONF_MTU:
> if (val < L2CAP_DEFAULT_MIN_MTU) {
> *result = L2CAP_CONF_UNACCEPT;
> - pi->omtu = L2CAP_DEFAULT_MIN_MTU;
> + pi->imtu = L2CAP_DEFAULT_MIN_MTU;
> } else
> - pi->omtu = val;
> - l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->omtu);
> + pi->imtu = val;
> + l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
> break;
>
> case L2CAP_CONF_FLUSH_TO:
> --
> 1.7.0.4
--
Ville
^ permalink raw reply
* Re: AVRCP future
From: Sander van Grieken @ 2010-09-02 8:20 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100901185729.GB30041@jh-x301>
Hi Johan,
Thanks for your feedback.
On Wednesday 01 September 2010 20:57:29 Johan Hedberg wrote:
> Hi Sander,
>
> On Wed, Sep 01, 2010, Sander van Grieken wrote:
> > - Is anyone working on AVRCP, besides jprvita?
>
> Maybe, but nothing I'm aware of.
>
> > - Aside from the proposed D-Bus API in doc/control-api.txt, has anyone
> > done some research how an AVRCP1.4 interface should look?
>
> Mostly just ideas that haven't really been written down.
Argh, there a wiki would come in handy ;) It has probably gone over the list a few times,
but I just joined the list and the web archives are.. cumbersome, and google didn't find
much of avrcp in the list.
> It'd be easier
> if we talked about specific features though than about a profile version
> since different features will require different design solutions and
> API's. E.g. in the MeeGo case we'd probably be talking to tracker in
> order to implement media browsing, however other platforms might have a
> different storage backend which means that we'll need some sort of
> backend driver abstraction (we have a similar situation already in obexd
> PBAP and contact storage).
I'm not in favor of having (multiple) storage plugins. Simply because a storage backend is
not a player. This distinction is important. MeeGo/tracker is a semantic index, so in
theory you could browse the media through it, but the player might have 'smart' playlist,
or is only able to play media of a certain kind. Also the current playlist is a player-
only thing (and is also a browsable item). So I think browsing should go _through_ the
player.
I was more thinking of exposing a dbus interface that allows a player (or any TG) to
register itself as a TG, then acting on signals/sending events/responses.
> > - Are there objections to conforming to section 2.3.2, i.e. untying
> > the AVRCP connection from the A2DP connection?
>
> If by that you mean adding Connect() and Disconnect() method calls to
> the org.bluez.Control D-Bus interface, then I'd be happy to accept
> patches for it. However, the automated connecting of AVRCP as triggered
> by an A2DP connection should stay in order to keep good interoperability
> and make things easy for the user interface code.
Agreed.
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Add handling of UID contact's field in vCard
From: Johan Hedberg @ 2010-09-02 8:10 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=nEVCDx3L3B5d0Xet7uJU0XXpBqgCYf0AQ5fz9@mail.gmail.com>
Hi Rafal,
On Thu, Sep 02, 2010, Rafał Michalski wrote:
> From: Rafal Michalski <michalski.raf@gmail.com>
> Date: Wed, 1 Sep 2010 16:08:35 +0200
> Subject: [PATCH] Add handling of UID contact's field in vCard
>
> After pulling contacts this field wasn't presented in downloaded vCard
> structure in spite of that it existed (not empty). Now it shows downloaded
> UID (using database query).
> ---
> plugins/phonebook-tracker.c | 1 +
> plugins/vcard.c | 4 ++++
> plugins/vcard.h | 1 +
> 3 files changed, 6 insertions(+), 0 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] hid/hid-sony: Apply sixaxis quirks only to sixaxis
From: Jiri Kosina @ 2010-09-02 7:41 UTC (permalink / raw)
To: Antonio Ospite; +Cc: Bastien Nocera, linux-input, linux-bluetooth, cbe-oss-dev
In-Reply-To: <20100901192055.2f23c8c7.ospite@studenti.unina.it>
On Wed, 1 Sep 2010, Antonio Ospite wrote:
> > > Be more explicit and avoid calling sony_set_operational_usb() when we
> > > have USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE.
> > >
> > > While at it, rename the sony_set_operational routines to
> > > sixaxis_set_operational as they are sixaxis specific.
> > >
> > > This is also in preparation for the sysfs interface to set and get bdaddr
> > > over usb and for some other Sixaxis report fixup.
> > >
> > > Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> >
> > Signed-off-by: Bastien Nocera <hadess@hadess.net>
> >
>
> Thanks Bastien for bringing this up again, I was going to repost
> this patch sometime this month.
>
> Added Jiri to CC as I forgot to do that back then.
Thanks, I have missed that one on linux-input@.
Applied now.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* [PATCH] Add handling of UID contact's field in vCard
From: Rafał Michalski @ 2010-09-02 7:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Add-handling-of-UID-contact-s-field-in-vCard.patch --]
[-- Type: text/x-patch, Size: 2012 bytes --]
From 4c3ee0455ea066b5fd4cb07a54c0bc6e0012d848 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Wed, 1 Sep 2010 16:08:35 +0200
Subject: [PATCH] Add handling of UID contact's field in vCard
After pulling contacts this field wasn't presented in downloaded vCard
structure in spite of that it existed (not empty). Now it shows downloaded
UID (using database query).
---
plugins/phonebook-tracker.c | 1 +
plugins/vcard.c | 4 ++++
plugins/vcard.h | 1 +
3 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 193226f..bdd9587 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -866,6 +866,7 @@ add_entry:
contact->company = g_strdup(reply[22]);
contact->department = g_strdup(reply[23]);
contact->title = g_strdup(reply[24]);
+ contact->uid = g_strdup(reply[CONTACTS_ID_COL]);
set_call_type(contact, reply[COL_DATE], reply[COL_SENT],
reply[COL_ANSWERED]);
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 6d74e06..4a77eb3 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -468,6 +468,9 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_begin(vcards, format);
+ if (filter & FILTER_UID)
+ vcard_printf_tag(vcards, format, "UID", NULL, contact->uid);
+
if (filter & FILTER_N)
vcard_printf_name(vcards, contact);
@@ -580,6 +583,7 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_slist_foreach(contact->addresses, address_free, NULL);
g_slist_free(contact->addresses);
+ g_free(contact->uid);
g_free(contact->fullname);
g_free(contact->given);
g_free(contact->family);
diff --git a/plugins/vcard.h b/plugins/vcard.h
index d012106..4d134c2 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -62,6 +62,7 @@ struct phonebook_address {
};
struct phonebook_contact {
+ char *uid;
char *fullname;
char *given;
char *family;
--
1.6.3.3
^ permalink raw reply related
* Re: AVRCP future
From: Johan Hedberg @ 2010-09-01 18:57 UTC (permalink / raw)
To: Sander van Grieken; +Cc: linux-bluetooth
In-Reply-To: <201009011603.02153.sander@outrightsolutions.nl>
Hi Sander,
On Wed, Sep 01, 2010, Sander van Grieken wrote:
> - Is anyone working on AVRCP, besides jprvita?
Maybe, but nothing I'm aware of.
> - Aside from the proposed D-Bus API in doc/control-api.txt, has anyone
> done some research how an AVRCP1.4 interface should look?
Mostly just ideas that haven't really been written down. It'd be easier
if we talked about specific features though than about a profile version
since different features will require different design solutions and
API's. E.g. in the MeeGo case we'd probably be talking to tracker in
order to implement media browsing, however other platforms might have a
different storage backend which means that we'll need some sort of
backend driver abstraction (we have a similar situation already in obexd
PBAP and contact storage).
> - Are there objections to conforming to section 2.3.2, i.e. untying
> the AVRCP connection from the A2DP connection?
If by that you mean adding Connect() and Disconnect() method calls to
the org.bluez.Control D-Bus interface, then I'd be happy to accept
patches for it. However, the automated connecting of AVRCP as triggered
by an A2DP connection should stay in order to keep good interoperability
and make things easy for the user interface code.
Johan
^ permalink raw reply
* Re: [PATCH] Get IEEE1284 for a single printer
From: Johan Hedberg @ 2010-09-01 18:49 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <1283351741.2361.19.camel@localhost.localdomain>
Hi Bastien,
On Wed, Sep 01, 2010, Bastien Nocera wrote:
> From: Bastien Nocera <hadess@hadess.net>
> Date: Sun, 6 Jun 2010 15:48:26 +0100
> Subject: [PATCH] (cups) Add ability to print IEEE1284 device ID
>
> Add ability to print IEEE1284 device ID for Bluetooth
> printers to allow auto-configuration once paired.
> ---
> cups/main.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 83 insertions(+), 0 deletions(-)
Thanks for the updated patch. It's now pushed upstream.
> I've only fixed the style problems in the patch itself. I'm happy to do
> the rest of the file, if you have a "indent" magic incantation for it.
In my experience indent can produce quite a mess compared to fixing
style issues manually. Anyway, I went ahead and did the cleanup myself
for the issues that I could quickly spot and pushed the fixes as a
separate patch upstream.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] hid/hid-sony: get and set Sixaxis bdaddr via sysfs
From: Bastien Nocera @ 2010-09-01 17:41 UTC (permalink / raw)
To: Antonio Ospite; +Cc: linux-input, linux-bluetooth, cbe-oss-dev, Jiri Kosina
In-Reply-To: <20100901192854.9370c605.ospite@studenti.unina.it>
On Wed, 2010-09-01 at 19:28 +0200, Antonio Ospite wrote:
> On Wed, 01 Sep 2010 17:17:54 +0100
> Bastien Nocera <hadess@hadess.net> wrote:
>
> > On Mon, 2010-05-03 at 22:15 +0200, Antonio Ospite wrote:
> > > Expose to userspace a simple way to get device bdaddr, and get/set master
> > > bdaddr on Sixaxis controller.
> > >
> > > Right now userspace softwares which manage pairing the controller with a
> > > bluetooth adapter, rely on libusb and hence have to detach and reattach
> > > usbhid, which is not very nice.
> > >
> > > Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> > > ---
> > >
> > > As said, ideally this should be done with an interface such as hidraw, but its
> > > limitations prevent us from doing it the right way; and I am not going to
> > > touch hidraw myself anytime soon.
> >
> > Rest looks alright to me. Thanks!
>
> Bastien, Jiri, this patch can be DISCARDED. The hidraw work from Alan
> Ott (waiting for Marcel to ACK the bluetooth part) will make this kernel
> approach overkill.
>
> I already have some bluez patches based on Alan's work, but I am waiting
> for the needed changes to land into linus tree before submitting them.
>
> Sorry for making you wasting some time reviewing this one, I told you on
> IRC it could be discarded, but we know: "IRCs volant, emails manent".
Given the time it took me to review it, it's my own damn fault anyway ;)
^ permalink raw reply
* Re: [PATCH 2/2] hid/hid-sony: get and set Sixaxis bdaddr via sysfs
From: Antonio Ospite @ 2010-09-01 17:28 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-input, linux-bluetooth, cbe-oss-dev, Jiri Kosina
In-Reply-To: <1283357874.2361.24.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]
On Wed, 01 Sep 2010 17:17:54 +0100
Bastien Nocera <hadess@hadess.net> wrote:
> On Mon, 2010-05-03 at 22:15 +0200, Antonio Ospite wrote:
> > Expose to userspace a simple way to get device bdaddr, and get/set master
> > bdaddr on Sixaxis controller.
> >
> > Right now userspace softwares which manage pairing the controller with a
> > bluetooth adapter, rely on libusb and hence have to detach and reattach
> > usbhid, which is not very nice.
> >
> > Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> > ---
> >
> > As said, ideally this should be done with an interface such as hidraw, but its
> > limitations prevent us from doing it the right way; and I am not going to
> > touch hidraw myself anytime soon.
>
> Rest looks alright to me. Thanks!
Bastien, Jiri, this patch can be DISCARDED. The hidraw work from Alan
Ott (waiting for Marcel to ACK the bluetooth part) will make this kernel
approach overkill.
I already have some bluez patches based on Alan's work, but I am waiting
for the needed changes to land into linus tree before submitting them.
Sorry for making you wasting some time reviewing this one, I told you on
IRC it could be discarded, but we know: "IRCs volant, emails manent".
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ 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