* [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: 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 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 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
* 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
* [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: 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
* 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: [PATCH 1/2] Add master/slave parsing for le_conn_complete event
From: Johan Hedberg @ 2010-09-30 7:31 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1285768581-19654-1-git-send-email-ville.tervo@nokia.com>
Hi Ville,
On Wed, Sep 29, 2010, Ville Tervo wrote:
> ---
> parser/hci.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Thanks for the patch. I've pushed it to the upstream hcidump tree with
the following whitespace fix:
> + evt->status, btohs(evt->handle), evt->role?"slave":"master");
It should be 'evt->role ? "slave" : "master"' i.e. you've got some
missing spaces there.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Replace hard code of configuration continuation flag.
From: Gustavo F. Padovan @ 2010-09-30 7:24 UTC (permalink / raw)
To: haijun liu
Cc: Ville Tervo, linux-bluetooth@vger.kernel.org, Mat Martineau,
dantian.ip
In-Reply-To: <AANLkTin8muojCiTZ+1MZL7GLDs45MwsZBErmvzVaZy4a@mail.gmail.com>
* haijun liu <liuhaijun.er@gmail.com> [2010-09-29 21:33:09 +0800]:
> Replace hard code of configuration continuation flag with self-comment macro.
>
>
> Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
> ---
> net/bluetooth/l2cap_core.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
This one is also corrupted.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Update conf_state before send config_req out.
From: Gustavo F. Padovan @ 2010-09-30 7:23 UTC (permalink / raw)
To: haijun liu; +Cc: linux-bluetooth@vger.kernel.org, dantian.ip
In-Reply-To: <AANLkTikz3VTGtL5PY2nAXKO1z_XD4ROEZyUV3JXsrstn@mail.gmail.com>
Hi Haijun,
* haijun liu <liuhaijun.er@gmail.com> [2010-09-29 19:11:29 +0800]:
> Update conf_state with L2CAP_CONF_REQ_SENT before send
> config_req out in l2cap_config_req().
>
>
> Signed-off-by: Haijun.Liu <haijun.liu@atheros.com>
> ---
> net/bluetooth/l2cap_core.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Still corrupted:
Applying: Bluetooth: Update conf_state before send config_req out.
fatal: corrupt patch at line 10
Patch failed at 0001 Bluetooth: Update conf_state before send config_req
out.
Make sure you can apply your patches sent with git send-email before
sending them to the mailing list. Thanks.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: a2dp, myth, pulse
From: Brad Midgley @ 2010-09-29 20:50 UTC (permalink / raw)
To: Sander van Grieken; +Cc: linux-bluetooth
In-Reply-To: <201009291708.01026.sander@outrightsolutions.nl>
Sander
> I suppose this has to be enabled in the kernel, or loaded as a module, then udev will pick
> it up. On my Ubuntu 10.10 it is enabled in the kernel.
ok, so this is a bug in ubuntu before 10.10. for now I put uinput in
/etc/modules. see
https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/584812
the key names coming through now as reported by irw:
a3 0 KEY_NEXTSONG event9
a5 0 KEY_PREVIOUSSONG event9
c9 0 KEY_PAUSECD event9
c8 0 KEY_PLAYCD event9
unfortunately there isn't a clear way to merge a udp/hdhomerun remote
coming in on lircd with avrcp events from inputlircd. I'll take it up
with the lirc folks and summarize here later. There is also eventlirc
that can deal with dynamic devices better but it still can't do udp.
Wouldn't it be nice if lirc simply used d-bus?
--
Brad Midgley
^ permalink raw reply
* Re: [PATCH] Fix not detecting errors on small files
From: Luiz Augusto von Dentz @ 2010-09-29 20:26 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1285770456-8457-1-git-send-email-luiz.dentz@gmail.com>
Hi,
On Wed, Sep 29, 2010 at 5:27 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> When flushing the last part of buffer/file we have to wait for response
> since that can contain errors.
>
> To fix this gw_obex_xfer_close is called in order to force gwobex to
> resume the request and return any error related to it.
> ---
> client/transfer.c | 9 +++++++--
> 1 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/client/transfer.c b/client/transfer.c
> index 8ceb36f..e5fcfcc 100644
> --- a/client/transfer.c
> +++ b/client/transfer.c
> @@ -360,7 +360,7 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
> {
> struct transfer_data *transfer = user_data;
> struct transfer_callback *callback = transfer->callback;
> - gint written, err = 0;
> + gint written = 0, err = 0;
>
> if (transfer->buffer_len == 0) {
> transfer->buffer_len = DEFAULT_BUFFER_SIZE;
> @@ -380,7 +380,12 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
> transfer->filled += len;
>
> if (transfer->filled == 0) {
> - gw_obex_xfer_flush(xfer, &err);
> + if (written > 0) {
> + gw_obex_xfer_flush(xfer, &err);
> + return;
> + }
> +
> + gw_obex_xfer_close(xfer, &err);
> goto done;
> }
Actually I might simplify even more by not returning when flushing the
transfer, at that point we don't have anything else to write so
returning and waiting for gwobex to call it again is just a wait of
time, so please ignore this for now.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [ANN] Atheros Linux Bluetooth drivers home page
From: Luis R. Rodriguez @ 2010-09-29 20:05 UTC (permalink / raw)
To: linux-bluetooth
Cc: linux-wireless, linux-kernel, Ken Steck,
Shanmugamkamatchi Balashanmugam
I noted a while ago Bluetooth seemed to lack a wiki-based home and if
we can just borrow the existing wiki on wireless.kernel.org and saw no
opposition so started adding some related Bluetooth documentation like
Bluetooth-Coexistance [1]. I now found a need to document some pending
patches for ath3k [2] so started a Linux Atheros Bluetooth drivers
page [3] with just one reference to ath3k [4]. Goal is also to
motivate and welcome more developers to document more of the Bluetooth
subsystem and drivers on wireless.kernel.org. If you have a Bluetooth
drivers you'd like to document please feel free to add it to the
Bluetooth Drivers section [5] BT3.0 stuff might be a really good
candidate to be documented here. I tried modifying the site a bit to
add Bluetooth Specific navigation bar but failed, will wait on
Johannes to figure that stuff out.
Luis
[1] http://wireless.kernel.org/en/users/Documentation/Bluetooth-coexistence
[2] http://marc.info/?l=linux-bluetooth&m=128536965702436&w=2
[3] http://wireless.kernel.org/en/users/Drivers/Atheros-BT
[4] http://wireless.kernel.org/en/users/Drivers/ath3k
[5] http://wireless.kernel.org/en/users/Drivers-bluetooth
^ permalink raw reply
* Re: [PATCH 1/4] Add the Attribute interface to the API
From: Luiz Augusto von Dentz @ 2010-09-29 20:00 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth, Vinicius Costa Gomes
In-Reply-To: <AANLkTi=1hKSL+2-DJ4SJkZJ+TaAzP1BUSh4FbiT=xg4g@mail.gmail.com>
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
^ permalink raw reply
* Re: RFC: btusb firmware load help
From: Luis R. Rodriguez @ 2010-09-29 19:40 UTC (permalink / raw)
To: Marcel Holtmann, Ken Steck, Shanmugamkamatchi Balashanmugam
Cc: linux-bluetooth, linux-kernel, linux-wireless, Deepak Dhamdhere,
Sree Durbha
In-Reply-To: <20100924230730.GB6566@tux>
On Fri, Sep 24, 2010 at 4:07 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Marcel, I was just poked about this thread:
>
> http://www.spinics.net/lists/linux-bluetooth/msg06087.html
>
> The hack is required because our BT hardware does not accept HCI commands
> when the device is plugged in. If I understood your position you did not
> want to accept the patch because our BT USB devices are violating the
> specification by not acceping HCI commands and yet claiming to be BT
> devices, is that right?
>
> This position seems perfectly reasonable, and if it is violating the
> specification this needs to be fixed in hardware for future devices. But
> what is done is done, and we need to support existing customers with
> current hardware, can you provide some recommendation as to an alternative
> approach to resolve this upstream?
Marcel some attention to this would be greatly appreciated.
> Without a patch like the one suggested Atheros' Bluetooth USB devices are
> essentially not functional at all. I am in hopes we can come to some agreement
> how to deal with a hardware quirk for now while we nag at our hardware team
> to consider changing the way our devices work.
I have gotten clarifications from Ken Steck that this issue is only
present on AR3011 chips used in the SFLASH configuration. AR3012 will
not have this issue.
> Someone from the Atheros BT team: can you send me the same patch to be
> applied into compat-wireless under the linux-next-pending/ directory ?
> That is, send me a patch which will apply onto compat-wireless.
> This way we can actually get our hardware functional to customers while
> we try to look for a better alternative directly upstream. You will
> also need to document this issue on the wiki. I recommend you document
> this here:
>
> http://wireless.kernel.org/en/users/Drivers/ath3k
>
> That is, create a new wiki page there for the driver and the things
> needed for it. Once I get the patch into compat-wireless we can
> refer users/customers to the compat-wireless stable releases with
> the linux-next-pending/ patch you give to me applied.
I saw no takers on this.. so I just created the page myself.
> Someone from the Atheros BT team: does the patch currently handle
> suspend/resume?
Shanmugamkamatchi has noted to me he will be sending me this patch
soon and it also supports suspend/resume properly, however, I would
like to resolve this upstream.
Marcel, please let us know what path you recommend we take for this.
Luis
^ permalink raw reply
* SCO Socket input connection.
From: Pepe Aracil @ 2010-09-29 16:27 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTinZS1EbbW7XGYVHMdA0M5tMss8RuYwtiNoM5m_M@mail.gmail.com>
Hello.
I'm developing embedded alarm system with hands free bluetooth profile.
Some months ago this code in python was working OK. (i don't remember
bluez version)
self.sco = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_SEQPACKET,
socket.BTPROTO_SCO)
print "socket SCO opened."
self.sco.bind("00:00:00:00:00:00")
self.sco.listen(1)
sck, mac = self.sco.accept()
When receiving a call on my cell phone and took down (via rfcomm HF
connecton) , SCO connection was produced from the phone to pc.
Now this connection fails.
I added to audio.conf Disable=Headset,Control,Gateway to disable
SCO Listening from bluetoothd but with no result :(
The only thing that works is to launch this python code before bluetoothd.
Some thing is touched by bluetoothd that blocks SCO incoming
connections for other apps. ¿What?
I try compile with --disable-audio with no results.
Thanks. and sorry for may horrible English.
^ permalink raw reply
* Re: a2dp, myth, pulse
From: Sander van Grieken @ 2010-09-29 15:08 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=voJHxhTa4VXNnhUBm2v8ouX6cQNWgToip=wVi@mail.gmail.com>
On Wednesday 29 September 2010 17:01:06 Brad Midgley wrote:
> Sander,
>
> >> Control is enabled by default in 4.60, is there anything I can check
> >> to see why I don't see any log messages about avrcp, no input device
> >> appear, nothing logged, etc?
> >
> > Currently there is support in bluez to act as a AVRCP target, and it will deliver
these
> > events through the input layer. No new input device will appear, it will go through
> > /dev/uinput (which I think you can open for reading then)
>
> Thanks for the tip. I didn't have /dev/uinput or /dev/input/uinput so
> I mknod'd it temporarily (mknod /dev/input/uinput c 10 233). Trying to
> get anything out of it while streaming gives me "No such device".
I suppose this has to be enabled in the kernel, or loaded as a module, then udev will pick
it up. On my Ubuntu 10.10 it is enabled in the kernel.
--
Sander
^ permalink raw reply
* Re: a2dp, myth, pulse
From: Brad Midgley @ 2010-09-29 15:01 UTC (permalink / raw)
To: Sander van Grieken; +Cc: linux-bluetooth
In-Reply-To: <201009291337.40197.sander@outrightsolutions.nl>
Sander,
>> Control is enabled by default in 4.60, is there anything I can check
>> to see why I don't see any log messages about avrcp, no input device
>> appear, nothing logged, etc?
>
> Currently there is support in bluez to act as a AVRCP target, and it will deliver these
> events through the input layer. No new input device will appear, it will go through
> /dev/uinput (which I think you can open for reading then)
Thanks for the tip. I didn't have /dev/uinput or /dev/input/uinput so
I mknod'd it temporarily (mknod /dev/input/uinput c 10 233). Trying to
get anything out of it while streaming gives me "No such device". Is
there somewhere else I can look to debug what bluez is doing to see if
it's trying to handle avrcp events? Is there any d-bus api for
examining them? hcidump shows avrcp messages going across, I just
don't know what bluetoothd is doing with them.
thanks all
--
Brad Midgley
^ permalink raw reply
* Re: [PATCH 1/4] Add the Attribute interface to the API
From: Claudio Takahasi @ 2010-09-29 14:52 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth, Vinicius Costa Gomes
In-Reply-To: <20100929134908.GB19362@jh-x301>
On Wed, Sep 29, 2010 at 10:49 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> On Tue, Sep 28, 2010, Claudio Takahasi wrote:
>> +Attribute Protocol hierarchy
>> +============================
>> +
>> +Service org.bluez
>> +Interface org.bluez.Attribute
>> +Object path [prefix]/{hci0}/{device0}
>> +
>> +
>> +Methods dict GetProperties()
>> +
>> + Returns all properties for the interface. See the
>> + properties section for available properties.
>> +
>> +Properties array{object} Services
>> +
>> + List of all the Primary Services that this device
>> + implements.
>> +
>> +
>> Device Service hierarchy
>> ========================
>>
>> diff --git a/doc/device-api.txt b/doc/device-api.txt
>> index 95b5b22..b818299 100644
>> --- a/doc/device-api.txt
>> +++ b/doc/device-api.txt
>> @@ -139,10 +139,6 @@ Properties string Address [readonly]
>> List of 128-bit UUIDs that represents the available
>> remote services.
>>
>> - array{object} Services [readonly]
>> -
>> - List of characteristics based services.
>> -
>> boolean Paired [readonly]
>>
>> Indicates if the remote device is paired.
>
> 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.
Claudio.
^ permalink raw reply
* Re: Spurious authentication request?
From: Daniel Örstadius @ 2010-09-29 14:39 UTC (permalink / raw)
To: Daniel Örstadius, linux-bluetooth
In-Reply-To: <20100928081513.GA20800@jh-x301>
Hi Johan,
On Tue, Sep 28, 2010 at 11:15 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Daniel,
>
> On Mon, Sep 27, 2010, Daniel Örstadius wrote:
>> Occasionally when pairing with a headset BlueZ issues what looks
>> to be an unnecessary "Authentication Requested" after
>> receiving "Auth Complete" and "Simple Pairing Complete".
>>
>> 2010-09-22 11:23:45.282348 > HCI Event: Auth Complete (0x06) plen 3
>> status 0x00 handle 2
>> 2010-09-22 11:23:45.282378 < HCI Command: Set Connection Encryption
>> (0x01|0x0013) plen 3
>> handle 2 encrypt 0x01
>> [..]
>> 2010-09-22 11:23:45.363646 < HCI Command: Authentication Requested
>> (0x01|0x0011) plen 2
>> handle 2
>>
>> This request is coming from bonding_connect_cb and occurs if that
>> callback happens to be executed before the function
>> hcid_dbus_bonding_process_complete (triggered by the auth complete
>> event). The order between those functions might have been affected
>> by this patch
>>
>> http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=be35d00671519b8d92361c2caad9abeedda151f8
>>
>> The request for authentication seems to be used for legacy pairing and
>> should probably not be made for simple pairing. Also, it might be
>> inconsistent that the kernel issues "Authentication Requested" for
>> simple pairing, but bluetoothd does it for legacy?
>>
>> I guess enclosing the call in a check for legacy pairing would
>> work, if that information is or can be made available to
>> bluetoothd.
>>
>> Have I understood the situation correctly and if so, what would
>> be a good way to fix this issue?
>
> The reason why the extra authentication request is there is to deal with
> old kernels that do not initiate authentication by themselves. So
> checking for SSP vs legacy pairing wouldn't work.
>
Ok, thanks.
In newer kernels the auth req seems to be triggered in
hci_event.c/hci_remote_features_evt() only if both sides support SSP.
For legacy pairing it's up to bluetoothd to request authentication.
Because of that, there is an unnecessary "auth req" from bluetoothd in 2.1
pairing if bonding_connect_cb gets called before device_bonding_complete.
The latter function clears the bonding_req in btd_device, causing the former
to return directly.
I think this is the relation between HCI events and those functions in
bluetoothd: [*]
auth complete evt => device_bonding_complete
encrypt change evt => bonding_connect_cb
"auth complete" occurs before "encrypt change", but its corresponding
function doesn't always get called first (maybe because of the low priority
on the raw HCI socket watch in security.c).
As you mentioned offline it might work to query the kernel to find out if
the device is authenticated. I don't know what should be considered to
be the root cause of the issue.
/Daniel
[*] From looking at the sources, the kernel seems respond to the "auth
complete" event with a request for encryption. Could be that
bonding_connect_cb in bluetoothd gets called when the kernel receives
the "encrypt change" event (since the socket state goes to
BT_CONNECTED at that point and bluetoothd is watching the socket for
G_IO_OUT via glib).
^ permalink raw reply
* [PATCH] Fix not detecting errors on small files
From: Luiz Augusto von Dentz @ 2010-09-29 14:27 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
When flushing the last part of buffer/file we have to wait for response
since that can contain errors.
To fix this gw_obex_xfer_close is called in order to force gwobex to
resume the request and return any error related to it.
---
client/transfer.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/client/transfer.c b/client/transfer.c
index 8ceb36f..e5fcfcc 100644
--- a/client/transfer.c
+++ b/client/transfer.c
@@ -360,7 +360,7 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
{
struct transfer_data *transfer = user_data;
struct transfer_callback *callback = transfer->callback;
- gint written, err = 0;
+ gint written = 0, err = 0;
if (transfer->buffer_len == 0) {
transfer->buffer_len = DEFAULT_BUFFER_SIZE;
@@ -380,7 +380,12 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
transfer->filled += len;
if (transfer->filled == 0) {
- gw_obex_xfer_flush(xfer, &err);
+ if (written > 0) {
+ gw_obex_xfer_flush(xfer, &err);
+ return;
+ }
+
+ gw_obex_xfer_close(xfer, &err);
goto done;
}
--
1.7.1
^ permalink raw reply related
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Claudio Takahasi @ 2010-09-29 14:05 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <20100929134521.GA19362@jh-x301>
On Wed, Sep 29, 2010 at 10:45 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Thu, Sep 23, 2010, Claudio Takahasi wrote:
>> Rename hciops {start, stop}_discovery to {start, stop}_inquiry
>
> I'm not sure about this patch. Wasn't the idea to hide the device
> discovery details from the higher layers? I.e. the method could be
> called discovery and it'd take care of both BR/EDR and LE discovery
> methods.
>
> Johan
>
Hi Johan,
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? I am not sure at the moment if it is
possible, but we can try. We need to clean the code anyway in order to
have a "smooth" migration to the new Bluetooth Management Interface.
Regards,
Claudio
^ permalink raw reply
* [PATCH 2/2] Fix missing comma in cmd_le_str
From: Ville Tervo @ 2010-09-29 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1285768581-19654-1-git-send-email-ville.tervo@nokia.com>
---
parser/hci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/parser/hci.c b/parser/hci.c
index 7f23605..863afd9 100644
--- a/parser/hci.c
+++ b/parser/hci.c
@@ -381,7 +381,7 @@ static char *cmd_testing_str[CMD_TESTING_NUM + 1] = {
"Unknown",
};
-#define CMD_LE_NUM 30
+#define CMD_LE_NUM 31
static char *cmd_le_str[CMD_LE_NUM + 1] = {
"Unknown",
"LE Set Event Mask",
@@ -403,7 +403,7 @@ static char *cmd_le_str[CMD_LE_NUM + 1] = {
"LE Add Device To White List",
"LE Remove Device From White List",
"LE Connection Update",
- "LE Set Host Channel Classification"
+ "LE Set Host Channel Classification",
"LE Read Channel Map",
"LE Read Remote Used Features",
"LE Encrypt",
--
1.7.1
^ permalink raw reply related
* [PATCH 1/2] Add master/slave parsing for le_conn_complete event
From: Ville Tervo @ 2010-09-29 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
---
parser/hci.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/parser/hci.c b/parser/hci.c
index 250ba58..7f23605 100644
--- a/parser/hci.c
+++ b/parser/hci.c
@@ -3239,7 +3239,8 @@ static inline void evt_le_conn_complete_dump(int level, struct frame *frm)
evt_le_connection_complete *evt = frm->ptr;
p_indent(level, frm);
- printf("status 0x%2.2x handle %d\n", evt->status, btohs(evt->handle));
+ printf("status 0x%2.2x handle %d, role %s\n",
+ evt->status, btohs(evt->handle), evt->role?"slave":"master");
}
static inline void le_meta_ev_dump(int level, struct frame *frm)
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox