* Re: [PATCHes] osso-gwobex patches for review
From: Johan Hedberg @ 2010-02-23 13:48 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1266762470.25029.2195.camel@localhost.localdomain>
Hi Bastien,
On Sun, Feb 21, 2010, Bastien Nocera wrote:
> The first patch fixes a few typos.
Yep, looks good and I've pushed it upstream.
> The second one requires the openobex patches I posted to the list, but
> should fail gracefully if the support does not exist.
This patch has some issues:
> + /* Setup low-level USB */
> + if (!gw_obex_transport_setup_usb(&handle)) {
> + debug("gw_obex_transport_setup_usb() failed, no USB support?\n");
> + return NULL;
> + }
You forget to set *error before returning NULL here.
> + /* Do the transport connection */
> + if (OBEX_InterfaceConnect(handle, iface) < 0) {
> + debug("Could not connect to USB device '%s'\n", dev);
> + if (error)
> + *error = GW_OBEX_ERROR_NO_SERVICE;
> + return NULL;
> + }
This looks like a memory leak since you don't do the same cleanup of ctx->mutex
and ctx as you do in the other failure cases. Maybe the function could use a
"fail" label where you jump to for cleanup tasks?
Besides those issues the patch seems ok'ish.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix service driver selection when WHO header is informed
From: Johan Hedberg @ 2010-02-23 13:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <2d5a2c101002230206r5a945ec0hd8b638f171440a33@mail.gmail.com>
Hi Luiz,
On Tue, Feb 23, 2010, Luiz Augusto von Dentz wrote:
> Drivers which support WHO header should be checked first since they have
> priority e.g. pcsuite over ftp.
> ---
> src/service.c | 10 +++++++---
> 1 files changed, 7 insertions(+), 3 deletions(-)
The patch is now upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Fix pcsuite WHO header
From: Johan Hedberg @ 2010-02-23 13:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <2d5a2c101002230207h3e3f5da8p1917c273fb27943a@mail.gmail.com>
Hi Luiz,
On Tue, Feb 23, 2010, Luiz Augusto von Dentz wrote:
> ---
> plugins/ftp.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
This one's also upstream now. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix double free on AVDTP Abort response
From: Johan Hedberg @ 2010-02-23 14:04 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Daniel Örstadius, linux-bluetooth
In-Reply-To: <2d5a2c101002210953l4ef26078j25f4cc31758b80a7@mail.gmail.com>
Hi Luiz,
On Sun, Feb 21, 2010, Luiz Augusto von Dentz wrote:
> While discussing this problem we find out that our timeout doesn't
> really work as we imagine due to the possibility of abort being
> rejected, so either we don't call any callback on timeout and do it on
> abort response while changing to aborting state (which probably means
> 4-8 sec before we are really able to abort/cancel) or we disconnect as
> the other end seems to not cooperate on aborting.
>
> Btw, we probably should have a smaller timeout for avdtp_abort anyway
> and make sure we call it upon RequestDisconnect not avdtp_close which
> has no priority over the others commands.
Makes sense. Feel free to propose a patch (or multiple patches) for all
this ;)
Johan
^ permalink raw reply
* Re: Automatically connect to Bluetooth devices?
From: Caleb Katz @ 2010-02-23 19:57 UTC (permalink / raw)
To: Linux-Bluetooth
In-Reply-To: <20100222074700.0c6e0b9c@shogun.epicvoyage.org>
Hey,
I've made a little bit of progress. I can add the mouse through the
gnome-bluetooth interface and it will automatically reconnect. Keyboard
bonding does not work that way (it does not seem to accept the PIN when
entered on the keyboard):
bluetoothd[10443]: adapter_get_device(00:02:76:03:3A:EA)
bluetoothd[10443]: adapter_create_device(00:02:76:03:3A:EA)
bluetoothd[10443]: Creating device /org/bluez/10443/hci0/dev_00_02_76_03_3A_EA
bluetoothd[10443]: btd_device_ref(0xb7f3b9c0): ref=1
bluetoothd[10443]: /org/bluez/10443/hci0/dev_00_02_76_03_3A_EA: requesting bonding
bluetoothd[10443]: Temporary agent registered for /org/bluez/10443/hci0/dev_00_02_76_03_3A_EA at :1.54:/org/bluez/agent/wizard
bluetoothd[10443]: adapter_get_device(00:02:76:03:3A:EA)
bluetoothd[10443]: hcid_dbus_bonding_process_complete: status=05
bluetoothd[10443]: adapter_get_device(00:02:76:03:3A:EA)
bluetoothd[10443]: hcid_dbus_bonding_process_complete: no pending auth request
bluetoothd[10443]: Removing temporary device /org/bluez/10443/hci0/dev_00_02_76_03_3A_EA
bluetoothd[10443]: Releasing agent :1.54, /org/bluez/agent/wizard
bluetoothd[10443]: Removing device /org/bluez/10443/hci0/dev_00_02_76_03_3A_EA
bluetoothd[10443]: /org/bluez/10443/hci0/dev_00_02_76_03_3A_EA: canceling bonding request
bluetoothd[10443]: btd_device_unref(0xb7f3b9c0): ref=0
bluetoothd[10443]: device_free(0xb7f3b9c0)
Is there a tutorial somewhere? I don't even mind doing this from the
command line, but apparently I do not understand hcitool properly
either:
# hcitool info 00:02:76:03:3A:EA
Requesting information ...
BD Address: 00:02:76:03:3A:EA
Device Name: Rocketfish Bluetooth Keyboard
LMP Version: 1.2 (0x2) LMP Subversion: 0x229
Manufacturer: Broadcom Corporation (15)
Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<sniff mode> <RSSI> <power control> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <AFH cap. slave>
# hcitool cc 00:02:76:03:3A:EA
# hcitool auth 00:02:76:03:3A:EA
Not connected.
# hcitool cc 00:02:76:03:3A:EA;hcitool auth 00:02:76:03:3A:EA
HCI authentication request failed: Input/output error
About one second lapses between the "hcitool cc" command and when
bluetoothd drops the device information.
Thanks,
Caleb
On Mon, 22 Feb 2010 07:47:00 -0600
Caleb Katz <C2.Katz@gmail.com> wrote:
> Hey,
>
> How do I make a Bluetooth keyboard and mouse connect automatically on system startup? If that is not possible (and I would understand security reasons why it would not be), how do I make Bluez/bluetoothd automatically accept their connections?
>
> In a slightly longer form:
>
> My Bluetooth keyboard and mouse are able to behave as a standard USB keyboard/mouse (where the Bluetooth connection is hidden from the hardware/software) but the extra features like the scroll wheel and media keys do not work. In order to use them, I have to configure both as Bluetooth devices.
>
> It is easy enough to get them working. My distro (Slackware) already starts bluetoothd at boot, and the command "hidd --search --master" can find both after I press the "Connect" button on each. But that is the problem. I have to run a command after telling them to find the computer. When this combo is the only keyboard and mouse available, it is a little difficult to do that, especially when they automatically disconnect after a timeout in order to conserve battery power.
>
> Last night I got frustrated and wrote a short script that is launched into the background by the local init script. I'm attaching it (rocketfish.sh) for critique but it does increase my system load slightly. Please tell me there is a better way.
>
> I have the hardware address for the keyboard and mouse and have added this to my /etc/bluetooth/hcid.conf as someone elsewhere recommended (I have been unable to find documentation for it):
>
> device 00:02:76:03:3A:EA {
> name "RocketFish Keyboard";
> auth enable;
> encrypt enable;
> }
>
> device 00:02:76:0A:D2:2E {
> name "RocketFish Mouse";
> }
>
> When I run "bluetoothd -n -d," there are messages that indicate it detects the keyboard and mouse -- even when a key is pressed -- but then it removes their temporary entry.
>
> Obligatory system information:
> Slackware 13/kernel 2.6.29.5 (kernel was from pre-release)
> Bluez v4.47
> Keyboard and Mouse are models RF-BTKB2 and RF-BTMSE2
> My main.conf and hcid.conf are both attached.
>
> Thanks,
>
> Caleb
^ permalink raw reply
* Re: A2DP sink indications + autoclose after suspension
From: Luiz Augusto von Dentz @ 2010-02-23 20:14 UTC (permalink / raw)
To: Jacek Szczech; +Cc: linux-bluetooth
In-Reply-To: <20100223125854.GA22065@8planets.net>
Hi,
2010/2/23 Jacek Szczech <jszczech@8planet.net>:
> Hi,
>
> I succeeded writing a program that receives a2dp stream (from my mobile
> phone), decodes and sends to stdout using unix/ipc interface. It'll be run on
> old hw without X enviroment, that's why I didn't use already available
> software (like pulseaudio).
>
> I faced a few problems connected with suspension of stream:
>
> 1) Unix.c does not support indications (am I right?). How can I detect changes
> of states (e.g. OPEN<->STREAMING)? I can detect suspension with EAGAIN on
> stream_fd but it does not seem to be proper solution. Do you plan to support
> indications in unix/ipc interface?
You can listen for State on Audio interface or in the profile specific
interfaces such as AudioSource/AudioSink/Headset.
> 2) Will it be possible to get indications concerning OPEN<->STREAMING changes
> on dbus Media interface?
Media interface is just for endpoint registration, but again you can
achieve the same by listen to State changes e.g. Connected <-> Playing
> 3) After suspension of stream (SUSPEND sent from SRC) the stream
> is CLOSEd after about 10 seconds. What part of code disconnects this? Is it a
> way to avoid this?
Afaik this is not triggered if there is a unix client holding a lock,
so if e.g. the headset reconnects you have to claim the socket
otherwise it will timeout.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Events apparently not detected from USB bluetooth speaker
From: Reuben Firmin @ 2010-02-24 0:22 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100223200149.GA17518@kroah.com>
Hello,
I have a Saitek A-250, which is a USB bluetooth dongle sound device
which transmits to a set of speakers. Sound output works well.
However, I would like to capture events from the buttons on the
speakers (it has buttons for play, next, previous, etc, which cause
events to be sent back to the dongle, and which apparently work with
the windows driver.)
I used gizmod to monitor /dev/input/event*, but nothing showed up when
pressing the buttons on the speaker. Are the events coming in
elsewhere? Is there any tool that I can use to detect and kick off
actions on these events?
I asked over on the linux-usb list, and they suggested posting the
question here, believing that enabling the HID driver would do the
job. Because the dongle masquerades as a sound device, the bluetooth
stack apparently doesn't see it as being bluetooth. Any ideas on how
to proceed?
Thanks
Reuben
^ permalink raw reply
* Re: Read default link policy from main.conf - draft change for comments
From: Liang Bao @ 2010-02-24 7:33 UTC (permalink / raw)
To: linux-bluetooth
I've added a configuration item DisableParkState in main.conf and let
the bluetoothd check this. If it's set to true, the
main_opts.link_policy will be HCI_LP_RSWITCH | HCI_LP_SNIFF |
HCI_LP_HOLD, otherwise, it will be original one -
HCI_LP_RSWITCH | HCI_LP_SNIFF | HCI_LP_HOLD | HCI_LP_PARK. Any comment
on the code change or the way to configure? I just want to see if
further improvement is necessary before I send out the patch. Thanks.
diff --git a/data/main.conf b/data/main.conf
index 8153eb2..b9b8fef 100644
--- a/data/main.conf
+++ b/data/main.conf
@@ -57,3 +57,8 @@ ReverseServiceDiscovery = true
# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
NameResolving = true
+
+# Disable park state support helps some bluetooth device stably connected, e.g.
+# Motorola HF850 car-kit will lose connection or fail to setup SCO when it's
+# in park state. Defaults to 'false'.
+DisableParkState = true
diff --git a/src/main.c b/src/main.c
index ff423a4..e0ec7ce 100644
--- a/src/main.c
+++ b/src/main.c
@@ -203,8 +203,15 @@ static void parse_config(GKeyFile *config)
main_opts.link_mode = HCI_LM_ACCEPT;
main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
- HCI_LP_HOLD | HCI_LP_PARK;
+ HCI_LP_HOLD ;
+ boolean = g_key_file_get_boolean(config, "General",
+ "DisableParkState", &err);
+ if (err)
+ g_clear_error(&err);
+ else if (!boolean)
+ main_opts.link_policy |= HCI_LP_PARK;
}
2010/2/10 Liang Bao <tim.bao@gmail.com>:
> Anyone could advice? Thanks.
>
> 2010/2/8 Liang Bao <tim.bao@gmail.com>:
>> Hi,
>>
>> We noticed that currently BlueZ doesn't read link policy settings from
>> main.conf as it does for other things such as General.Name or
>> General.Class. It just enable everything in parse_config()
>> (src/main.c). Is this just due to lack of use case or BlueZ does this
>> intentionally for some reason? Thanks.
>>
>>
>> 86 static void parse_config(GKeyFile *config)
>> 87 {
>> .....
>> 206 main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
>> 207 HCI_LP_HOLD | HCI_LP_PARK;
>> 208 }
>>
>
^ permalink raw reply related
* Re: [bluetooth-next 1/1] bluetooth: handle device reset event
From: Ville Tervo @ 2010-02-24 12:25 UTC (permalink / raw)
To: ext Tomas Winkler
Cc: marcel@holtmann.org, linux-bluetooth@vger.kernel.org,
guy.cohen@intel.com, ron.rindjunsky@intel.com, Gregory Paskar
In-Reply-To: <1266486007-25015-1-git-send-email-tomas.winkler@intel.com>
Hi Tomas,
ext Tomas Winkler wrote:
> From: Gregory Paskar <greogry.paskar@intel.com>
>
> A bluetooth device experiencing hardware failure may issue
> a HARDWARE_ERROR hci event. The reaction to this event is device
> reset flow implemented in following sequence.
>
> 1. Notify: HCI_DEV_DOWN
> 2. Reinitialize internal structures.
> 3. Call driver flush function
> 4. Send HCI reset request to the device.
> 5. Send HCI init sequence reset to the device.
> 6. Notify HCI_DEV_UP.
Drivers on some embedded platforms can disable whole bt chip with gpio
line. Actually hw reset is sometimes needed for the reset. I'm wondering
if it would be feasible to add hdev->close() and hdev->open requense to
reset code? It would force driver to do hw reset for the chip.
--
Ville
^ permalink raw reply
* Re: Read default link policy from main.conf - draft change for comments
From: Liang Bao @ 2010-02-24 13:10 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <6aeb672b1002232333u54dbc04qd1f119cccef5febf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2833 bytes --]
Here's the patch file. I move the assignment of default value to
init_defaults() and just remove HCI_LP_PARK if the configuration is
set to "true". By default, this configuation in main.conf is written
as "DisableParkState = false"
2010/2/24 Liang Bao <tim.bao@gmail.com>:
> I've added a configuration item DisableParkState in main.conf and let
> the bluetoothd check this. If it's set to true, the
> main_opts.link_policy will be HCI_LP_RSWITCH | HCI_LP_SNIFF |
> HCI_LP_HOLD, otherwise, it will be original one -
> HCI_LP_RSWITCH | HCI_LP_SNIFF | HCI_LP_HOLD | HCI_LP_PARK. Any comment
> on the code change or the way to configure? I just want to see if
> further improvement is necessary before I send out the patch. Thanks.
>
> diff --git a/data/main.conf b/data/main.conf
> index 8153eb2..b9b8fef 100644
> --- a/data/main.conf
> +++ b/data/main.conf
> @@ -57,3 +57,8 @@ ReverseServiceDiscovery = true
> # Enable name resolving after inquiry. Set it to 'false' if you don't need
> # remote devices name and want shorter discovery cycle. Defaults to 'true'.
> NameResolving = true
> +
> +# Disable park state support helps some bluetooth device stably connected, e.g.
> +# Motorola HF850 car-kit will lose connection or fail to setup SCO when it's
> +# in park state. Defaults to 'false'.
> +DisableParkState = true
>
> diff --git a/src/main.c b/src/main.c
> index ff423a4..e0ec7ce 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -203,8 +203,15 @@ static void parse_config(GKeyFile *config)
>
> main_opts.link_mode = HCI_LM_ACCEPT;
>
> main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
> - HCI_LP_HOLD | HCI_LP_PARK;
> + HCI_LP_HOLD ;
> + boolean = g_key_file_get_boolean(config, "General",
> + "DisableParkState", &err);
> + if (err)
> + g_clear_error(&err);
> + else if (!boolean)
> + main_opts.link_policy |= HCI_LP_PARK;
> }
>
>
>
>
> 2010/2/10 Liang Bao <tim.bao@gmail.com>:
>> Anyone could advice? Thanks.
>>
>> 2010/2/8 Liang Bao <tim.bao@gmail.com>:
>>> Hi,
>>>
>>> We noticed that currently BlueZ doesn't read link policy settings from
>>> main.conf as it does for other things such as General.Name or
>>> General.Class. It just enable everything in parse_config()
>>> (src/main.c). Is this just due to lack of use case or BlueZ does this
>>> intentionally for some reason? Thanks.
>>>
>>>
>>> 86 static void parse_config(GKeyFile *config)
>>> 87 {
>>> .....
>>> 206 main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
>>> 207 HCI_LP_HOLD | HCI_LP_PARK;
>>> 208 }
>>>
>>
>
[-- Attachment #2: 0001-Allow-disable-park-state-in-main.conf.patch --]
[-- Type: text/x-diff, Size: 2182 bytes --]
From 331b120153c04694c73556c0287456a11874251f Mon Sep 17 00:00:00 2001
From: Tim Bao <tim.bao@gmail.com>
Date: Wed, 24 Feb 2010 20:48:29 +0800
Subject: [PATCH] Allow disable park state in main.conf
Currently BlueZ is hard-coding the default link policy to include
hold mode, role switch, sniff mode and park state. However, some
device will have problem to maintain the connection or setup SCO
if they are in park state. Making the park state configurable in
main.conf improves flexibility so it can be disabled when needed.
Signed-off-by: Tim Bao <tim.bao@gmail.com>
---
src/main.c | 13 +++++++++----
src/main.conf | 5 +++++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/main.c b/src/main.c
index 014d8b6..977c87b 100644
--- a/src/main.c
+++ b/src/main.c
@@ -201,10 +201,12 @@ static void parse_config(GKeyFile *config)
else
main_opts.name_resolv = boolean;
- main_opts.link_mode = HCI_LM_ACCEPT;
-
- main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
- HCI_LP_HOLD | HCI_LP_PARK;
+ boolean = g_key_file_get_boolean(config, "General",
+ "DisableParkState", &err);
+ if (err)
+ g_clear_error(&err);
+ else if (boolean)
+ main_opts.link_policy &= (~HCI_LP_PARK);
}
/*
@@ -276,6 +278,9 @@ static void init_defaults(void)
main_opts.remember_powered = TRUE;
main_opts.reverse_sdp = TRUE;
main_opts.name_resolv = TRUE;
+ main_opts.link_mode = HCI_LM_ACCEPT;
+ main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
+ HCI_LP_HOLD | HCI_LP_PARK;
if (gethostname(main_opts.host_name, sizeof(main_opts.host_name) - 1) < 0)
strcpy(main_opts.host_name, "noname");
diff --git a/src/main.conf b/src/main.conf
index b252a82..6f975fc 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -50,3 +50,8 @@ ReverseServiceDiscovery = true
# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
NameResolving = true
+
+# Disable park state in default link policy. Some devices have connection
+# stability issue or fail to setup SCO when the link is in park state. Defaults
+# to 'false'.
+DisableParkState = false
--
1.5.6.3
^ permalink raw reply related
* obexd 0.14 "put" file corruption
From: Ed Tsang @ 2010-02-24 21:50 UTC (permalink / raw)
To: Bluettooth Linux
Hi,
I am using obexd 0.14 to push files into phone. The image file received by some phone seem a bit strange and in some phone it could not be display at all. So I tried a simple text file with line number as text. Then I saw the file received from the phone is corrupted. Looking into the hcidump look like the second "Put cmd" and forward, the first "0xc8" bytes was not copied (stay the same as the firs put cmd).
Anyone know if this is a known problem in 0.14 or fixed in the latest (obexd 0.20).
Thanks,
Ed
__________________________________________________________________
Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/
^ permalink raw reply
* Re: obexd 0.14 "put" file corruption
From: Ed Tsang @ 2010-02-24 22:23 UTC (permalink / raw)
To: Bluettooth Linux
>I am using obexd 0.14 to push files into phone. The image file received by some phone seem a bit strange and in some phone it could not be >display at all. So I tried a simple text file with line number as text. Then I saw the file received from the phone is corrupted. Looking into the >hcidump look like the second "Put cmd" and forward, the first "0xc8" bytes was not copied (stay the same as the firs put cmd).
> Anyone know if this is a known problem in 0.14 or fixed in the latest (obexd 0.20).
Installed the obexd o.20. Same problem???
-------------------------- first put
RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 303 fcs 0x4f
OBEX: Put cmd(c): len 3922
Name (0x01) = Unicode length 12
0000: 00 74 00 2e 00 74 00 78 00 74 00 00 .t...t.x.t..
Length (0xc3) = 8208
Body (0x48) = Sequence length 3896
0000: 30 30 20 66 69 72 73 74 20 6c 69 6e 65 20 20 0a 00 first line .
0010: 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 1 .
...................... second put (after 0xc8 is fine)
RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 283 fcs 0x4f
OBEX: Put cmd(c): len 3902 (continue)
Body (0x48) = Sequence length 3896
0000: 30 30 20 66 69 72 73 74 20 6c 69 6e 65 20 20 0a 00 first line .
0010: 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 1 .
0020: 32 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 2 .
0030: 33 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 3 .
0040: 34 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 4 .
0050: 35 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 5 .
0060: 36 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 6 .
0070: 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 7 .
0080: 38 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 8 .
0090: 39 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 9 .
00a0: 41 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a A .
00b0: 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a B .
00c0: 43 20 20 20 20 20 20 20 31 30 30 20 73 65 63 6f C 100 seco
00d0: 6e 64 20 70 61 67 65 0a 31 20 20 20 20 20 20 20 nd page.1
00e0: 20 20 20 20 20 20 32 0a 32 20 20 20 20 20 20 20 2.2
Anyone bump into this?? look like the start of copying problem...
Ed
__________________________________________________________________
Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
^ permalink raw reply
* DiscoverableTimeout not working as expected
From: Ross Burton @ 2010-02-25 12:19 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
Hi,
My client calls SetProperty(DiscoverTimeout, 20) then
SetProperty(Discoverable, True) on my adaptor, but I don't get the
expected behaviour:
signal sender=:1.2 -> dest=(null destination) serial=847 path=/org/bluez/1564/hci0; interface=org.bluez.Adapter; member=PropertyChanged
string "DiscoverableTimeout"
variant uint32 20
signal sender=:1.2 -> dest=(null destination) serial=850 path=/org/bluez/1564/hci0; interface=org.bluez.Adapter; member=PropertyChanged
string "Discoverable"
variant boolean true
signal sender=:1.2 -> dest=(null destination) serial=852 path=/org/bluez/1564/hci0; interface=org.bluez.Adapter; member=PropertyChanged
string "DiscoverableTimeout"
variant uint32 0
As the timeout is now 0, discoverable never resets itself to false.
Am I doing something stupid, or is setting the discovery timeout broken?
Ross
--
Intel Open Source Technology Centre
http://oss.intel.com/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* patch for firmware download to Qualcomm Bluetooth chip
From: Matt Wilson @ 2010-02-26 0:02 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 128 bytes --]
Hi Marcel,
Please let us know if this patch will be acceptable or suggestions for
changes to make it so.
Thanks,
Matt Wilson
[-- Attachment #2: 0001-Firmware-download-for-Qualcomm-Bluetooth-devices.patch --]
[-- Type: text/x-patch, Size: 10335 bytes --]
>From 76d0bdd82a0a4e5b3b9544bb864c31888f20cea1 Mon Sep 17 00:00:00 2001
From: Wilson, Matt <mtwilson@codeaurora.org>
Date: Thu, 11 Feb 2010 11:53:29 -0600
Subject: [PATCH] Firmware download for Qualcomm Bluetooth devices
---
Makefile.tools | 3 +-
tools/hciattach.c | 9 ++
tools/hciattach.h | 4 +
tools/hciattach_qualcomm.c | 279 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 294 insertions(+), 1 deletions(-)
create mode 100644 tools/hciattach_qualcomm.c
diff --git a/Makefile.tools b/Makefile.tools
index 2735d68..7b92c8f 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -23,7 +23,8 @@ tools_l2ping_LDADD = lib/libbluetooth.la
tools_hciattach_SOURCES = tools/hciattach.c tools/hciattach.h \
tools/hciattach_st.c \
tools/hciattach_ti.c \
- tools/hciattach_tialt.c
+ tools/hciattach_tialt.c \
+ tools/hciattach_qualcomm.c
tools_hciattach_LDADD = lib/libbluetooth.la
tools_hciconfig_SOURCES = tools/hciconfig.c tools/csr.h tools/csr.c \
diff --git a/tools/hciattach.c b/tools/hciattach.c
index 364c5ff..d6aafbe 100644
--- a/tools/hciattach.c
+++ b/tools/hciattach.c
@@ -5,6 +5,7 @@
* Copyright (C) 2000-2001 Qualcomm Incorporated
* Copyright (C) 2002-2003 Maxim Krasnyansky <maxk@qualcomm.com>
* Copyright (C) 2002-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (C) 2010, Code Aurora Forum. All rights reserved.
*
*
* This program is free software; you can redistribute it and/or modify
@@ -299,6 +300,11 @@ static int texasalt(int fd, struct uart_t *u, struct termios *ti)
return texasalt_init(fd, u->speed, ti);
}
+static int qualcomm(int fd, struct uart_t *u, struct termios *ti)
+{
+ return qualcomm_init(fd, u->speed, ti, u->bdaddr);
+}
+
static int read_check(int fd, void *buf, int count)
{
int res;
@@ -1071,6 +1077,9 @@ struct uart_t uart[] = {
/* Broadcom BCM2035 */
{ "bcm2035", 0x0A5C, 0x2035, HCI_UART_H4, 115200, 460800, FLOW_CTL, NULL, bcm2035 },
+ /* QUALCOMM BTS */
+ { "qualcomm", 0x0000, 0x0000, HCI_UART_H4, 115200, 115200, FLOW_CTL, NULL, qualcomm },
+
{ NULL, 0 }
};
diff --git a/tools/hciattach.h b/tools/hciattach.h
index 867563b..5c89013 100644
--- a/tools/hciattach.h
+++ b/tools/hciattach.h
@@ -3,6 +3,7 @@
* BlueZ - Bluetooth protocol stack for Linux
*
* Copyright (C) 2003-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
*
*
* This program is free software; you can redistribute it and/or modify
@@ -45,3 +46,6 @@ int texas_post(int fd, struct termios *ti);
int texasalt_init(int fd, int speed, struct termios *ti);
int stlc2500_init(int fd, bdaddr_t *bdaddr);
int bgb2xx_init(int dd, bdaddr_t *bdaddr);
+int qualcomm_init(int fd, int speed, struct termios *ti, const char *bdaddr);
+
+
diff --git a/tools/hciattach_qualcomm.c b/tools/hciattach_qualcomm.c
new file mode 100644
index 0000000..31ca3c8
--- /dev/null
+++ b/tools/hciattach_qualcomm.c
@@ -0,0 +1,279 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2005-2010 Marcel Holtmann <marcel@holtmann.org>
+ * Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdio.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+#include <signal.h>
+#include <syslog.h>
+#include <termios.h>
+#include <time.h>
+#include <sys/time.h>
+#include <sys/poll.h>
+#include <sys/param.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
+#include <sys/uio.h>
+
+#include <bluetooth/bluetooth.h>
+#include <bluetooth/hci.h>
+#include <bluetooth/hci_lib.h>
+
+#include "hciattach.h"
+
+#define FAILIF(x, args...) do { \
+ if (x) { \
+ fprintf(stderr, ##args); \
+ return -1; \
+ } \
+} while(0)
+
+typedef struct {
+ uint8_t uart_prefix;
+ hci_event_hdr hci_hdr;
+ evt_cmd_complete cmd_complete;
+ uint8_t status;
+ uint8_t data[16];
+} __attribute__((packed)) command_complete_t;
+
+
+static int read_command_complete(int fd, unsigned short opcode, unsigned char len) {
+ command_complete_t resp;
+ unsigned char vsevent[512];
+ int n;
+
+ /* Read reply. */
+ n = read_hci_event(fd, vsevent, sizeof(vsevent));
+ FAILIF(n < 0, "Failed to read response");
+
+ FAILIF(vsevent[1] != 0xFF, "Failed to read response");
+
+ n = read_hci_event(fd, (unsigned char *)&resp, sizeof(resp));
+ FAILIF(n < 0, "Failed to read response");
+
+ FAILIF(resp.hci_hdr.evt != EVT_CMD_COMPLETE, /* event must be event-complete */
+ "Error in response: not a cmd-complete event, "
+ "but 0x%02x!\n", resp.hci_hdr.evt);
+
+ FAILIF(resp.hci_hdr.plen < 4, /* plen >= 4 for EVT_CMD_COMPLETE */
+ "Error in response: plen is not >= 4, but 0x%02x!\n",
+ resp.hci_hdr.plen);
+
+ /* cmd-complete event: opcode */
+ FAILIF(resp.cmd_complete.opcode != 0,
+ "Error in response: opcode is 0x%04x, not 0!",
+ resp.cmd_complete.opcode);
+
+ return resp.status == 0 ? 0 : -1;
+}
+
+static int qualcomm_load_firmware(int fd, const char *firmware, const char *bdaddr_s) {
+
+ int fw = open(firmware, O_RDONLY);
+
+ fprintf(stdout, "Opening firmware file: %s\n", firmware);
+
+ FAILIF(fw < 0,
+ "Could not open firmware file %s: %s (%d).\n",
+ firmware, strerror(errno), errno);
+
+ fprintf(stdout, "Uploading firmware...\n");
+ do {
+ /* Read each command and wait for a response. */
+ unsigned char data[1024];
+ unsigned char cmdp[1 + sizeof(hci_command_hdr)];
+ hci_command_hdr *cmd = (hci_command_hdr *)(cmdp + 1);
+ int nr;
+ nr = read(fw, cmdp, sizeof(cmdp));
+ if (!nr)
+ break;
+ FAILIF(nr != sizeof(cmdp), "Could not read H4 + HCI header!\n");
+ FAILIF(*cmdp != HCI_COMMAND_PKT, "Command is not an H4 command packet!\n");
+
+ FAILIF(read(fw, data, cmd->plen) != cmd->plen,
+ "Could not read %d bytes of data for command with opcode %04x!\n",
+ cmd->plen,
+ cmd->opcode);
+
+ if ((data[0] == 1) && (data[1] == 2) && (data[2] == 6)) {
+ bdaddr_t bdaddr;
+ if (bdaddr_s != NULL) {
+ (void) str2ba(bdaddr_s, &bdaddr);
+ memcpy(&data[3], &bdaddr, sizeof(bdaddr_t));
+ }
+ }
+
+ {
+ int nw;
+ struct iovec iov_cmd[2];
+ iov_cmd[0].iov_base = cmdp;
+ iov_cmd[0].iov_len = sizeof(cmdp);
+ iov_cmd[1].iov_base = data;
+ iov_cmd[1].iov_len = cmd->plen;
+ nw = writev(fd, iov_cmd, 2);
+ FAILIF(nw != (int) sizeof(cmdp) + cmd->plen,
+ "Could not send entire command (sent only %d bytes)!\n",
+ nw);
+ }
+
+ /* Wait for response */
+ if (read_command_complete(fd,
+ cmd->opcode,
+ cmd->plen) < 0) {
+ return -1;
+ }
+
+ } while(1);
+ fprintf(stdout, "Firmware upload successful.\n");
+
+ close(fw);
+ return 0;
+}
+
+int qualcomm_init(int fd, int speed, struct termios *ti, const char *bdaddr)
+{
+ struct timespec tm = {0, 50000};
+ char cmd[5];
+ unsigned char resp[100]; /* Response */
+ char fw[100];
+ int n;
+
+ memset(resp,'\0', 100);
+
+ /* Get Manufacturer and LMP version */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x01;
+ cmd[2] = 0x10;
+ cmd[3] = 0x00;
+
+ do {
+ n = write(fd, cmd, 4);
+ if (n < 0) {
+ perror("Failed to write init command (READ_LOCAL_VERSION_INFORMATION)");
+ return -1;
+ }
+ if (n < 4) {
+ fprintf(stderr, "Wanted to write 4 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if (read_hci_event(fd, resp, 100) < 0) {
+ perror("Failed to read init response (READ_LOCAL_VERSION_INFORMATION)");
+ return -1;
+ }
+
+ /* Wait for command complete event for our Opcode */
+ } while (resp[4] != cmd[1] && resp[5] != cmd[2]);
+
+ /* Verify manufacturer */
+ if ((resp[11] & 0xFF) != 0x1d)
+ fprintf(stderr,"WARNING : module's manufacturer is not Qualcomm\n");
+
+ /* Print LMP version */
+ fprintf(stderr, "Qualcomm module LMP version : 0x%02x\n", resp[10] & 0xFF);
+
+ /* Print LMP subversion */
+ {
+ unsigned short lmp_subv = resp[13] | (resp[14] << 8);
+
+ fprintf(stderr, "Qualcomm module LMP sub-version : 0x%04x\n", lmp_subv);
+
+ }
+
+ /* Get SoC type */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x00;
+ cmd[2] = 0xFC;
+ cmd[3] = 0x01;
+ cmd[4] = 0x06;
+
+ do {
+ n = write(fd, cmd, 5);
+ if (n < 0) {
+ perror("Failed to write init command");
+ return -1;
+ }
+ if (n < 5) {
+ fprintf(stderr, "Wanted to write 5 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if ((n = read_hci_event(fd, resp, 100)) < 0) {
+ perror("Failed to read init response");
+ return -1;
+ }
+
+ } while (resp[3] != 0 && resp[4] != 2);
+
+ snprintf(fw, sizeof(fw),
+ "/etc/firmware/%c%c%c%c%c%c_%c%c%c%c.bin",
+ resp[18], resp[19], resp[20], resp[21],
+ resp[22], resp[23],
+ resp[32], resp[33], resp[34], resp[35]);
+
+ /* Wait for command complete event for our Opcode */
+ if (read_hci_event(fd, resp, 100) < 0) {
+ perror("Failed to read init response");
+ return -1;
+ }
+
+ qualcomm_load_firmware(fd, fw, bdaddr);
+
+ /* Reset */
+ cmd[0] = HCI_COMMAND_PKT;
+ cmd[1] = 0x03;
+ cmd[2] = 0x0C;
+ cmd[3] = 0x00;
+
+ do {
+ n = write(fd, cmd, 4);
+ if (n < 0) {
+ perror("Failed to write reset command");
+ return -1;
+ }
+ if (n < 4) {
+ fprintf(stderr, "Wanted to write 4 bytes, could only write %d. Stop\n", n);
+ return -1;
+ }
+
+ /* Read reply. */
+ if ((n = read_hci_event(fd, resp, 100)) < 0) {
+ perror("Failed to read reset response");
+ return -1;
+ }
+
+ } while (resp[4] != cmd[1] && resp[5] != cmd[2]);
+
+ nanosleep(&tm, NULL);
+ return 0;
+}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.
From: Nick Pelly @ 2010-02-26 1:05 UTC (permalink / raw)
To: Ville Tervo; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <4B82380A.6040204@nokia.com>
On Sun, Feb 21, 2010 at 11:53 PM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Nick Pelly wrote:
>>>>
>>>> Attached is a new patch with the consistent bit logic.
>>>>
>>>> Comments?
>>>
>>> In order to keep backwards compatibility 1 should mean "don't allow this
>>> packet type" for all packets. Other wise old application with new kernel
>>> would not allow any packet types.
>>
>> The current patch achieves this backwards compatibility by assuming
>> that all packet types are allowed if the old sockaddr_sco struct is
>> used (it checks the size), or if sco_pkt_type is 0.
>
> OK. Then my concerns are gone.
As best I can tell there are no objections. We're going ahead with this patch.
http://android.git.kernel.org/?p=kernel/common.git;a=commit;h=3b077241e02041b1f03fee912896b8de1d7ac096
Nick
^ permalink raw reply
* link starvation during multi profile scenario
From: Suraj Sumangala @ 2010-02-26 8:39 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Vikram Kandukuri, linux-bluetooth@vger.kernel.org, Luis Rodriguez,
Jothikumar Mothilal, Zhongyi Chen
In-Reply-To: <4B836ABE.70505@atheros.com>
Hi Marcel,
I am facing an issue on Bluetooth Multiprofile secnario on CSR board as
well as Atheros board on Ubuntu git tree head source.
The scenario is
1. From Ubuntu make A2DP connection
2. Start Streaming
3. From Ubuntu do FTP connection
4. Send file from Ubuntu to remote device.
5. Take A2DP sink (Headset) out of range.
6. FTP operation stops.
From my observation, it looks like the stalled A2DP connection is using
up all HCI buffers and starving the FTP connection of HCI buffers.
I have written a small enhancement for this scenario.
Please have a look at it and let me know if you have a cleaner and
better implementation.
Please find my changes below,
Regards
Suraj
Author: Suraj Sumangala <suraj@atheros.com>
Date: Fri Feb 26 12:16:50 2010 +0530
Avoid link starvation in multi-link scenario
Signed-off-by: <suraj@atheros.com>
diff --git a/include/net/bluetooth/hci_core.h
b/include/net/bluetooth/hci_core.h
index ce3c99e..fcae633 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -181,6 +181,9 @@ struct hci_conn {
unsigned int sent;
+
+ unsigned int acl_avail;
+
struct sk_buff_head data_q;
struct timer_list disc_timer;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 4ad2319..10b80c4 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1359,6 +1359,9 @@ static inline struct hci_conn *hci_low_sent(struct
hci_dev *hdev, __u8 type, int
if (c->state != BT_CONNECTED && c->state != BT_CONFIG)
continue;
+ if (c->acl_avail == 0)
+ continue;
+
num++;
if (c->sent < min) {
@@ -1423,6 +1426,10 @@ static inline void hci_sched_acl(struct hci_dev
*hdev)
hdev->acl_cnt--;
conn->sent++;
+
+ if (conn->acl_avail != 0)
+ conn->acl_avail--;
+
}
}
}
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 592da5c..18dbdc2 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -900,6 +900,7 @@ static inline void hci_conn_complete_evt(struct
hci_dev *hdev, struct sk_buff *s
if (conn->type == ACL_LINK) {
struct hci_cp_read_remote_features cp;
cp.handle = ev->handle;
+ conn->acl_avail = hdev->acl_pkts;
hci_send_cmd(hdev, HCI_OP_READ_REMOTE_FEATURES,
sizeof(cp), &cp);
}
@@ -1447,6 +1448,9 @@ static inline void hci_num_comp_pkts_evt(struct
hci_dev *hdev, struct sk_buff *s
if (conn->type == ACL_LINK) {
if ((hdev->acl_cnt += count) > hdev->acl_pkts)
hdev->acl_cnt = hdev->acl_pkts;
+
+ conn->acl_avail = count;
+
} else {
if ((hdev->sco_cnt += count) > hdev->sco_pkts)
hdev->sco_cnt = hdev->sco_pkts;
^ permalink raw reply related
* Re: obexd 0.14 "put" file corruption
From: Luiz Augusto von Dentz @ 2010-02-26 8:41 UTC (permalink / raw)
To: Ed Tsang; +Cc: Bluettooth Linux
In-Reply-To: <367108.65360.qm@web52604.mail.re2.yahoo.com>
Hi,
On Thu, Feb 25, 2010 at 12:23 AM, Ed Tsang <netdesign_98@yahoo.com> wrote:
>
>
>>I am using obexd 0.14 to push files into phone. The image file received by some phone seem a bit strange and in some phone it could not be >display at all. So I tried a simple text file with line number as text. Then I saw the file received from the phone is corrupted. Looking into the >hcidump look like the second "Put cmd" and forward, the first "0xc8" bytes was not copied (stay the same as the firs put cmd).
>> Anyone know if this is a known problem in 0.14 or fixed in the latest (obexd 0.20).
> Installed the obexd o.20. Same problem???
> -------------------------- first put
> RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 303 fcs 0x4f
> OBEX: Put cmd(c): len 3922
> Name (0x01) = Unicode length 12
> 0000: 00 74 00 2e 00 74 00 78 00 74 00 00 .t...t.x.t..
> Length (0xc3) = 8208
> Body (0x48) = Sequence length 3896
> 0000: 30 30 20 66 69 72 73 74 20 6c 69 6e 65 20 20 0a 00 first line .
> 0010: 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 1 .
>
> ...................... second put (after 0xc8 is fine)
> RFCOMM(d): UIH: cr 1 dlci 12 pf 0 ilen 283 fcs 0x4f
> OBEX: Put cmd(c): len 3902 (continue)
> Body (0x48) = Sequence length 3896
> 0000: 30 30 20 66 69 72 73 74 20 6c 69 6e 65 20 20 0a 00 first line .
> 0010: 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 1 .
> 0020: 32 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 2 .
> 0030: 33 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 3 .
> 0040: 34 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 4 .
> 0050: 35 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 5 .
> 0060: 36 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 6 .
> 0070: 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 7 .
> 0080: 38 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 8 .
> 0090: 39 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a 9 .
> 00a0: 41 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a A .
> 00b0: 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a B .
> 00c0: 43 20 20 20 20 20 20 20 31 30 30 20 73 65 63 6f C 100 seco
> 00d0: 6e 64 20 70 61 67 65 0a 31 20 20 20 20 20 20 20 nd page.1
> 00e0: 20 20 20 20 20 20 32 0a 32 20 20 20 20 20 20 20 2.2
>
> Anyone bump into this?? look like the start of copying problem...
Weird, are you sure the client is sending this properly? Anyway we do
store the data in a buffer even if was sent together with put cmd, Im
very suspicious that this is not the problem since we would have
notice this before. Btw obexd does not push/send files obex-client
does, are you talking about obex-client?
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Bluetooth: Allow SCO/eSCO packet type selection for outgoing SCO connections.
From: Iain Hibbert @ 2010-02-26 9:20 UTC (permalink / raw)
To: Nick Pelly; +Cc: Ville Tervo, Marcel Holtmann, linux-bluetooth@vger.kernel.org
In-Reply-To: <35c90d961002251705j2cd95a8cjc7d10aa432a49f4@mail.gmail.com>
On Thu, 25 Feb 2010, Nick Pelly wrote:
> On Sun, Feb 21, 2010 at 11:53 PM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > Nick Pelly wrote:
> >>>>
> >>>> Attached is a new patch with the consistent bit logic.
> >>>>
> >>>> Comments?
> >>>
> >>> In order to keep backwards compatibility 1 should mean "don't allow this
> >>> packet type" for all packets. Other wise old application with new kernel
> >>> would not allow any packet types.
> >>
> >> The current patch achieves this backwards compatibility by assuming
> >> that all packet types are allowed if the old sockaddr_sco struct is
> >> used (it checks the size), or if sco_pkt_type is 0.
> >
> > OK. Then my concerns are gone.
>
> As best I can tell there are no objections. We're going ahead with this patch.
>
> http://android.git.kernel.org/?p=kernel/common.git;a=commit;h=3b077241e02041b1f03fee912896b8de1d7ac096
FWIW (I am not a Linux, Android or BlueZ developer) I think abusing the
socket address structure for this is wrong and a socket option should be
used to set options for the socket.
In general, the "Address Family" AF_BLUETOOTH domain sockets should all
use the same socket address structure. That BlueZ/Linux does not and never
has done so should be considered a bug.
regards,
iain
^ permalink raw reply
* Re: DiscoverableTimeout not working as expected
From: Luiz Augusto von Dentz @ 2010-02-26 9:24 UTC (permalink / raw)
To: Ross Burton; +Cc: linux-bluetooth
In-Reply-To: <1267100354.22889.16.camel@flashheart.burtonini.com>
Hi Ross,
On Thu, Feb 25, 2010 at 2:19 PM, Ross Burton <ross@linux.intel.com> wrote:
> Hi,
>
> My client calls SetProperty(DiscoverTimeout, 20) then
> SetProperty(Discoverable, True) on my adaptor, but I don't get the
> expected behaviour:
>
> signal sender=:1.2 -> dest=(null destination) serial=847 path=/org/bluez/1564/hci0; interface=org.bluez.Adapter; member=PropertyChanged
> string "DiscoverableTimeout"
> variant uint32 20
> signal sender=:1.2 -> dest=(null destination) serial=850 path=/org/bluez/1564/hci0; interface=org.bluez.Adapter; member=PropertyChanged
> string "Discoverable"
> variant boolean true
> signal sender=:1.2 -> dest=(null destination) serial=852 path=/org/bluez/1564/hci0; interface=org.bluez.Adapter; member=PropertyChanged
> string "DiscoverableTimeout"
> variant uint32 0
I got a different behavior (using git tree and testtest-adapter):
signal sender=:1.65 -> dest=(null destination) serial=151
path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
member=PropertyChanged
string "DiscoverableTimeout"
variant uint32 10
signal sender=:1.65 -> dest=(null destination) serial=160
path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
member=PropertyChanged
string "Discoverable"
variant boolean true
signal sender=:1.65 -> dest=(null destination) serial=161
path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
member=PropertyChanged
string "Class"
variant uint32 6430988
signal sender=:1.65 -> dest=(null destination) serial=162
path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
member=PropertyChanged
string "Discoverable"
variant boolean false
signal sender=:1.65 -> dest=(null destination) serial=163
path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
member=PropertyChanged
string "Class"
variant uint32 6422796
> As the timeout is now 0, discoverable never resets itself to false.
Basically the timeout is persistent so once set it will be triggered
every time you switch the adapter to discoverable, in other words it
wont change to 0 automatically anymore, I guess this was an old
behavior but it has been changed long time ago.
> Am I doing something stupid, or is setting the discovery timeout broken?
I guess what you need is to update your bluez version then it should work.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* lockdep warns: inconsistent lock state ({IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W})
From: Andrei Emeltchenko @ 2010-02-26 9:26 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Enabling locking debug we have triggered warning below:
[ 2917.827178] =================================
[ 2917.833068] [ INFO: inconsistent lock state ]
[ 2917.837432] 2.6.32 #54
[ 2917.841125] ---------------------------------
[ 2917.845520] inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
[ 2917.851562] krfcommd/1516 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 2917.856903] (slock-AF_BLUETOOTH){+.?...}, at: [<bf057b50>]
rfcomm_sk_state_change+0x78/0x160 [rfcomm]
[ 2917.866363] {IN-SOFTIRQ-W} state was registered at:
[ 2917.871276] [<c008d33c>] mark_lock+0x298/0x630
[ 2917.875946] [<c008ed3c>] __lock_acquire+0x5f4/0x175c
[ 2917.881134] [<c008ff0c>] lock_acquire+0x68/0x7c
[ 2917.885864] [<c036938c>] _spin_lock+0x48/0x58
[ 2917.890441] [<bf025960>] l2cap_conn_start+0x80/0x388 [l2cap]
[ 2917.896362] [<bf028f44>] l2cap_recv_frame+0x1c58/0x2fe0 [l2cap]
[ 2917.902526] [<bf02a3cc>] l2cap_recv_acldata+0x100/0x350 [l2cap]
[ 2917.908691] [<bf0035a8>] hci_rx_task+0x244/0x478 [bluetooth]
[ 2917.914642] [<c006c4d0>] tasklet_action+0x78/0xd8
[ 2917.919555] [<c006cc34>] __do_softirq+0xa8/0x154
[ 2917.924407] [<c006cd40>] irq_exit+0x60/0xb4
[ 2917.928802] [<c0030078>] asm_do_IRQ+0x78/0x90
[ 2917.933380] [<c0030af0>] __irq_svc+0x50/0xbc
[ 2917.937866] [<c0043c74>] omap3_enter_idle_bm+0x1d0/0x238
[ 2917.943389] [<c029ee94>] cpuidle_idle_call+0xb4/0x114
[ 2917.948669] [<c00320b0>] cpu_idle+0x58/0xac
[ 2917.953063] [<c0360b18>] rest_init+0x70/0x84
[ 2917.957550] [<c00089fc>] start_kernel+0x2b4/0x318
[ 2917.962493] [<80008034>] 0x80008034
[ 2917.966186] irq event stamp: 312
[ 2917.969421] hardirqs last enabled at (312): [<c03691ac>]
_spin_unlock_irqrestore+0x44/0x70
[ 2917.977844] hardirqs last disabled at (311): [<c036947c>]
_spin_lock_irqsave+0x24/0x68
[ 2917.985809] softirqs last enabled at (261): [<c006ccc8>]
__do_softirq+0x13c/0x154
[ 2917.993438] softirqs last disabled at (244): [<c006cde8>]
do_softirq+0x54/0x78
[ 2918.000732]
[ 2918.000732] other info that might help us debug this:
[ 2918.007293] 2 locks held by krfcommd/1516:
[ 2918.011413] #0: (rfcomm_mutex){+.+.+.}, at: [<bf054df4>]
rfcomm_run+0x1f0/0xb00 [rfcomm]
[ 2918.019805] #1: (&d->lock){+.+...}, at: [<bf055220>]
rfcomm_run+0x61c/0xb00 [rfcomm]
[ 2918.027832]
[ 2918.027832] stack backtrace:
[ 2918.032226] Backtrace:
[ 2918.034729] [<c00348d0>] (dump_backtrace+0x0/0x110) from [<c036616c>]
(dump_stack+0x18/0x1c)
[ 2918.043212] r7:dc8f6c00 r6:c0425252 r5:00000001 r4:00000001
[ 2918.048950] [<c0366154>] (dump_stack+0x0/0x1c) from [<c008d060>]
(print_usage_bug+0x178/0x1bc)
[ 2918.057617] [<c008cee8>] (print_usage_bug+0x0/0x1bc) from [<c008d408>]
(mark_lock+0x364/0x630)
[ 2918.066284] [<c008d0a4>] (mark_lock+0x0/0x630) from [<c008edcc>]
(__lock_acquire+0x684/0x175c)
[ 2918.074951] [<c008e748>] (__lock_acquire+0x0/0x175c) from [<c008ff0c>]
(lock_acquire+0x68/0x7c)
[ 2918.083709] [<c008fea4>] (lock_acquire+0x0/0x7c) from [<c036938c>]
(_spin_lock+0x48/0x58)
[ 2918.091949] r7:dba9402c r6:dba5c3c0 r5:dba9402c r4:bf057b50
[ 2918.097717] [<c0369344>] (_spin_lock+0x0/0x58) from [<bf057b50>]
(rfcomm_sk_state_change+0x78/0x160 [rfcomm])
[ 2918.107696] r5:dba94000 r4:00000000
[ 2918.111358] [<bf057ad8>] (rfcomm_sk_state_change+0x0/0x160 [rfcomm]) from
[<bf055238>] (rfcomm_run+0x634/0xb00 [rfcomm])
[ 2918.122283] r7:dba5c450 r6:dba5d6c0 r5:dba5c3c0 r4:dba5c430
[ 2918.128051] [<bf054c04>] (rfcomm_run+0x0/0xb00 [rfcomm]) from [<c007cc10>]
(kthread+0x88/0x90)
[ 2918.136749] [<c007cb88>] (kthread+0x0/0x90) from [<c006a86c>]
(do_exit+0x0/0x678)
[ 2918.144256] r7:00000000 r6:00000000 r5:00000000 r4:00000000
^ permalink raw reply
* Re: Kernel panic in rfcomm_run - unbalanced refcount on rfcomm_session
From: Ville Tervo @ 2010-02-26 10:23 UTC (permalink / raw)
To: ext Nick Pelly; +Cc: Dave Young, Bluettooth Linux
In-Reply-To: <35c90d961002211300s25507542y9b73724881be5540@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
Nick Pelly wrote:
> On Sat, Feb 20, 2010 at 12:17 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
>> On Thu, Feb 18, 2010 at 1:04 PM, Nick Pelly <npelly@google.com> wrote:
>>> Since 2.6.32 we are seeing kernel panics like:
>>>
>>> [10651.110229] Unable to handle kernel paging request at virtual
>>> address 6b6b6b6b
>>> [10651.111968] Internal error: Oops: 5 [#1] PREEMPT
>>> [10651.113952] CPU: 0 Tainted: G W (2.6.32-59979-gd0c97db #1)
>>> [10651.114624] PC is at rfcomm_run+0xa04/0xdbc
>>> <...>
>>> [10651.406188] [<c031ad24>] (rfcomm_run+0xa04/0xdbc) from [<c006ce30>]
>>> (kthread+0x78/0x80)
>>> [10651.406585] [<c006ce30>] (kthread+0x78/0x80) from [<c002793c>]
>>> (kernel_thread_exit+0x0/0x8)
>>>
>>> (rfcomm_run() is all inlined so theres not much of a stack trace))
l2cap socket status might change while rfcomm is processing frames. And
that makes rfcomm_process_rx to do double rfcomm_session_put() for
incoming session reference. We cannot use sk_state.
Could you try with this patch if it helps to your problems also? My OPP
problems went away with this patch.
I moved rfcomm_session_put() for incoming session to
rfcomm_session_close in order to get more clear _hold()/_put() pairs.
--
Ville
[-- Attachment #2: 0001-Bluetooth-Drop-rfcomm-session-reference-only-once-fo.patch --]
[-- Type: text/x-patch, Size: 2540 bytes --]
>From e713b2e8ae93aa46465984237247698d18f6a671 Mon Sep 17 00:00:00 2001
From: Ville Tervo <ville.tervo@nokia.com>
Date: Fri, 26 Feb 2010 12:21:01 +0200
Subject: [PATCH] Bluetooth: Drop rfcomm session reference only once for incoming session
Move decision to drop reference for incoming session to
rfcomm_session_close to get more clear
rfcomm_session_hold()/rfcomm_session_put() pairs.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
net/bluetooth/rfcomm/core.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 89f4a59..adccd92 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -662,6 +662,9 @@ static void rfcomm_session_close(struct rfcomm_session *s, int err)
BT_DBG("session %p state %ld err %d", s, s->state, err);
+ if (s->state == BT_CLOSED)
+ return;
+
rfcomm_session_hold(s);
s->state = BT_CLOSED;
@@ -674,6 +677,11 @@ static void rfcomm_session_close(struct rfcomm_session *s, int err)
}
rfcomm_session_clear_timer(s);
+
+ /* Drop reference for incoming sessions */
+ if (!s->initiator)
+ rfcomm_session_put(s);
+
rfcomm_session_put(s);
}
@@ -1150,11 +1158,7 @@ static int rfcomm_recv_ua(struct rfcomm_session *s, u8 dlci)
break;
case BT_DISCONN:
- /* When socket is closed and we are not RFCOMM
- * initiator rfcomm_process_rx already calls
- * rfcomm_session_put() */
- if (s->sock->sk->sk_state != BT_CLOSED)
- rfcomm_session_put(s);
+ rfcomm_session_close(s, 0);
break;
}
}
@@ -1185,7 +1189,6 @@ static int rfcomm_recv_dm(struct rfcomm_session *s, u8 dlci)
else
err = ECONNRESET;
- s->state = BT_CLOSED;
rfcomm_session_close(s, err);
}
return 0;
@@ -1220,7 +1223,6 @@ static int rfcomm_recv_disc(struct rfcomm_session *s, u8 dlci)
else
err = ECONNRESET;
- s->state = BT_CLOSED;
rfcomm_session_close(s, err);
}
@@ -1845,12 +1847,8 @@ static inline void rfcomm_process_rx(struct rfcomm_session *s)
rfcomm_recv_frame(s, skb);
}
- if (sk->sk_state == BT_CLOSED) {
- if (!s->initiator)
- rfcomm_session_put(s);
-
+ if (sk->sk_state == BT_CLOSED)
rfcomm_session_close(s, sk->sk_err);
- }
}
static inline void rfcomm_accept_connection(struct rfcomm_session *s)
@@ -1904,7 +1902,6 @@ static inline void rfcomm_check_connection(struct rfcomm_session *s)
break;
case BT_CLOSED:
- s->state = BT_CLOSED;
rfcomm_session_close(s, sk->sk_err);
break;
}
--
1.6.4.4
^ permalink raw reply related
* Re: DiscoverableTimeout not working as expected
From: Ross Burton @ 2010-02-26 10:29 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <2d5a2c101002260124w2a526e5bh4622af9658e179c0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
On Fri, 2010-02-26 at 11:24 +0200, Luiz Augusto von Dentz wrote:
> I got a different behavior (using git tree and testtest-adapter):
>
> signal sender=:1.65 -> dest=(null destination) serial=151
> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
> member=PropertyChanged
> string "DiscoverableTimeout"
> variant uint32 10
> signal sender=:1.65 -> dest=(null destination) serial=160
> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
> member=PropertyChanged
> string "Discoverable"
> variant boolean true
> signal sender=:1.65 -> dest=(null destination) serial=161
> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
> member=PropertyChanged
> string "Class"
> variant uint32 6430988
> signal sender=:1.65 -> dest=(null destination) serial=162
> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
> member=PropertyChanged
> string "Discoverable"
> variant boolean false
> signal sender=:1.65 -> dest=(null destination) serial=163
> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
> member=PropertyChanged
> string "Class"
> variant uint32 6422796
Interesting. Using test-adaptor and bluez 4.60 (debian sid), I don't
see that behaviour. I also can't see anything relevant in the git
log. :(
Ross
--
Intel Open Source Technology Centre
http://oss.intel.com/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: DiscoverableTimeout not working as expected
From: Luiz Augusto von Dentz @ 2010-02-26 11:58 UTC (permalink / raw)
To: Ross Burton; +Cc: linux-bluetooth
In-Reply-To: <1267180169.32051.20.camel@flashheart.burtonini.com>
Hi Ross,
On Fri, Feb 26, 2010 at 12:29 PM, Ross Burton <ross@linux.intel.com> wrote:
> On Fri, 2010-02-26 at 11:24 +0200, Luiz Augusto von Dentz wrote:
>> I got a different behavior (using git tree and testtest-adapter):
>>
>> signal sender=:1.65 -> dest=(null destination) serial=151
>> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
>> member=PropertyChanged
>> string "DiscoverableTimeout"
>> variant uint32 10
>> signal sender=:1.65 -> dest=(null destination) serial=160
>> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
>> member=PropertyChanged
>> string "Discoverable"
>> variant boolean true
>> signal sender=:1.65 -> dest=(null destination) serial=161
>> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
>> member=PropertyChanged
>> string "Class"
>> variant uint32 6430988
>> signal sender=:1.65 -> dest=(null destination) serial=162
>> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
>> member=PropertyChanged
>> string "Discoverable"
>> variant boolean false
>> signal sender=:1.65 -> dest=(null destination) serial=163
>> path=/org/bluez/3359/hci0; interface=org.bluez.Adapter;
>> member=PropertyChanged
>> string "Class"
>> variant uint32 6422796
>
> Interesting. Using test-adaptor and bluez 4.60 (debian sid), I don't
> see that behaviour. I also can't see anything relevant in the git
> log. :(
Please check if someone isn't sending
SetProperty("DiscoverableTimeout", 0), that will cancel the timeout
which seems the exact behavior that you are seeing with your
application, bluetooth-applet on ubuntu does that when I select Make
computer discoverable it set the timeout to 0.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Allow disable park state in main.conf
From: Liang Bao @ 2010-02-26 13:32 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 5652 bytes --]
Currently BlueZ is reading a bunch of configuration from main.conf.
However it hard-codes the default link policy to enable role switch,
hold mode, park state and sniff mode. We've found that there're some
Bluetooth devices such as Motorola HF850 can't work well when park
state is enabled. Once the link is parked, the Motorola HF850 car-kit
will fail to unpark and lose connection. After that the car-kit will
keep re-connect and disconnect. Also, if it's the remote device who
initiates connection, the connection will be stable but once the link
is in park state, the SCO connection can't be setup. Feedback from
accessory team is that park state often causes some interoperability
problem so it's used rarely now.
Because these devices have been available on market, one option is to
turn off park state on the phone side. Instead of making a blacklist
to include devices who have problem with park state, adding a single
configuration item to disable park state will provide the flexibility
with limited change. Default value for this configuration item will be
false to keep current behavior unchanged.
Here's the log captured with the HF850 and a Droid phone. Note
entering park state at 14:58:40.534427 and the connection timeout at
2010-01-05 14:58:46.372714. The Droid will keep entering park state,
detect timeout and accept re-connection.
2010-01-05 14:58:34.456210 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 1 mode 0x02 interval 2048
Mode: Sniff
2010-01-05 14:58:34.940677 > ACL data: handle 1 flags 0x02 dlen 19
L2CAP(d): cid 0x0041 len 15 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 20 pf 1 ilen 10 fcs 0x2d credits 1
A T + N R E C = 0 .
2010-01-05 14:58:34.951480 < ACL data: handle 1 flags 0x02 dlen 14
L2CAP(d): cid 0x004d len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 6 fcs 0xeb
. . O K . .
2010-01-05 14:58:36.217044 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 1
2010-01-05 14:58:37.500095 > ACL data: handle 1 flags 0x02 dlen 19
L2CAP(d): cid 0x0041 len 15 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 20 pf 1 ilen 10 fcs 0x2d credits 1
A T + C C W A = 1 .
2010-01-05 14:58:37.506900 < ACL data: handle 1 flags 0x02 dlen 14
L2CAP(d): cid 0x004d len 10 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 20 pf 0 ilen 6 fcs 0xeb
. . O K . .
2010-01-05 14:58:38.777072 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 1
2010-01-05 14:58:40.062412 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 1 mode 0x00 interval 0
Mode: Active
2010-01-05 14:58:40.534427 > HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 1 mode 0x03 interval 1152
Mode: Park
2010-01-05 14:58:46.372714 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1 reason 0x08
Reason: Connection Timeout
2010-01-05 14:58:47.689975 > HCI Event: Connect Request (0x04) plen 10
bdaddr 00:50:CD:20:BA:E6 class 0x200404 type ACL
2010-01-05 14:58:47.690097 < HCI Command: Accept Connection Request
(0x01|0x0009) plen 7
bdaddr 00:50:CD:20:BA:E6 role 0x00
Role: Master
2010-01-05 14:58:47.690616 > HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2010-01-05 14:58:47.851596 > HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:50:CD:20:BA:E6 role 0x00
Role: Master
2010-01-05 14:58:47.961978 > HCI Event: Link Key Request (0x17) plen 6
bdaddr 00:50:CD:20:BA:E6
2010-01-05 14:58:47.963748 < HCI Command: Link Key Request Reply
(0x01|0x000b) plen 22
bdaddr 00:50:CD:20:BA:E6 key 9752FA7985E81F9282DCDD80FB9C2B40
2010-01-05 14:58:47.964450 > HCI Event: Command Complete (0x0e) plen 10
Link Key Request Reply (0x01|0x000b) ncmd 1
status 0x00 bdaddr 00:50:CD:20:BA:E6
2010-01-05 14:58:48.076389 > HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 1 bdaddr 00:50:CD:20:BA:E6 type ACL encrypt 0x01
2010-01-05 14:58:48.076541 < HCI Command: Read Remote Supported
Features (0x01|0x001b) plen 2
handle 1
2010-01-05 14:58:48.076602 > HCI Event: Page Scan Repetition Mode
Change (0x20) plen 7
bdaddr 00:50:CD:20:BA:E6 mode 1
2010-01-05 14:58:48.077579 > HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-05 14:58:48.079257 > HCI Event: Max Slots Change (0x1b) plen 3
handle 1 slots 5
2010-01-05 14:58:48.079776 > ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x004e
2010-01-05 14:58:48.079898 < ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x004e result 1 status 0
Connection pending - No futher information available
2010-01-05 14:58:48.079959 < ACL data: handle 1 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
2010-01-05 14:58:48.083896 > HCI Event: Number of Completed Packets
(0x13) plen 5
handle 1 packets 2
2010-01-05 14:58:48.092990 > HCI Event: Read Remote Supported Features
(0x0b) plen 11
status 0x00 handle 1
Features: 0xff 0xff 0x8f 0xf8 0x18 0x18 0x00 0x80
2010-01-05 14:58:48.098422 < HCI Command: Remote Name Request
(0x01|0x0019) plen 10
bdaddr 00:50:CD:20:BA:E6 mode 2 clkoffset 0x0000
2010-01-05 14:58:48.098941 > HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-01-05 14:58:48.101444 > ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0000
2010-01-05 14:58:48.101596 < ACL data: handle 1 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x004e result 0 status 0
Connection successful
[-- Attachment #2: 0001-Allow-disable-park-state-in-main.conf.patch --]
[-- Type: text/x-diff, Size: 2182 bytes --]
From 331b120153c04694c73556c0287456a11874251f Mon Sep 17 00:00:00 2001
From: Tim Bao <tim.bao@gmail.com>
Date: Wed, 24 Feb 2010 20:48:29 +0800
Subject: [PATCH] Allow disable park state in main.conf
Currently BlueZ is hard-coding the default link policy to include
hold mode, role switch, sniff mode and park state. However, some
device will have problem to maintain the connection or setup SCO
if they are in park state. Making the park state configurable in
main.conf improves flexibility so it can be disabled when needed.
Signed-off-by: Tim Bao <tim.bao@gmail.com>
---
src/main.c | 13 +++++++++----
src/main.conf | 5 +++++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/src/main.c b/src/main.c
index 014d8b6..977c87b 100644
--- a/src/main.c
+++ b/src/main.c
@@ -201,10 +201,12 @@ static void parse_config(GKeyFile *config)
else
main_opts.name_resolv = boolean;
- main_opts.link_mode = HCI_LM_ACCEPT;
-
- main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
- HCI_LP_HOLD | HCI_LP_PARK;
+ boolean = g_key_file_get_boolean(config, "General",
+ "DisableParkState", &err);
+ if (err)
+ g_clear_error(&err);
+ else if (boolean)
+ main_opts.link_policy &= (~HCI_LP_PARK);
}
/*
@@ -276,6 +278,9 @@ static void init_defaults(void)
main_opts.remember_powered = TRUE;
main_opts.reverse_sdp = TRUE;
main_opts.name_resolv = TRUE;
+ main_opts.link_mode = HCI_LM_ACCEPT;
+ main_opts.link_policy = HCI_LP_RSWITCH | HCI_LP_SNIFF |
+ HCI_LP_HOLD | HCI_LP_PARK;
if (gethostname(main_opts.host_name, sizeof(main_opts.host_name) - 1) < 0)
strcpy(main_opts.host_name, "noname");
diff --git a/src/main.conf b/src/main.conf
index b252a82..6f975fc 100644
--- a/src/main.conf
+++ b/src/main.conf
@@ -50,3 +50,8 @@ ReverseServiceDiscovery = true
# Enable name resolving after inquiry. Set it to 'false' if you don't need
# remote devices name and want shorter discovery cycle. Defaults to 'true'.
NameResolving = true
+
+# Disable park state in default link policy. Some devices have connection
+# stability issue or fail to setup SCO when the link is in park state. Defaults
+# to 'false'.
+DisableParkState = false
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] Allow disable park state in main.conf
From: Johan Hedberg @ 2010-02-26 14:38 UTC (permalink / raw)
To: Liang Bao, marcel; +Cc: linux-bluetooth
In-Reply-To: <6aeb672b1002260532v6e209d7dr8370003463334b3@mail.gmail.com>
Hi,
On Fri, Feb 26, 2010, Liang Bao wrote:
> Currently BlueZ is hard-coding the default link policy to include
> hold mode, role switch, sniff mode and park state. However, some
> device will have problem to maintain the connection or setup SCO
> if they are in park state. Making the park state configurable in
> main.conf improves flexibility so it can be disabled when needed.
>
> Signed-off-by: Tim Bao <tim.bao@gmail.com>
> ---
> src/main.c | 13 +++++++++----
> src/main.conf | 5 +++++
> 2 files changed, 14 insertions(+), 4 deletions(-)
In principle the patch looks ok to me, however we might want to discuss
a little bit about the naming of the parameter in the config file and
its possible values. E.g. would it make sense to be able to define the
link policy more flexibly than just toggling park mode on and off.
Marcel, do you have any thoughts on this?
Johan
^ 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