* Re: [PATCH 2/2] Fix missing comma in cmd_le_str
From: Johan Hedberg @ 2010-09-30 7:31 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1285768581-19654-2-git-send-email-ville.tervo@nokia.com>
Hi Ville,
On Wed, Sep 29, 2010, Ville Tervo wrote:
> ---
> parser/hci.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Thanks. This one has also been pushed upstream.
Johan
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Johan Hedberg @ 2010-09-30 7:39 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTimvvp=D+X+TcP3Ji7WuGaMZF7+LA+8BWZiQCStr@mail.gmail.com>
Hi Claudio,
On Wed, Sep 29, 2010, Claudio Takahasi wrote:
> StartDiscovery() triggers all the process. The adapter type: BR/EDR
> only/LE only or dual mode is hidden from the higher layers.
> So, your suggestion it try to hide all discovery details inside the
> hciops as much as possible?
That was the idea yes, but I'm not 100% sure that it's the best
approach. Another question is also how do we want to represent this with
the new management interface. Should the kernel do it "all" through a
single request from userspace or should userspace control the separate
BR/EDR and LE discoveries. If it's the former, then having a single
adapter_ops callback makes sense. If it's the later then we should
probably have two separate ones. Either way I now realize that to
implement this with a single callback we'd need to have the HCI event
processing moved over to hciops and that's not something that will
happen very quickly. So maybe it's better to have these as two separate
adapter_ops callbacks for now.
Johan
^ permalink raw reply
* [PATCH] Fix not detecting errors on small files
From: Luiz Augusto von Dentz @ 2010-09-30 8:09 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Make use of gw_obex_xfer_close instead of gw_obex_xfer_flush since the
former not only flushes the remaining data but also wait for the response
catching errors that gw_obex_xfer_flush doesn't.
---
client/transfer.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/client/transfer.c b/client/transfer.c
index 8ceb36f..ea98b32 100644
--- a/client/transfer.c
+++ b/client/transfer.c
@@ -380,7 +380,7 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
transfer->filled += len;
if (transfer->filled == 0) {
- gw_obex_xfer_flush(xfer, &err);
+ gw_obex_xfer_close(xfer, &err);
goto done;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Fix not detecting errors on small files
From: Johan Hedberg @ 2010-09-30 8:20 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1285834199-20500-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Sep 30, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> Make use of gw_obex_xfer_close instead of gw_obex_xfer_flush since the
> former not only flushes the remaining data but also wait for the response
> catching errors that gw_obex_xfer_flush doesn't.
> ---
> client/transfer.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks for the patch. It has been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: hci open callback for hci UART transport driver
From: Suraj Sumangala @ 2010-09-30 8:31 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth@vger.kernel.org, Jothikumar Mothilal
In-Reply-To: <1285075981-8941-1-git-send-email-suraj@atheros.com>
*ping*
On 9/21/2010 7:03 PM, Suraj Sumangala wrote:
> This patch provides option for hci transport driver protocol implementation
> to have a callback for hci open.
>
> Signed-off-by: Suraj Sumangala<suraj@atheros.com>
> ---
> drivers/bluetooth/hci_ldisc.c | 5 ++++-
> drivers/bluetooth/hci_uart.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletions(-)
>
Regards
Suraj
^ permalink raw reply
* [PATCH] Fix handlig for gboolean mce_bt_set field
From: Rafal Michalski @ 2010-09-30 8:45 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
Expression (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is invalid because it makes
wrong assumption about that it evaluates to TRUE, when bit
MCE_RADIO_STATE_BLUETOOTH is set. In this case, assignment
mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) makes that gboolean
"mce_bt_set" receives value equal 8 instead of TRUE (equal 1). So condition in
"if (mce_bt_set == powered)" statement will never evaluate to true because
gboolean "powered" receives only TRUE (equal 1) or FALSE (equal 0) value.
We should remember that gboolean type is not bool type in C++ sense.
It's simply typedef of gint (int), so assignmnet:
mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is valid for compiler but
in our case it makes a bug. So assignmnet:
mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) == MCE_RADIO_STATE_BLUETOOTH
preserves that "mce_bt_set" will receive only TRUE or FALSE value.
---
plugins/maemo6.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/plugins/maemo6.c b/plugins/maemo6.c
index c96731d..45d96b8 100644
--- a/plugins/maemo6.c
+++ b/plugins/maemo6.c
@@ -71,7 +71,8 @@ static gboolean mce_signal_callback(DBusConnection *connection,
/* set the adapter according to the mce signal
and remember the value */
- mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH;
+ mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) ==
+ MCE_RADIO_STATE_BLUETOOTH;
if (mce_bt_set)
btd_adapter_switch_online(adapter);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Fix handlig for gboolean mce_bt_set field
From: Gustavo F. Padovan @ 2010-09-30 8:51 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1285836334-7012-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
* Rafal Michalski <michalski.raf@gmail.com> [2010-09-30 10:45:34 +0200]:
> Expression (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is invalid because it makes
> wrong assumption about that it evaluates to TRUE, when bit
> MCE_RADIO_STATE_BLUETOOTH is set. In this case, assignment
> mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) makes that gboolean
> "mce_bt_set" receives value equal 8 instead of TRUE (equal 1). So condition in
> "if (mce_bt_set == powered)" statement will never evaluate to true because
> gboolean "powered" receives only TRUE (equal 1) or FALSE (equal 0) value.
> We should remember that gboolean type is not bool type in C++ sense.
> It's simply typedef of gint (int), so assignmnet:
> mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is valid for compiler but
> in our case it makes a bug. So assignmnet:
> mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) == MCE_RADIO_STATE_BLUETOOTH
> preserves that "mce_bt_set" will receive only TRUE or FALSE value.
> ---
> plugins/maemo6.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/maemo6.c b/plugins/maemo6.c
> index c96731d..45d96b8 100644
> --- a/plugins/maemo6.c
> +++ b/plugins/maemo6.c
> @@ -71,7 +71,8 @@ static gboolean mce_signal_callback(DBusConnection *connection,
>
> /* set the adapter according to the mce signal
> and remember the value */
> - mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH;
> + mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) ==
> + MCE_RADIO_STATE_BLUETOOTH;
Alternatively you can do
mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH)
It might be better do that this way, but I'm not really asking you to
change that. ;)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* [PATCH] Fix handlig for gboolean mce_bt_set field
From: Rafal Michalski @ 2010-09-30 10:22 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
Expression (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is invalid because it makes
wrong assumption about that it evaluates to TRUE, when bit
MCE_RADIO_STATE_BLUETOOTH is set. In this case, assignment
mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) makes that gboolean
"mce_bt_set" receives value equal 8 instead of TRUE (equal 1). So condition in
"if (mce_bt_set == powered)" statement will never evaluate to true because
gboolean "powered" receives only TRUE (equal 1) or FALSE (equal 0) value.
We should remember that gboolean type is not bool type in C++ sense.
It's simply typedef of gint (int), so assignmnet:
mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is valid for compiler but
in our case it makes a bug. So normalization (double negation) in assignment:
mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH) preserves that
"mce_bt_set" will receive only TRUE or FALSE value.
---
plugins/maemo6.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/maemo6.c b/plugins/maemo6.c
index c96731d..c396db0 100644
--- a/plugins/maemo6.c
+++ b/plugins/maemo6.c
@@ -71,7 +71,7 @@ static gboolean mce_signal_callback(DBusConnection *connection,
/* set the adapter according to the mce signal
and remember the value */
- mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH;
+ mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH);
if (mce_bt_set)
btd_adapter_switch_online(adapter);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Fix handlig for gboolean mce_bt_set field
From: Johan Hedberg @ 2010-09-30 10:49 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1285842160-4127-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Thu, Sep 30, 2010, Rafal Michalski wrote:
> Expression (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is invalid because it makes
> wrong assumption about that it evaluates to TRUE, when bit
> MCE_RADIO_STATE_BLUETOOTH is set. In this case, assignment
> mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) makes that gboolean
> "mce_bt_set" receives value equal 8 instead of TRUE (equal 1). So condition in
> "if (mce_bt_set == powered)" statement will never evaluate to true because
> gboolean "powered" receives only TRUE (equal 1) or FALSE (equal 0) value.
> We should remember that gboolean type is not bool type in C++ sense.
> It's simply typedef of gint (int), so assignmnet:
> mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) is valid for compiler but
> in our case it makes a bug. So normalization (double negation) in assignment:
> mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH) preserves that
> "mce_bt_set" will receive only TRUE or FALSE value.
> ---
> plugins/maemo6.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks. The patch has been pushed upstream with a much simplified commit
message (the above is really quite complicated to read compared to the
simplicity of the actual fix).
Johan
^ permalink raw reply
* [PATCH] Change "websiteUrl" query field to more general
From: Rafal Michalski @ 2010-09-30 13:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
"websiteUrl" query field is replaced by more general "url" because
previously web address wasn't downloaded in each case.
---
plugins/phonebook-tracker.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 2d94bc6..c10491d 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -64,7 +64,7 @@
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
- "nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
+ "nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
@@ -116,7 +116,7 @@
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
- "nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
+ "nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
@@ -188,7 +188,7 @@
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
- "nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
+ "nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
@@ -260,7 +260,7 @@
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew)" \
- "nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
+ "nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
@@ -328,7 +328,7 @@
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
- "nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
+ "nco:birthDate(?c) nco:nickname(?c) nco:url(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
@@ -443,7 +443,7 @@
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew)" \
- "nco:birthDate(<%s>) nco:nickname(<%s>) nco:websiteUrl(<%s>) " \
+ "nco:birthDate(<%s>) nco:nickname(<%s>) nco:url(<%s>) " \
"nco:photo(<%s>) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 1/2] Bluetooth: Replace hard code of configuration flag with self-comment macro.
From: Gustavo F. Padovan @ 2010-09-30 13:56 UTC (permalink / raw)
To: Haijun.Liu; +Cc: linux-bluetooth, ville.tervo, dan.tian, suraj
In-Reply-To: <1285836760-3234-1-git-send-email-haijun.liu@atheros.com>
Hi Haijun,
* Haijun.Liu <haijun.liu@atheros.com> [2010-09-30 16:52:39 +0800]:
>
> Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
> ---
> net/bluetooth/l2cap_core.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Your patch doesn't build:
net/bluetooth/l2cap_core.c: In function 'l2cap_config_req':
net/bluetooth/l2cap_core.c:2988: error: 'L2CAP_CONF_FLAG_CONT'
undeclared (first use in this function)
net/bluetooth/l2cap_core.c:2988: error: (Each undeclared identifier is
reported only once
net/bluetooth/l2cap_core.c:2988: error: for each function it appears
in.)
net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp':
net/bluetooth/l2cap_core.c:3096: error: 'L2CAP_CONF_FLAG_CONT'
undeclared (first use in this function)
You also have to fix your commit subject, it would be good if you can do
it with 50 characters, but never overstep the 72 characters. If need to
add more info the commit message is there for you ;)
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Update conf_state with L2CAP_CONF_REQ_SENT before send config_req out in l2cap_config_req().
From: Gustavo F. Padovan @ 2010-09-30 14:00 UTC (permalink / raw)
To: Haijun.Liu; +Cc: linux-bluetooth, ville.tervo, dan.tian, suraj
In-Reply-To: <1285836760-3234-2-git-send-email-haijun.liu@atheros.com>
Hi Haijun,
* Haijun.Liu <haijun.liu@atheros.com> [2010-09-30 16:52:40 +0800]:
>
> Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
> ---
> net/bluetooth/l2cap_core.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 279f98a..9e788c2 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
Patch has been applied to my bluetooth-next-2.6 tree with modifications
to the commit message and subject. Next time pay attention to not
overstep the 72 characters in the commit subject and do not add a "." in
the end of your subject. Thanks.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
From: Claudio Takahasi @ 2010-09-30 14:24 UTC (permalink / raw)
To: BlueZ development; +Cc: CLAUDIO TAKAHASI
The following changes since commit b5c556ef59a9a8318b239453c3d4a8aad951689f:
Move adapter address reading to hciops (2010-09-29 16:34:55 +0300)
are available in the git repository at:
git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
Bruna Moreira (1):
Use bt_io_connect in gatttool
Claudio Takahasi (4):
Add L2CAP fixed channels support for BTIO
Add characteristic SetProperty implementation
Fix invalid read and memory leak in the attribute server
Fix left open socket warning for attribute server
Gustavo F. Padovan (1):
l2test: add support to the fixed channels
Vinicius Costa Gomes (5):
Fix filtering out LE events
Add support for LE connections to gatttool
Add support for LE connections to the GATT server
Fix ValueChanged not being called on registered agents
Add "Services" property in the org.bluez.Device interface
Makefile.am | 2 +-
attrib/client.c | 122 +++++++++++++++++++++++++++++++++++++++------------
attrib/client.h | 5 +-
attrib/gatttool.c | 121 +++++++++++++++-----------------------------------
attrib/manager.c | 12 +----
btio/btio.c | 37 +++++++++++----
btio/btio.h | 1 +
src/adapter.c | 3 +
src/attrib-server.c | 29 ++++++++++--
src/device.c | 29 ++++++++++--
src/device.h | 1 +
src/security.c | 1 +
test/l2test.c | 26 +++++++++--
13 files changed, 238 insertions(+), 151 deletions(-)
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Claudio Takahasi @ 2010-09-30 14:28 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <20100930073938.GA6964@jh-x301>
On Thu, Sep 30, 2010 at 4:39 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Wed, Sep 29, 2010, Claudio Takahasi wrote:
>> StartDiscovery() triggers all the process. The adapter type: BR/EDR
>> only/LE only or dual mode is hidden from the higher layers.
>> So, your suggestion it try to hide all discovery details inside the
>> hciops as much as possible?
>
> That was the idea yes, but I'm not 100% sure that it's the best
> approach. Another question is also how do we want to represent this with
> the new management interface. Should the kernel do it "all" through a
> single request from userspace or should userspace control the separate
> BR/EDR and LE discoveries. If it's the former, then having a single
> adapter_ops callback makes sense. If it's the later then we should
> probably have two separate ones. Either way I now realize that to
> implement this with a single callback we'd need to have the HCI event
> processing moved over to hciops and that's not something that will
> happen very quickly. So maybe it's better to have these as two separate
> adapter_ops callbacks for now.
>
> Johan
>
Another point is: scanning needs to be disabled "actively", it is not
possible to inform a scanning length like inquiry, it is necessary to
create a timeout to disable the scanning. Joining inquiry and scanning
inside a single adapter_ops callback will be hard to control the
discovery procedure "states". So for now, I prefer two separate
callbacks due the scanning timeout and HCI events processing.
However, for the new management interface, one single request seems to
be more appropriate but extra requests will be necessary to setup the
scan and inquiry parameters.
Claudio
^ permalink raw reply
* Re: [PATCH] Fix handlig for gboolean mce_bt_set field
From: Anderson Lizardo @ 2010-09-30 15:15 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Rafal Michalski, linux-bluetooth
In-Reply-To: <20100930085136.GC3048@vigoh>
On Thu, Sep 30, 2010 at 4:51 AM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
>> diff --git a/plugins/maemo6.c b/plugins/maemo6.c
>> index c96731d..45d96b8 100644
>> --- a/plugins/maemo6.c
>> +++ b/plugins/maemo6.c
>> @@ -71,7 +71,8 @@ static gboolean mce_signal_callback(DBusConnection *connection,
>>
>> /* set the adapter according to the mce signal
>> and remember the value */
>> - mce_bt_set = sigvalue & MCE_RADIO_STATE_BLUETOOTH;
>> + mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) ==
>> + MCE_RADIO_STATE_BLUETOOTH;
>
> Alternatively you can do
> mce_bt_set = !!(sigvalue & MCE_RADIO_STATE_BLUETOOTH)
I'm a bit late, but:
mce_bt_set = (sigvalue & MCE_RADIO_STATE_BLUETOOTH) != 0;
would equally work.
PS: yes, I know it's already commited. :). Interestingly, there is
only one more occurrence of this idiom already in bluez code:
input/device.c: connected = !!g_slist_find_custom(idev->connections, NULL,
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 1/4] Add the Attribute interface to the API
From: Claudio Takahasi @ 2010-09-30 18:48 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, Vinicius Costa Gomes
In-Reply-To: <AANLkTinp8bmy9y-GrQsFPDxdJkPK7n5dixaKsVZtJv0h@mail.gmail.com>
On Wed, Sep 29, 2010 at 5:00 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Wed, Sep 29, 2010 at 5:52 PM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>>>
>>> What's the motivation of moving this into its own D-Bus interface? I
>>> thought the plan was to abstract both traditional SDP and ATT behind the
>>> same API in which case having this in the Device interface makes more
>>> sense imho.
>>>
>>> Johan
>>>
>>
>> Hi Johan,
>>
>> we forgot the SDP integration plan. Forget this patch.
>>
>> From the implementation point of view, implement inside the attrib
>> client plugin was the easiest way, if we keep this property inside the
>> Device interface a new function needs to be created in device.h to
>> register the available primary services object paths.
>
> Well there is a more complicated way, which is to add support for
> user_data per method/property, so a plugin could directly register
> their methods and properties in e.g. Adapter and Device interfaces. Of
> course this has drawbacks since the API could really became a mess
> with plugins doing there thing carelessly, but in the other hand it
> can greatly simplify the interfaces like Device.Disconnect()
> propagation.
>
> Just a crazy idea I had late in the night :D
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
Please ignore this patch sequence. A proper pull request will be sent
to the ML containing the last 3 patches only.
This patch [PATCH 1/4] will be removed.
Claudio
^ permalink raw reply
* Re: [PATCH] Change "websiteUrl" query field to more general
From: Johan Hedberg @ 2010-09-30 20:22 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1285854113-13649-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Thu, Sep 30, 2010, Rafal Michalski wrote:
> "websiteUrl" query field is replaced by more general "url" because
> previously web address wasn't downloaded in each case.
> ---
> plugins/phonebook-tracker.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
The patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
From: Claudio Takahasi @ 2010-09-30 20:34 UTC (permalink / raw)
To: BlueZ development; +Cc: CLAUDIO TAKAHASI
In-Reply-To: <AANLkTinG4Bpq7uo7v8OrSLjozjJG4XOviGuTnaSbS_Nz@mail.gmail.com>
On Thu, Sep 30, 2010 at 11:24 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> The following changes since commit b5c556ef59a9a8318b239453c3d4a8aad951689f:
>
> Move adapter address reading to hciops (2010-09-29 16:34:55 +0300)
>
> are available in the git repository at:
> git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
>
> Bruna Moreira (1):
> Use bt_io_connect in gatttool
>
> Claudio Takahasi (4):
> Add L2CAP fixed channels support for BTIO
> Add characteristic SetProperty implementation
> Fix invalid read and memory leak in the attribute server
> Fix left open socket warning for attribute server
>
> Gustavo F. Padovan (1):
> l2test: add support to the fixed channels
>
> Vinicius Costa Gomes (5):
> Fix filtering out LE events
> Add support for LE connections to gatttool
> Add support for LE connections to the GATT server
> Fix ValueChanged not being called on registered agents
> Add "Services" property in the org.bluez.Device interface
>
> Makefile.am | 2 +-
> attrib/client.c | 122 +++++++++++++++++++++++++++++++++++++++------------
> attrib/client.h | 5 +-
> attrib/gatttool.c | 121 +++++++++++++++-----------------------------------
> attrib/manager.c | 12 +----
> btio/btio.c | 37 +++++++++++----
> btio/btio.h | 1 +
> src/adapter.c | 3 +
> src/attrib-server.c | 29 ++++++++++--
> src/device.c | 29 ++++++++++--
> src/device.h | 1 +
> src/security.c | 1 +
> test/l2test.c | 26 +++++++++--
> 13 files changed, 238 insertions(+), 151 deletions(-)
>
New pull request, patches rebased!
The following changes since commit f7b4b3fcd1190d231b864730c821b98fb945e439:
Move connection list fetching to hciops (2010-09-30 22:12:37 +0300)
are available in the git repository at:
git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
Bruna Moreira (1):
Use bt_io_connect in gatttool
Claudio Takahasi (4):
Add L2CAP fixed channels support for BTIO
Add characteristic SetProperty implementation
Fix invalid read and memory leak in the attribute server
Fix left open socket warning for attribute server
Gustavo F. Padovan (1):
l2test: add support to the fixed channels
Vinicius Costa Gomes (5):
Fix filtering out LE events
Add support for LE connections to gatttool
Add support for LE connections to the GATT server
Fix ValueChanged not being called on registered agents
Add "Services" property in the org.bluez.Device interface
Makefile.am | 2 +-
attrib/client.c | 122 +++++++++++++++++++++++++++++++++++++++------------
attrib/client.h | 5 +-
attrib/gatttool.c | 121 +++++++++++++++-----------------------------------
attrib/manager.c | 12 +----
btio/btio.c | 37 +++++++++++----
btio/btio.h | 1 +
src/adapter.c | 3 +
src/attrib-server.c | 29 ++++++++++--
src/device.c | 29 ++++++++++--
src/device.h | 1 +
src/security.c | 1 +
test/l2test.c | 26 +++++++++--
13 files changed, 238 insertions(+), 151 deletions(-)
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
From: Johan Hedberg @ 2010-09-30 21:04 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTi=m3MrgF=mJ54wMVH+0b5O9jwciw-HcChpF7HiG@mail.gmail.com>
Hi Claudio,
On Thu, Sep 30, 2010, Claudio Takahasi wrote:
> New pull request, patches rebased!
>
> The following changes since commit f7b4b3fcd1190d231b864730c821b98fb945e439:
>
> Move connection list fetching to hciops (2010-09-30 22:12:37 +0300)
>
> are available in the git repository at:
> git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-attrib
>
> Bruna Moreira (1):
> Use bt_io_connect in gatttool
>
> Claudio Takahasi (4):
> Add L2CAP fixed channels support for BTIO
> Add characteristic SetProperty implementation
> Fix invalid read and memory leak in the attribute server
> Fix left open socket warning for attribute server
>
> Gustavo F. Padovan (1):
> l2test: add support to the fixed channels
>
> Vinicius Costa Gomes (5):
> Fix filtering out LE events
> Add support for LE connections to gatttool
> Add support for LE connections to the GATT server
> Fix ValueChanged not being called on registered agents
> Add "Services" property in the org.bluez.Device interface
>
> Makefile.am | 2 +-
> attrib/client.c | 122 +++++++++++++++++++++++++++++++++++++++------------
> attrib/client.h | 5 +-
> attrib/gatttool.c | 121 +++++++++++++++-----------------------------------
> attrib/manager.c | 12 +----
> btio/btio.c | 37 +++++++++++----
> btio/btio.h | 1 +
> src/adapter.c | 3 +
> src/attrib-server.c | 29 ++++++++++--
> src/device.c | 29 ++++++++++--
> src/device.h | 1 +
> src/security.c | 1 +
> test/l2test.c | 26 +++++++++--
> 13 files changed, 238 insertions(+), 151 deletions(-)
Thanks. All patches have been pushed upstream.
Johan
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Claudio Takahasi @ 2010-09-30 21:51 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <AANLkTikADcqHYfOjmRQVEDdPuU9mrGVvAVGNUdRTsQcd@mail.gmail.com>
On Thu, Sep 30, 2010 at 11:28 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> On Thu, Sep 30, 2010 at 4:39 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi Claudio,
>>
>> On Wed, Sep 29, 2010, Claudio Takahasi wrote:
>>> StartDiscovery() triggers all the process. The adapter type: BR/EDR
>>> only/LE only or dual mode is hidden from the higher layers.
>>> So, your suggestion it try to hide all discovery details inside the
>>> hciops as much as possible?
>>
>> That was the idea yes, but I'm not 100% sure that it's the best
>> approach. Another question is also how do we want to represent this with
>> the new management interface. Should the kernel do it "all" through a
>> single request from userspace or should userspace control the separate
>> BR/EDR and LE discoveries. If it's the former, then having a single
>> adapter_ops callback makes sense. If it's the later then we should
>> probably have two separate ones. Either way I now realize that to
>> implement this with a single callback we'd need to have the HCI event
>> processing moved over to hciops and that's not something that will
>> happen very quickly. So maybe it's better to have these as two separate
>> adapter_ops callbacks for now.
>>
>> Johan
>>
>
> Another point is: scanning needs to be disabled "actively", it is not
> possible to inform a scanning length like inquiry, it is necessary to
> create a timeout to disable the scanning. Joining inquiry and scanning
> inside a single adapter_ops callback will be hard to control the
> discovery procedure "states". So for now, I prefer two separate
> callbacks due the scanning timeout and HCI events processing.
>
> However, for the new management interface, one single request seems to
> be more appropriate but extra requests will be necessary to setup the
> scan and inquiry parameters.
>
> Claudio
>
New pull request! Patches rebased and a new hciops callback function
has been added to export the write LE host supported command.
The following changes since commit 3a8386d428e385d97b95a890623362321a7e3a19:
Fix left open socket warning for attribute server (2010-09-30 17:26:55 -0300)
are available in the git repository at:
git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
Claudio Takahasi (23):
Add LE start and stop scanning
Remove RSSI field from the advertising report event
Decoding the RSSI parameter from the advertising report event
Send Discovering property "FALSE" when the interleave finishes
Add length argument on hciops start discovery function
Stop inquiry using the length parameter
Fix remote name resolution for interleave discovery
Add Write LE host supported function
Set the LE host supported and disable simultaneous LE and BR/EDR flags
Add extended feature mask constants definition
Read the local extended features
Stop LE scanning when discovery is suspended
Rename hciops {start, stop}_discovery to {start, stop}_inquiry
Don't enter on interleave mode if there isn't active sessions
Code cleanup: improving inquiry logic
Clear the remote device found list in the state transition
Fix periodic inquiry signals
Fixing DeviceDisappeared signal
Postpone discovery if still resolving names
Add adapter discovery type function
Do not send another Discovering TRUE signal if still resolving names
Forcing periodic inquiry exit
Fix interleave scanning
Vinicius Costa Gomes (1):
Add BR/EDR LE interleaved discovery
lib/hci.c | 29 +++++
lib/hci.h | 17 +++-
lib/hci_lib.h | 1 +
plugins/hciops.c | 69 +++++++++++-
src/adapter.c | 301 +++++++++++++++++++++++++++++++++++++-----------------
src/adapter.h | 38 ++++---
src/dbus-hci.c | 45 +++++++--
src/dbus-hci.h | 1 +
src/security.c | 131 ++++++++++++++----------
9 files changed, 449 insertions(+), 183 deletions(-)
^ permalink raw reply
* Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-doc
From: Claudio Takahasi @ 2010-09-30 21:57 UTC (permalink / raw)
To: BlueZ development; +Cc: CLAUDIO TAKAHASI
The following changes since commit 3a8386d428e385d97b95a890623362321a7e3a19:
Fix left open socket warning for attribute server (2010-09-30 17:26:55 -0300)
are available in the git repository at:
git://git.infradead.org/users/cktakahasi/bluez.git for-upstream-doc
Claudio Takahasi (3):
Add GetProperties method in the Device service hierarchy
Add SetProperty in the Device characteristic hierarchy
Fix object path in the register watcher method
doc/attribute-api.txt | 46 ++++++++++++++--------------------------------
1 files changed, 14 insertions(+), 32 deletions(-)
^ permalink raw reply
* Re: pull-request: bluetooth-2.6 2010-09-27
From: David Miller @ 2010-10-01 0:26 UTC (permalink / raw)
To: padovan; +Cc: linville, marcel, linux-bluetooth, netdev
In-Reply-To: <20100928224941.GA19409@vigoh>
From: "Gustavo F. Padovan" <padovan@profusion.mobi>
Date: Tue, 28 Sep 2010 19:49:41 -0300
> Actually sk_stream_wait_memory is another point why it's safe to release
> the lock and block waiting for memory. We've been doing that safely in
> protocols like TCP, SCTP and DCCP for a long time.
Do you notice what TCP does when sk_stream_wait_memory() returns?
It reloads all volatile state that might have changed in the socket
while the lock was dropped.
For example, TCP will reload the current MSS that can change
asynchronously while we don't have the socket lock.
^ permalink raw reply
* Re: pull-request: bluetooth-2.6 2010-09-27
From: Gustavo F. Padovan @ 2010-10-01 1:22 UTC (permalink / raw)
To: David Miller; +Cc: linville, marcel, linux-bluetooth, netdev
In-Reply-To: <20100930.172657.123994559.davem@davemloft.net>
Hi Dave,
* David Miller <davem@davemloft.net> [2010-09-30 17:26:57 -0700]:
> From: "Gustavo F. Padovan" <padovan@profusion.mobi>
> Date: Tue, 28 Sep 2010 19:49:41 -0300
>
> > Actually sk_stream_wait_memory is another point why it's safe to release
> > the lock and block waiting for memory. We've been doing that safely in
> > protocols like TCP, SCTP and DCCP for a long time.
>
> Do you notice what TCP does when sk_stream_wait_memory() returns?
>
> It reloads all volatile state that might have changed in the socket
> while the lock was dropped.
>
> For example, TCP will reload the current MSS that can change
> asynchronously while we don't have the socket lock.
I got your point. And what I tried to say in the last e-mail is that
ERTM doesn't have such volatile states that need to restore after get
the lock back. The others code path it affect are very simple and also
doesn't have such problem. So we are safe against asynchronous changes.
We obvious have volatiles states, but the code paths where
bt_skb_send_alloc() is used doesn't rely on that states. I'm seeing no
problem on release the lock, alloc memory, and lock it again.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* How to ensure pairing is done
From: Yedire, Sandeep @ 2010-10-01 6:25 UTC (permalink / raw)
To: linux-bluetooth
Hi there,
I am currently working with A2DP. I have installed Bluez-4.69 for
target(MIPS). I have also set-up dbus-daemon and bluetoothd deamon. By
executing the test programs on Bluez-4.69
./l2test -c <bdaddr>
I get below error message
l2test[476]: Can't connect: Connection refused (146)
I could connect the device by SOCK_RAW mode and able to send. But in
SOCK_SEQPACKET, I am unable to connect and will get the above error.
Now my doubt: How do I ensure pairing is done properly?
I followed these steps below for dbus-daemon, bluetoothd
<>dbus-uuidgen --ensure
<>export DBUG_VERBOSE=1
<>adduser -DH messagebus
<>addgroup messagebus messagebus
<>dbus-daemon --system
<>bluetoothd -d
<>ps -ef to check dbus-daemon, bluetoothd running
<>./agent 0000 <baddr>
After executing the last command (./agent 000 <baddr>) the headset
changes its blinking pattern from red-blue blink to blue-blue blink.
The same behaviour happens with my mobile during pairing with my
mobile.
Please let me know if any one is aware why in SOCK_SEQPACKET mode,
connect system call will fail.
What is the cause of this error? I get <146> connection refused.
How to ensure this pairing is done?
below is log message attached during execution of (./agent 0000 <baddr>)
________________________________________________________________
./agent --adapter hci0 0000 00:1E:7C:00:B7:AD
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
Pincode request for device /org/bluez/379/hci0/dev_00_1E_7C_00_B7_AD
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
lockd: cannot monitor 136.170.194.184
lockd: failed to monitor 136.170.194.184
Agent has been released
<>
Regards,
Sandeep.Yedire
----------------------------------------------------------
T.Jefferson, 'Victory and defeat are each of the same price"
^ permalink raw reply
* RE: How to ensure pairing is done
From: Waldemar.Rymarkiewicz @ 2010-10-01 6:51 UTC (permalink / raw)
To: syedire, linux-bluetooth
In-Reply-To: <AANLkTimDw_obL=cV-CjU5OPCH+PiTqSyQ+0JTy1o+=3Q@mail.gmail.com>
Hi
>I get below error message
>l2test[476]: Can't connect: Connection refused (146)
>
I suggest to analyse hcidump first.
Regards,
/Waldek
^ 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