* Re: Fix bluetoothd not starting on cold boot
From: Johan Hedberg @ 2010-09-22 19:28 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1285155481.13582.99.camel@cookie.hadess.net>
Hi Bastien,
On Wed, Sep 22, 2010, Bastien Nocera wrote:
> Subject: [PATCH] Also run bluetoothd on udev change events
>
> Fixes bluetoothd not starting on cold boot with newer versions
> of udev. See:
> https://bugzilla.redhat.com/show_bug.cgi?id=634205
> ---
> scripts/bluetooth.rules.in | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/bluetooth.rules.in b/scripts/bluetooth.rules.in
> index 6809e9d..64df69d 100644
> --- a/scripts/bluetooth.rules.in
> +++ b/scripts/bluetooth.rules.in
> @@ -1,3 +1,4 @@
> # Run helper every time a Bluetooth device appears
> # On remove actions, bluetoothd should go away by itself
> ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="@prefix@/sbin/bluetoothd --udev"
> +ACTION=="change", SUBSYSTEM=="bluetooth", RUN+="@prefix@/sbin/bluetoothd --udev"
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: Pull request: git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
From: Johan Hedberg @ 2010-09-22 19:39 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikcG2XRNDKSiq5b==JXo+YtPVJy9y4QWkBR9zdR@mail.gmail.com>
Hi Anderson,
On Wed, Sep 22, 2010, Anderson Lizardo wrote:
> The following changes since commit ec901c2428324ea2fe7d1bc2a2f3171ac5ed1950:
> Johan Hedberg (1):
> Fix reading local name from command complete event
>
> are available in the git repository at:
>
> git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
>
> Claudio Takahasi (9):
> Update characteristic value when a notification is received
> Return an error if the path doesn't exist when registering a watcher
> Add watcher's characteristic path verification before notify changes
> Watchers don't need to reply for characteristic value updates
> Change notification/indication output formating on gatttool
> Report attribute changes for the Battery Service
> Add missing response for handle value indication on attribute client
> Remove forward declaration on gattrib source
> Fix uninitialised value warning
>
> Vinicius Costa Gomes (6):
> Add encoders/decoders for Indication/Confirmation
> Add support to the server to sending Indications
> Add support for Indications to gatttool
> Add support for Indications to the client
> Add support for actively updating the watcher
> Add a way to unregister GAttrib events
>
> attrib/att.c | 50 +++++++++++++++++
> attrib/att.h | 3 +
> attrib/client.c | 113 +++++++++++++++++++++++++++++++++++++--
> attrib/example.c | 19 +++----
> attrib/gattrib.c | 150 ++++++++++++++++++++++++++++++++-------------------
> attrib/gatttool.c | 40 +++++++++-----
> src/attrib-server.c | 28 ++++++++++
> 7 files changed, 320 insertions(+), 83 deletions(-)
Thanks. All patches have been merged upstream.
Johan
^ permalink raw reply
* Pull request: git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
From: Anderson Lizardo @ 2010-09-22 20:37 UTC (permalink / raw)
To: linux-bluetooth
The following changes since commit a5e1be914ba5480f9eae7ab9dc31e30524f74182:
Claudio Takahasi (1):
Fix uninitialised value warning
are available in the git repository at:
git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
Claudio Takahasi (13):
Add g_attrib_set_destroy_function in gattrib
Use the destroy function to reset the GAttrib reference
Increment GAttrib reference for each GATT/ATT request
Fix disconnection when multiple watchers are registered
Fix seg fault if the watcher exit before the connection complete
Add UnregisterCharacteristicsWatcher implementation
Unregister the primary and characteristic objects
Fix memory leak of characteristic and primary service lists
Remove the timeout source function when the example server exits
Delete all stored data related to GATT/ATT when the device is removed
Fix wrong D-Bus object path for Device Service
Add a new property "Services" on the Device object
Fix coding style issues in attribute client code
attrib/client.c | 278 +++++++++++++++++++++++++++++++------------------
attrib/example.c | 9 ++-
attrib/example.h | 1 +
attrib/gattrib.c | 35 ++++--
attrib/gattrib.h | 3 +
attrib/manager.c | 1 +
doc/attribute-api.txt | 3 +-
doc/device-api.txt | 4 +
src/attrib-server.c | 11 ++-
src/device.c | 1 +
src/storage.c | 68 ++++++++++++
src/storage.h | 1 +
12 files changed, 297 insertions(+), 118 deletions(-)
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Fwd: Gumstix Overo running OE 2.6.34 Bluetooth Serial Device; Problem: cannot open /dev/rfcomm0: Connection refused or No such file or directory
From: Paul Matz @ 2010-09-22 20:42 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTimGmce2EqNMBS0qURCnfFFLtdTm7KttwdojDBZL@mail.gmail.com>
In addition to minicom failing to be able to open /dev/rfcomm0 (see
details below), we also noticed that rfcomm connect fails with this:
Can't connect RFCOMM socket: Connection refused
However, think I found something; https://bugs.archlinux.org/task/4930
Details
bluez changed the pin_helper concept in the last release. If
pairing with a device requires a PIN, then it will send a
dbus-message.
Unfortunately, there are currently no dbus helpers compatible with
the new bluez dbus API.
There is a small program called passkey-agent in the bluez-utils
source, which solves this problem.
If you call "passkey-agent --default <pin>" just before the
pairing attempt, it will use the right pin.
This program is built with bluez-utils, but make install ignores it.
Fix: Add install -D -m755
$startdir/src/bluez-utils-3.1/hcid/passkey-agent
$startdir/pkg/usr/bin/passkey-agent to the PKGBUILD.
In bluez-4.71 (bluez4), there appears to be no more utils release;
(last one was bluez-utils-3.36).
Looking thru the source right now to see if there's some sort of
equivalent utility.
Anybody know what's up in the most recent release of bluez?
Thanks in advance,
-PEM
---------- Forwarded message ----------
From: Paul Matz <paul@osterhoutgroup.com>
Date: Mon, Sep 20, 2010 at 1:11 PM
Subject: Overo running OE 2.6.34 Bluetooth Serial Device; Problem:
cannot open /dev/rfcomm0: Connection refused or No such file or
directory
To: gumstix-users@lists.sourceforge.net
We are trying to read input from a Bluetooth embedded serial device.
We are using the bluez4-4.66-r7.0 stack in Open Embedded 2.6.34.
We have been assuming that once the serial BT device pairs and
connects, that we can use rfcomm to map it to a /dev/rfcomm0 serial
device that we can open and read.
The BT serial device is sending data out continuously. We find that
we can pair it with other systems - Windows for example - and see
serial data blasting out of it.
A lot works, but not enough. Unsure if pairing is happening
successfully. Can't seem to get debug info to turn on, (Tried
launching bluetoothd with -d, but doesn't seem to help).
Here's what we see.
root@overo:~# hcitool scan
Scanning ...
34:15:9E:90:D9:E6 ODG10050
00:12:A1:B0:5B:4A SPP-B
root@overo:~# hcitool inq
Inquiring ...
34:15:9E:90:D9:E6 clock offset: 0x4129 class: 0x38010c
00:12:A1:B0:5B:4A clock offset: 0x3305 class: 0x001f00
(The serial device, SPP-B, does have a weird class; not sure if this
is OK or not).
root@overo:~# hciconfig -a
hci0: Type: BR/EDR Bus: UART
BD Address: 00:19:88:39:F3:90 ACL MTU: 310:10 SCO MTU: 64:8
UP RUNNING PSCAN
RX bytes:1419 acl:0 sco:0 events:51 errors:0
TX bytes:389 acl:0 sco:0 commands:26 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'overo-0'
Class: 0x4a0100
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Uncategorized
HCI Version: 2.0 (0x3) Revision: 0xc5c
LMP Version: 2.0 (0x3) Subversion: 0xc5c
Manufacturer: Cambridge Silicon Radio (10)
root@overo:~# hcitool info 00:12:A1:B0:5B:4A
Requesting information ...
BD Address: 00:12:A1:B0:5B:4A
Device Name: SPP-B
LMP Version: 2.0 (0x3) LMP Subversion: 0x10b7
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
<power control> <transparent SCO> <broadcast encrypt>
<EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <inquiry with RSSI>
<extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>
<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>
<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features>
root@overo:~# rfcomm bind 0
root@overo:~# rfcomm
rfcomm0: 00:12:A1:B0:5B:4A channel 2 clean
Processes running of interest:
PID TTY STAT TIME COMMAND
874 ? S 0:00 /usr/sbin/hciattach -s 115200 ttyS1 csr 115200 noflow
878 ? S<s 0:00 /usr/sbin/bluetoothd --udev
884 ? S 0:00 /usr/bin/rfcomm -r watch 0 1 /sbin/getty -w -L rfcomm
Devices of interest:
root@overo:~# ls -alFgt /dev | head
crw------- 1 tty 4, 66 Sep 2 20:33 ttyS2
crw------- 1 root 4, 12 Sep 2 20:33 tty12
crw-rw---- 1 users 216, 0 Sep 2 20:23 rfcomm0
crw--w--w- 1 root 4, 1 Sep 2 20:03 tty1
crw------- 1 root 5, 1 Sep 2 20:03 console
crw-rw---- 1 dialout 4, 65 Sep 2 20:03 ttyS1
Trying to attach to it using minicom fails:
root@overo:~# minicom
minicom: cannot open /dev/rfcomm0: Connection refused
(sometimes the error is minicom: cannot open /dev/rfcomm0: No such
file or directory)
The suspicion is that we don't have the default pin configured
correctly, even though we've put it into the right file.
When security mode is set to user, there is suppose to be prompting
for the pin, but this doesn't work.
Attached below are some of the configuration files we have set up:
/etc/default/bluetooth :
HCIATTACH_ENABLE=true
HCIATTACH_TTY=ttyS1
HCIATTACH_TYPE=csr
HCIATTACH_START_SPEED=115200
HCIATTACH_SPEED=115200
HCIATTACH_HANDSHAKE=noflow
HCID_ENABLE=true
HCID_CONFIG="/etc/bluetooth/hcid.conf"
SDPD_ENABLE=true
HIDD_ENABLE=false
#HIDD_OPTIONS=""
HID2HCI_ENABLE=true
RFCOMM_ENABLE=true
RFCOMM_CONFIG="/etc/bluetooth/rfcomm.conf"
DUND_ENABLE=false
DUND_OPTIONS="--listen --persist"
PAND_ENABLE=false
#PAND_OPTIONS="--listen --role NAP"
#PAND_OPTIONS="--role PANU --search --service NAP -sdp --persist"
/etc/bluetooth/hcid.conf:
options {
autoinit yes;
security none; # tried auto & user here too...
pairing multi;
passkey "0000";
}
device {
name "%h-%d";
class 0x3e0100;
#pkt_type DH1,DM1,HV1;
iscan enable; pscan enable;
lm accept,master;
lp rswitch,hold,sniff,park;
}
device 00:12:A1:B0:5B:4A {
name "SPP-B"
}
/etc/bluetooth/rfcomm.conf:
rfcomm0 {
bind yes;
device 00:12:A1:B0:5B:4A;
channel 2;
comment "9 axis contoller Bluetooth device";
}
/etc/bluetooth/main.conf:
[General]
Name = %h-%d
Class = 0x000100
DiscoverableTimeout = 0
PairableTimeout = 0
PageTimeout = 8192
DiscoverSchedulerInterval = 0
InitiallyPowered = true
RememberPowered = true
#DeviceID = 1234:5678:abcd
ReverseServiceDiscovery = true
NameResolving = true
DebugKeys = false
--
Regards,
Paul Matz
Director, Software & Architecture
Osterhout Design Group - 153 Townsend St., STE 570, SF, CA 94107
Desk: 415 644 4030 Cell: 415 652 4077
--
Regards,
Paul Matz
Director, Software & Architecture
Osterhout Design Group - 153 Townsend St., STE 570, SF, CA 94107
Desk: 415 644 4030 Cell: 415 652 4077
^ permalink raw reply
* Re: Pull request: git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
From: Johan Hedberg @ 2010-09-22 21:04 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimxWsv_6809nrodxcPkhwdcuc8kVFCWM5JcYv68@mail.gmail.com>
Hi Anderson,
On Wed, Sep 22, 2010, Anderson Lizardo wrote:
> The following changes since commit a5e1be914ba5480f9eae7ab9dc31e30524f74182:
> Claudio Takahasi (1):
> Fix uninitialised value warning
>
> are available in the git repository at:
>
> git://gitorious.org/~lizardo/bluez/lizardo-bluez.git for-upstream
>
> Claudio Takahasi (13):
> Add g_attrib_set_destroy_function in gattrib
> Use the destroy function to reset the GAttrib reference
> Increment GAttrib reference for each GATT/ATT request
> Fix disconnection when multiple watchers are registered
> Fix seg fault if the watcher exit before the connection complete
> Add UnregisterCharacteristicsWatcher implementation
> Unregister the primary and characteristic objects
> Fix memory leak of characteristic and primary service lists
> Remove the timeout source function when the example server exits
> Delete all stored data related to GATT/ATT when the device is removed
> Fix wrong D-Bus object path for Device Service
> Add a new property "Services" on the Device object
> Fix coding style issues in attribute client code
>
> attrib/client.c | 278 +++++++++++++++++++++++++++++++------------------
> attrib/example.c | 9 ++-
> attrib/example.h | 1 +
> attrib/gattrib.c | 35 ++++--
> attrib/gattrib.h | 3 +
> attrib/manager.c | 1 +
> doc/attribute-api.txt | 3 +-
> doc/device-api.txt | 4 +
> src/attrib-server.c | 11 ++-
> src/device.c | 1 +
> src/storage.c | 68 ++++++++++++
> src/storage.h | 1 +
> 12 files changed, 297 insertions(+), 118 deletions(-)
Thanks. All patches have been merged upstream.
Johan
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: support to send power management enable during hci open
From: Pavan Savoy @ 2010-09-22 21:22 UTC (permalink / raw)
To: Suraj Sumangala
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <4C997F8C.5070104@Atheros.com>
Suraj,
On Tue, Sep 21, 2010 at 11:01 PM, Suraj Sumangala <suraj@atheros.com> wrote:
> Hi Pavan,
>
> On 9/22/2010 1:22 AM, Pavan Savoy wrote:
>>
>> On Tue, Sep 21, 2010 at 8:33 AM, Suraj Sumangala<suraj@atheros.com>
>> wrote:
>>>
>>> This patch enables HCI_UART_ATH3K transport driver to support
>>> sending Vendor specific hci commands during hci open
>>> to enable or disable power management feature.
>>
>> Why? shouldn't this be done from the hciattach? like for the other
>> manufacturers?
>> If you want it to be sent before hci0 interface is exposed, send it
>> over ttyXX, you have your _init function and if you require it to be
>> sent after the hci0 is exposed - do it in the _post function.
>>
> We are already using the _init and _post of hciattach.
>
> The mentioned feature will get disabled in the controller on receiving a HCI
> RESET command.
>
> If the user does an HCI close, this feature will be disabled and we need to
> enable it again when the user opens the HCI device again.
>
> I guess the "hdev->driver_init" queue is provided for that reason.
>
> An hciattach is called only once but hci open/close can be done multiple
> times.
Well this is debatable, I guess we had this discussion when our
manufacturer came up with PM feature like this - As to what is the
right BT on procedure?
Should hciattach be terminated when BT is Off or is it just a
hciconfig hci0 down - So we decided to get rid of hciattach way of
doing things.
Also HCI_QUIRK_NO_RESET allows you to not to have reset .. in certain
cases, I guess with this your chip's firmware is able to remember the
PM settings previously sent across?
> Regards
> Suraj
>
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: support to send power management enable during hci open
From: Suraj Sumangala @ 2010-09-23 4:13 UTC (permalink / raw)
To: Pavan Savoy
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <AANLkTikKLi1m8xTjzU_aOs+XNstenjTAUSmgbQxOGnkC@mail.gmail.com>
Hi Pavan,
On 9/23/2010 2:52 AM, Pavan Savoy wrote:
> Suraj,
>
> On Tue, Sep 21, 2010 at 11:01 PM, Suraj Sumangala<suraj@atheros.com> wrote:
>> Hi Pavan,
>>
>> On 9/22/2010 1:22 AM, Pavan Savoy wrote:
>>>
>>> On Tue, Sep 21, 2010 at 8:33 AM, Suraj Sumangala<suraj@atheros.com>
>>> wrote:
>>>>
>>>> This patch enables HCI_UART_ATH3K transport driver to support
>>>> sending Vendor specific hci commands during hci open
>>>> to enable or disable power management feature.
>>>
>>> Why? shouldn't this be done from the hciattach? like for the other
>>> manufacturers?
>>> If you want it to be sent before hci0 interface is exposed, send it
>>> over ttyXX, you have your _init function and if you require it to be
>>> sent after the hci0 is exposed - do it in the _post function.
>>>
>> We are already using the _init and _post of hciattach.
>>
>> The mentioned feature will get disabled in the controller on receiving a HCI
>> RESET command.
>>
>> If the user does an HCI close, this feature will be disabled and we need to
>> enable it again when the user opens the HCI device again.
>>
>> I guess the "hdev->driver_init" queue is provided for that reason.
>>
>> An hciattach is called only once but hci open/close can be done multiple
>> times.
>
> Well this is debatable, I guess we had this discussion when our
> manufacturer came up with PM feature like this - As to what is the
> right BT on procedure?
> Should hciattach be terminated when BT is Off or is it just a
> hciconfig hci0 down - So we decided to get rid of hciattach way of
> doing things.
Yes, it would work fine for me too on a customer platform. but my idea
was to get it working on a generic x86 system running a normal distribution.
Moreover, if you looks at the "hdev->driver_init" queue, it looks like
it is meant for exactly this requirement. Bluez already have code in
hci_init_req() to take care of this scenario.
>
> Also HCI_QUIRK_NO_RESET allows you to not to have reset .. in certain
> cases, I guess with this your chip's firmware is able to remember the
> PM settings previously sent across?
HCI_QUIRK_NO_RESET only lets you not send a HCI reset during
initialization. I have no issues there, I am using the _post callback in
hciattach to configure PM.
I am doing the testing in Ubuntu 10.04 using the Blueman as my Bluetooth
agent.
From the UI if the user does a BT off. It sends an HCI reset command
followed by ah HCI close. This is causing the firmware forget the PM
parameters.
>
>> Regards
>> Suraj
>>
Regards
Suraj
^ permalink raw reply
* Bluez simple-agent vs agent
From: Viswanathan Sankararam @ 2010-09-23 7:46 UTC (permalink / raw)
To: linux-bluetooth
All,
I am new to bluetooth and bluez. I am having problems pairing my
bluetooth keyboard to my target that does not have python and so in
order to pair, I have compiled the agent application. My target has
Bluez 4.47. But I have not been able to get it to pair. After running
agent -a hci0 1234 00:1F:20:06:47:65
I get asked to enter the pin on the bt keyboard and then it says Agent
is released. When I list devices using
dbus-send --system --dest=org.bluez --print-reply $BTADAPTER
org.bluez.Adapter.ListDevices
I see it in the list and when I repeat the command, it disappears.
When I log on to my gentoo machine to pair the bt keyboard, I am able
to pair with the simple-agent python script but not the agent
application. The way the agent application behaves is the same as it
behaves when I use it on the target.My gentoo system uses Bluez 4.69.
Below is the log when I run bluetoothd with the -d option for the
simple-agent case and the agent C program case. As you can see, in the
simple-agent case, the device_probe_drivers gets called but in the
agent.c case, discover_services_req_exit gets called. This is the
place where they diverge. Also, I am not sure why the dbus system
daemon is rejecting a message from agent to org.bluez. I am nto sure
if its related. I am not able to proceed from here. Has any one faced
this kind of issue? Please advice me on how to proceed. I would really
appreciate it.
Thanks
Vishwa
simple-agent:
Sep 22 22:59:40 Zatoichi
bluetoothd[7042]:src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
src/device.c:device_create() Creating device
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_ref() 0xb899f6b8: ref=1
Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
src/device.c:bonding_request_new()
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
src/device.c:bonding_request_new() Temporary agent registered for
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at :1.29:/test/agent
Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 22 22:59:41 Zatoichi bluetoothd[7042]: Authentication requested
Sep 22 22:59:41 Zatoichi bluetoothd[7042]: link_key_request
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
src/security.c:link_key_request() kernel auth requirements = 0x03
Sep 22 22:59:41 Zatoichi bluetoothd[7042]: pin_code_request
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
src/device.c:device_request_authentication()
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
authentication
Sep 22 22:59:47 Zatoichi bluetoothd[7042]: link_key_notify
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
0xff new key type 0x00
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
auth 0xff
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
0x00
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_ref() 0xb899f6b8: ref=2
Sep 22 22:59:47 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
Releasing agent :1.29, /test/agent
Sep 22 22:59:47 Zatoichi dbus-daemon: [system] Rejected send message,
1 matched rules; type="method_return", sender=":1.29" (uid=0 pid=7790
comm="/usr/bin/python2.6) interface="(unset)" member="(unset)" error
name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
comm="/usr/sbin/bluetoothd))
Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
src/device.c:device_probe_drivers() Probe drivers for
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
input/manager.c:hid_device_probe() path
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_ref() 0xb899f6b8: ref=3
Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
input/device.c:input_device_new() Registered interface org.bluez.Input
on path /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_unref() 0xb899f6b8: ref=2
agent.c:
Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
src/device.c:device_create() Creating device
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_ref() 0xb899f6b8: ref=1
Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
src/device.c:bonding_request_new()
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
src/device.c:bonding_request_new() Temporary agent registered for
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at
:1.35:/org/bluez/agent_8004
Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 23 00:14:35 Zatoichi bluetoothd[7042]: Authentication requested
Sep 23 00:14:35 Zatoichi bluetoothd[7042]: link_key_request
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
src/security.c:link_key_request() kernel auth requirements = 0x03
Sep 23 00:14:35 Zatoichi bluetoothd[7042]: pin_code_request
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
src/device.c:device_request_authentication()
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
authentication
Sep 23 00:14:38 Zatoichi bluetoothd[7042]: link_key_notify
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
0xff new key type 0x00
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
auth 0xff
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
0x00
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_ref() 0xb899f6b8: ref=2
Sep 23 00:14:38 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
Releasing agent :1.35, /org/bluez/agent_8004
Sep 23 00:14:38 Zatoichi dbus-daemon: [system] Rejected send message,
1 matched rules; type="method_return", sender=":1.35" (uid=1000
pid=8004 comm="./agent) interface="(unset)" member="(unset)" error
name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
comm="/usr/sbin/bluetoothd))
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/device.c:discover_services_req_exit() DiscoverServices requestor
exited
Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_unref() 0xb899f6b8: ref=1
Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
src/adapter.c:adapter_remove_connection() Removing temporary device
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
src/device.c:device_remove() Removing device
/org/bluez/7041/hci0/dev_00_1F_20_06_47_65
Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
src/device.c:btd_device_unref() 0xb899f6b8: ref=0
Sep 23 00:14:40 Zatoichi bluetoothd[7042]: src/device.c:device_free() 0xb899f6b8
^ permalink raw reply
* [PATCH] Fix headset disconnecting via device disconnect
From: Radoslaw Jablonski @ 2010-09-23 10:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Headsets for proper disconnecting need to disconnect profiles in specified
order(by ex. disconnect a2dp, then sink and hfp at the end). Instead of
adding separate callbacks for disconnecting each profile, now adding only
one callback in audio/device.c for calling audio disconnect functions in
correct order. New disconnect callback works similarly to dev_disconnect
from audio/device.c
---
audio/device.c | 138 +++++++++++++++++++++++++++++++++++++------------------
audio/headset.c | 19 --------
audio/sink.c | 29 ------------
audio/source.c | 33 -------------
4 files changed, 93 insertions(+), 126 deletions(-)
diff --git a/audio/device.c b/audio/device.c
index b30590e..eec67be 100644
--- a/audio/device.c
+++ b/audio/device.c
@@ -91,7 +91,9 @@ struct dev_priv {
guint control_timer;
guint avdtp_timer;
guint headset_timer;
+ guint dc_id;
+ gboolean disconnecting;
gboolean authorized;
guint auth_idle_id;
};
@@ -123,6 +125,9 @@ static void device_free(struct audio_device *dev)
dbus_message_unref(priv->dc_req);
if (priv->conn_req)
dbus_message_unref(priv->conn_req);
+ if (priv->dc_id)
+ device_remove_disconnect_watch(dev->btd_dev,
+ priv->dc_id);
g_free(priv);
}
@@ -145,6 +150,69 @@ static const char *state2str(audio_state_t state)
}
}
+static gboolean control_connect_timeout(gpointer user_data)
+{
+ struct audio_device *dev = user_data;
+
+ dev->priv->control_timer = 0;
+
+ if (dev->control)
+ avrcp_connect(dev);
+
+ return FALSE;
+}
+
+static gboolean device_set_control_timer(struct audio_device *dev)
+{
+ struct dev_priv *priv = dev->priv;
+
+ if (!dev->control)
+ return FALSE;
+
+ if (priv->control_timer)
+ return FALSE;
+
+ priv->control_timer = g_timeout_add_seconds(CONTROL_CONNECT_TIMEOUT,
+ control_connect_timeout,
+ dev);
+
+ return TRUE;
+}
+
+static void device_remove_control_timer(struct audio_device *dev)
+{
+ if (dev->priv->control_timer)
+ g_source_remove(dev->priv->control_timer);
+ dev->priv->control_timer = 0;
+}
+
+static void disconnect_cb(struct btd_device *btd_dev, gboolean removal,
+ void *user_data)
+{
+ struct audio_device *dev = user_data;
+ struct dev_priv *priv = dev->priv;
+
+ if (priv->state == AUDIO_STATE_DISCONNECTED)
+ return;
+
+ if (priv->disconnecting)
+ return;
+
+ priv->disconnecting = TRUE;
+
+ if (dev->control) {
+ device_remove_control_timer(dev);
+ avrcp_disconnect(dev);
+ }
+
+ if (dev->sink && priv->sink_state != SINK_STATE_DISCONNECTED)
+ sink_shutdown(dev->sink);
+ else if (priv->hs_state != HEADSET_STATE_DISCONNECTED)
+ headset_shutdown(dev);
+ else
+ priv->disconnecting = FALSE;
+}
+
static void device_set_state(struct audio_device *dev, audio_state_t new_state)
{
struct dev_priv *priv = dev->priv;
@@ -155,9 +223,21 @@ static void device_set_state(struct audio_device *dev, audio_state_t new_state)
if (!state_str)
return;
- if (new_state == AUDIO_STATE_DISCONNECTED)
+ if (new_state == AUDIO_STATE_DISCONNECTED) {
priv->authorized = FALSE;
+ if (priv->dc_id) {
+ device_remove_disconnect_watch(dev->btd_dev,
+ priv->dc_id);
+ priv->dc_id = 0;
+ }
+ }
+ else if (new_state == AUDIO_STATE_CONNECTED) {
+ priv->disconnecting = FALSE;
+ priv->dc_id = device_add_disconnect_watch(dev->btd_dev,
+ disconnect_cb, dev, NULL);
+ }
+
if (dev->priv->state == new_state) {
DBG("state change attempted from %s to %s",
state_str, state_str);
@@ -166,11 +246,15 @@ static void device_set_state(struct audio_device *dev, audio_state_t new_state)
dev->priv->state = new_state;
- if (priv->dc_req && new_state == AUDIO_STATE_DISCONNECTED) {
- reply = dbus_message_new_method_return(priv->dc_req);
- dbus_message_unref(priv->dc_req);
- priv->dc_req = NULL;
- g_dbus_send_message(dev->conn, reply);
+ if (new_state == AUDIO_STATE_DISCONNECTED) {
+ if (priv->dc_req) {
+ reply = dbus_message_new_method_return(priv->dc_req);
+ dbus_message_unref(priv->dc_req);
+ priv->dc_req = NULL;
+ g_dbus_send_message(dev->conn, reply);
+ }
+ else if (priv->disconnecting)
+ priv->disconnecting = FALSE;
}
if (priv->conn_req && new_state != AUDIO_STATE_CONNECTING) {
@@ -191,42 +275,6 @@ static void device_set_state(struct audio_device *dev, audio_state_t new_state)
DBUS_TYPE_STRING, &state_str);
}
-static gboolean control_connect_timeout(gpointer user_data)
-{
- struct audio_device *dev = user_data;
-
- dev->priv->control_timer = 0;
-
- if (dev->control)
- avrcp_connect(dev);
-
- return FALSE;
-}
-
-static gboolean device_set_control_timer(struct audio_device *dev)
-{
- struct dev_priv *priv = dev->priv;
-
- if (!dev->control)
- return FALSE;
-
- if (priv->control_timer)
- return FALSE;
-
- priv->control_timer = g_timeout_add_seconds(CONTROL_CONNECT_TIMEOUT,
- control_connect_timeout,
- dev);
-
- return TRUE;
-}
-
-static void device_remove_control_timer(struct audio_device *dev)
-{
- if (dev->priv->control_timer)
- g_source_remove(dev->priv->control_timer);
- dev->priv->control_timer = 0;
-}
-
static gboolean avdtp_connect_timeout(gpointer user_data)
{
struct audio_device *dev = user_data;
@@ -348,7 +396,7 @@ static void device_sink_cb(struct audio_device *dev,
avrcp_disconnect(dev);
}
if (priv->hs_state != HEADSET_STATE_DISCONNECTED &&
- priv->dc_req) {
+ (priv->dc_req || priv->disconnecting)) {
headset_shutdown(dev);
break;
}
@@ -427,8 +475,8 @@ static void device_headset_cb(struct audio_device *dev,
switch (new_state) {
case HEADSET_STATE_DISCONNECTED:
device_remove_avdtp_timer(dev);
- if (priv->sink_state != SINK_STATE_DISCONNECTED &&
- dev->sink && priv->dc_req) {
+ if (priv->sink_state != SINK_STATE_DISCONNECTED && dev->sink &&
+ (priv->dc_req || priv->disconnecting)) {
sink_shutdown(dev->sink);
break;
}
diff --git a/audio/headset.c b/audio/headset.c
index dad0716..9955d4b 100644
--- a/audio/headset.c
+++ b/audio/headset.c
@@ -158,7 +158,6 @@ struct headset {
GIOChannel *tmp_rfcomm;
GIOChannel *sco;
guint sco_id;
- guint dc_id;
gboolean auto_dc;
@@ -2162,9 +2161,6 @@ static void headset_free(struct audio_device *dev)
hs->dc_timer = 0;
}
- if (hs->dc_id)
- device_remove_disconnect_watch(dev->btd_dev, hs->dc_id);
-
close_sco(dev);
headset_close_rfcomm(dev);
@@ -2477,16 +2473,6 @@ int headset_connect_sco(struct audio_device *dev, GIOChannel *io)
return 0;
}
-static void disconnect_cb(struct btd_device *btd_dev, gboolean removal,
- void *user_data)
-{
- struct audio_device *device = user_data;
-
- info("Headset: disconnect %s", device->path);
-
- headset_shutdown(device);
-}
-
void headset_set_state(struct audio_device *dev, headset_state_t state)
{
struct headset *hs = dev->headset;
@@ -2520,8 +2506,6 @@ void headset_set_state(struct audio_device *dev, headset_state_t state)
telephony_device_disconnected(dev);
}
active_devices = g_slist_remove(active_devices, dev);
- device_remove_disconnect_watch(dev->btd_dev, hs->dc_id);
- hs->dc_id = 0;
break;
case HEADSET_STATE_CONNECTING:
emit_property_changed(dev->conn, dev->path,
@@ -2550,9 +2534,6 @@ void headset_set_state(struct audio_device *dev, headset_state_t state)
DBUS_TYPE_BOOLEAN, &value);
active_devices = g_slist_append(active_devices, dev);
telephony_device_connected(dev);
- hs->dc_id = device_add_disconnect_watch(dev->btd_dev,
- disconnect_cb,
- dev, NULL);
} else if (hs->state == HEADSET_STATE_PLAYING) {
value = FALSE;
g_dbus_emit_signal(dev->conn, dev->path,
diff --git a/audio/sink.c b/audio/sink.c
index 67cffee..eb90c21 100644
--- a/audio/sink.c
+++ b/audio/sink.c
@@ -61,7 +61,6 @@ struct sink {
struct avdtp *session;
struct avdtp_stream *stream;
unsigned int cb_id;
- guint dc_id;
guint retry_id;
avdtp_session_state_t session_state;
avdtp_state_t stream_state;
@@ -140,11 +139,6 @@ static void avdtp_state_callback(struct audio_device *dev,
emit_property_changed(dev->conn, dev->path,
AUDIO_SINK_INTERFACE, "Connected",
DBUS_TYPE_BOOLEAN, &value);
- if (sink->dc_id) {
- device_remove_disconnect_watch(dev->btd_dev,
- sink->dc_id);
- sink->dc_id = 0;
- }
}
sink_set_state(dev, SINK_STATE_DISCONNECTED);
break;
@@ -171,17 +165,6 @@ static void pending_request_free(struct audio_device *dev,
g_free(pending);
}
-static void disconnect_cb(struct btd_device *btd_dev, gboolean removal,
- void *user_data)
-{
- struct audio_device *device = user_data;
- struct sink *sink = device->sink;
-
- DBG("Sink: disconnect %s", device->path);
-
- avdtp_close(sink->session, sink->stream, TRUE);
-}
-
static void stream_state_changed(struct avdtp_stream *stream,
avdtp_state_t old_state,
avdtp_state_t new_state,
@@ -209,12 +192,6 @@ static void stream_state_changed(struct avdtp_stream *stream,
pending_request_free(dev, p);
}
- if (sink->dc_id) {
- device_remove_disconnect_watch(dev->btd_dev,
- sink->dc_id);
- sink->dc_id = 0;
- }
-
if (sink->session) {
avdtp_unref(sink->session);
sink->session = NULL;
@@ -234,9 +211,6 @@ static void stream_state_changed(struct avdtp_stream *stream,
AUDIO_SINK_INTERFACE,
"Connected",
DBUS_TYPE_BOOLEAN, &value);
- sink->dc_id = device_add_disconnect_watch(dev->btd_dev,
- disconnect_cb,
- dev, NULL);
} else if (old_state == AVDTP_STATE_STREAMING) {
value = FALSE;
g_dbus_emit_signal(dev->conn, dev->path,
@@ -601,9 +575,6 @@ static void sink_free(struct audio_device *dev)
avdtp_stream_remove_cb(sink->session, sink->stream,
sink->cb_id);
- if (sink->dc_id)
- device_remove_disconnect_watch(dev->btd_dev, sink->dc_id);
-
if (sink->session)
avdtp_unref(sink->session);
diff --git a/audio/source.c b/audio/source.c
index 01173f5..e8671ed 100644
--- a/audio/source.c
+++ b/audio/source.c
@@ -62,7 +62,6 @@ struct source {
struct avdtp *session;
struct avdtp_stream *stream;
unsigned int cb_id;
- guint dc_id;
guint retry_id;
avdtp_session_state_t session_state;
avdtp_state_t stream_state;
@@ -133,12 +132,6 @@ static void avdtp_state_callback(struct audio_device *dev,
switch (new_state) {
case AVDTP_SESSION_STATE_DISCONNECTED:
- if (source->state != SOURCE_STATE_CONNECTING &&
- source->dc_id) {
- device_remove_disconnect_watch(dev->btd_dev,
- source->dc_id);
- source->dc_id = 0;
- }
source_set_state(dev, SOURCE_STATE_DISCONNECTED);
break;
case AVDTP_SESSION_STATE_CONNECTING:
@@ -164,17 +157,6 @@ static void pending_request_free(struct audio_device *dev,
g_free(pending);
}
-static void disconnect_cb(struct btd_device *btd_dev, gboolean removal,
- void *user_data)
-{
- struct audio_device *device = user_data;
- struct source *source = device->source;
-
- DBG("Source: disconnect %s", device->path);
-
- avdtp_close(source->session, source->stream, TRUE);
-}
-
static void stream_state_changed(struct avdtp_stream *stream,
avdtp_state_t old_state,
avdtp_state_t new_state,
@@ -201,12 +183,6 @@ static void stream_state_changed(struct avdtp_stream *stream,
pending_request_free(dev, p);
}
- if (source->dc_id) {
- device_remove_disconnect_watch(dev->btd_dev,
- source->dc_id);
- source->dc_id = 0;
- }
-
if (source->session) {
avdtp_unref(source->session);
source->session = NULL;
@@ -215,12 +191,6 @@ static void stream_state_changed(struct avdtp_stream *stream,
source->cb_id = 0;
break;
case AVDTP_STATE_OPEN:
- if (old_state == AVDTP_STATE_CONFIGURED &&
- source->state == SOURCE_STATE_CONNECTING) {
- source->dc_id = device_add_disconnect_watch(dev->btd_dev,
- disconnect_cb,
- dev, NULL);
- }
source_set_state(dev, SOURCE_STATE_CONNECTED);
break;
case AVDTP_STATE_STREAMING:
@@ -536,9 +506,6 @@ static void source_free(struct audio_device *dev)
avdtp_stream_remove_cb(source->session, source->stream,
source->cb_id);
- if (source->dc_id)
- device_remove_disconnect_watch(dev->btd_dev, source->dc_id);
-
if (source->session)
avdtp_unref(source->session);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v4 2/2] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Ville Tervo @ 2010-09-23 11:51 UTC (permalink / raw)
To: ext Alan Ott
Cc: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Marcel Holtmann,
Stephane Chatty, Michael Poole, David S. Miller, Bastien Nocera,
Eric Dumazet, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1281990059-3562-3-git-send-email-alan@signal11.us>
Hi Alan,
One comment.
On Mon, Aug 16, 2010 at 10:20:59PM +0200, ext Alan Ott wrote:
> This patch adds support or getting and setting feature reports for bluetooth
> HID devices from HIDRAW.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
> ---
> net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++++++--
> net/bluetooth/hidp/hidp.h | 8 +++
> 2 files changed, 118 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index bfe641b..0e4880e 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -36,6 +36,7 @@
> #include <linux/file.h>
> #include <linux/init.h>
> #include <linux/wait.h>
> +#include <linux/mutex.h>
> #include <net/sock.h>
>
> #include <linux/input.h>
> @@ -313,6 +314,86 @@ static int hidp_send_report(struct hidp_session *session, struct hid_report *rep
> return hidp_queue_report(session, buf, rsize);
> }
>
> +static int hidp_get_raw_report(struct hid_device *hid,
> + unsigned char report_number,
> + unsigned char *data, size_t count,
> + unsigned char report_type)
> +{
> + struct hidp_session *session = hid->driver_data;
> + struct sk_buff *skb;
> + size_t len;
> + int numbered_reports = hid->report_enum[report_type].numbered;
> +
> + switch (report_type) {
> + case HID_FEATURE_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_FEATURE;
> + break;
> + case HID_INPUT_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_INPUT;
> + break;
> + case HID_OUTPUT_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_OUPUT;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (mutex_lock_interruptible(&session->report_mutex))
> + return -ERESTARTSYS;
> +
> + /* Set up our wait, and send the report request to the device. */
> + session->waiting_report_type = report_type & HIDP_DATA_RTYPE_MASK;
> + session->waiting_report_number = numbered_reports ? report_number : -1;
> + set_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + data[0] = report_number;
> + if (hidp_send_ctrl_message(hid->driver_data, report_type, data, 1))
> + goto err_eio;
> +
> + /* Wait for the return of the report. The returned report
> + gets put in session->report_return. */
> + while (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
> + int res;
> +
> + res = wait_event_interruptible_timeout(session->report_queue,
> + !test_bit(HIDP_WAITING_FOR_RETURN, &session->flags),
> + 5*HZ);
> + if (res == 0) {
> + /* timeout */
> + goto err_eio;
> + }
> + if (res < 0) {
> + /* signal */
> + goto err_restartsys;
> + }
> + }
> +
> + skb = session->report_return;
> + if (skb) {
> + len = skb->len < count ? skb->len : count;
> + memcpy(data, skb->data, len);
> +
> + kfree_skb(skb);
> + session->report_return = NULL;
> + } else {
> + /* Device returned a HANDSHAKE, indicating protocol error. */
> + len = -EIO;
> + }
> +
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> +
> + return len;
> +
> +err_restartsys:
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> + return -ERESTARTSYS;
> +err_eio:
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> + return -EIO;
> +}
How about a variable called ret and using that to return len or errno? It
would eliminate code dublication.
--
Ville
^ permalink raw reply
* Where "destroying" function definition is ?
From: Rafał Michalski @ 2010-09-23 12:06 UTC (permalink / raw)
To: linux-bluetooth
Hi
Does anybody know where "destroying" function is ? - pointer to this function is
stored in "destroy" field of agent_request structure, but I can't find
definition
of this function and place where this pointer (non-NULL) is passed.
This pointer is used as below - this is a piece of code from BlueZ
(release 4.71)
- src/agent.c file.
static void agent_request_free(struct agent_request *req, gboolean destroy)
{
if (req->msg)
dbus_message_unref(req->msg);
if (req->call)
dbus_pending_call_unref(req->call);
if (req->agent && req->agent->request)
req->agent->request = NULL;
if (destroy && req->destroy)
req->destroy(req->user_data);
/* where is the function that destroy points to ??? */
g_free(req);
}
Thanks for any help.
Best regards
Rafał Michalski
^ permalink raw reply
* [PATCH] Add test/test-attrib for testing Attribute API
From: Anderson Lizardo @ 2010-09-23 13:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
This is an initial version. Watcher registration is not working properly
yet. For now it will list all characteristics and its properties.
---
test/test-attrib | 93 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 93 insertions(+), 0 deletions(-)
create mode 100755 test/test-attrib
diff --git a/test/test-attrib b/test/test-attrib
new file mode 100755
index 0000000..bf3334b
--- /dev/null
+++ b/test/test-attrib
@@ -0,0 +1,93 @@
+#!/usr/bin/python
+import sys
+from optparse import OptionParser
+from xml.etree import ElementTree as ET
+from binascii import hexlify
+
+#import gobject
+import dbus
+#import dbus.service
+#import dbus.mainloop.glib
+
+#TEMPERATURE_UUID = "0000a006-0000-1000-8000-00805f9b34fb"
+
+def command_parse():
+ """Parse command line options."""
+
+ usage = """
+ Usage: %s [options]"""
+ parser = OptionParser(usage=usage)
+ parser.add_option("-i", "--adapter", action="store", type="string",
+ dest="adapter", help="Specify local adapter interface")
+ return parser.parse_args()
+
+# FIXME: implement a better way of discovering GATT services
+def gatt_services(device_path):
+ """Get GATT services for a given device."""
+
+ intro = dbus.Interface(bus.get_object("org.bluez", device_path),
+ "org.freedesktop.DBus.Introspectable")
+ tree = ET.fromstring(intro.Introspect())
+ services = [n.attrib["name"] for n in tree.getiterator("node")]
+ services = filter(lambda x: x.startswith("service"), services)
+ services = map(lambda x: device_path + "/" + x, services)
+
+ return services
+
+def characteristics(service_path):
+ """Get characteristics for a given GATT service."""
+
+ char = dbus.Interface(bus.get_object("org.bluez", service_path),
+ "org.bluez.Characteristic")
+
+ return char.GetCharacteristics()
+
+def dbus_type_str(d):
+ """Convert a D-Bus array to a hexdump."""
+
+ if isinstance(d, dbus.Array):
+ return hexlify("".join([str(x) for x in d]))
+ else:
+ return str(d)
+
+#class Watcher(dbus.service.Object):
+# @dbus.service.method("org.bluez.Watcher", in_signature="oay", out_signature="")
+# def ValueChanged(self, char, newvalue):
+# print "XXX: new value for %s: %s" % (char, newvalue)
+
+if __name__ == "__main__":
+ #dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
+ bus = dbus.SystemBus()
+ manager = dbus.Interface(bus.get_object("org.bluez", "/"),
+ "org.bluez.Manager")
+
+ (options, args) = command_parse()
+
+ if options.adapter:
+ path = manager.FindAdapter(options.adapter)
+ else:
+ path = manager.DefaultAdapter()
+
+ adapter = dbus.Interface(bus.get_object("org.bluez", path),
+ "org.bluez.Adapter")
+
+ #watcher = None
+
+ for d in adapter.GetProperties()["Devices"]:
+ for s in gatt_services(d):
+ for (path, props) in characteristics(s).iteritems():
+ ret = "Characteristic: %s\nProperties:\n" % path
+ for (k, v) in props.iteritems():
+ # FIXME: Watcher registration not working properly. We
+ # still need to figure out how to properly create the
+ # Object whose ValueChanged() method will be called
+ #if (k, v) == ["UUID", TEMPERATURE_UUID]:
+ # char = dbus.Interface(bus.get_object("org.bluez", s),
+ # "org.bluez.Characteristic")
+ # watcher = Watcher(bus, path)
+ # char.RegisterCharacteristicsWatcher(path)
+ ret += "\t%s: %s\n" % (k, dbus_type_str(v))
+ print ret
+
+ #mainloop = gobject.MainLoop()
+ #mainloop.run()
--
1.7.0.4
^ permalink raw reply related
* Fwd: Bluez simple-agent vs agent
From: Paul Matz @ 2010-09-23 13:36 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTikS2-eKiEP2ngqz6rW5JB-+eudtffw9QHykhbqq@mail.gmail.com>
This is a script that will allow us to generate the proper dbus
messages for the pin exchange. I'm not really sure how it works since
I haven't read much about the dbus IPC protocol. Interestingly
enough, it's checked into the linux kernel tree. Could this be the
source to the simple-agent binary in the bluez tar file?
http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=test/simple-agent;hb=HEAD
This is the python library that is required by the simple-agent script.
http://dbus.freedesktop.org/releases/dbus-python/
This works on a desktop, but we have an embedded system we are working
on that does not have the python stuff installed.
What I'm trying to figure out is how to create an agent that does what
the python script does.
One other problem I've got is that I can't get bluetoothd to generate
debug output. Starting it with -d, where does it write it's debug
output? /var/log/messages? Doesn't seem to.
-PEM
On Thu, Sep 23, 2010 at 12:46 AM, Viswanathan Sankararam
<developervishwa@gmail.com> wrote:
>
> All,
>
> I am new to bluetooth and bluez. I am having problems pairing my
> bluetooth keyboard to my target that does not have python and so in
> order to pair, I have compiled the agent application. My target has
> Bluez 4.47. But I have not been able to get it to pair. After running
>
> agent -a hci0 1234 00:1F:20:06:47:65
>
> I get asked to enter the pin on the bt keyboard and then it says Agent
> is released. When I list devices using
>
> dbus-send --system --dest=org.bluez --print-reply $BTADAPTER
> org.bluez.Adapter.ListDevices
>
> I see it in the list and when I repeat the command, it disappears.
>
> When I log on to my gentoo machine to pair the bt keyboard, I am able
> to pair with the simple-agent python script but not the agent
> application. The way the agent application behaves is the same as it
> behaves when I use it on the target.My gentoo system uses Bluez 4.69.
> Below is the log when I run bluetoothd with the -d option for the
> simple-agent case and the agent C program case. As you can see, in the
> simple-agent case, the device_probe_drivers gets called but in the
> agent.c case, discover_services_req_exit gets called. This is the
> place where they diverge. Also, I am not sure why the dbus system
> daemon is rejecting a message from agent to org.bluez. I am nto sure
> if its related. I am not able to proceed from here. Has any one faced
> this kind of issue? Please advice me on how to proceed. I would really
> appreciate it.
>
> Thanks
> Vishwa
>
> simple-agent:
>
> Sep 22 22:59:40 Zatoichi
> bluetoothd[7042]:src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
> src/device.c:device_create() Creating device
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_ref() 0xb899f6b8: ref=1
> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
> src/device.c:bonding_request_new()
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
> src/device.c:bonding_request_new() Temporary agent registered for
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at :1.29:/test/agent
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: Authentication requested
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: link_key_request
> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
> src/security.c:link_key_request() kernel auth requirements = 0x03
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: pin_code_request
> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
> src/device.c:device_request_authentication()
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
> authentication
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]: link_key_notify
> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
> 0xff new key type 0x00
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
> auth 0xff
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
> 0x00
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_ref() 0xb899f6b8: ref=2
> Sep 22 22:59:47 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
> Releasing agent :1.29, /test/agent
> Sep 22 22:59:47 Zatoichi dbus-daemon: [system] Rejected send message,
> 1 matched rules; type="method_return", sender=":1.29" (uid=0 pid=7790
> comm="/usr/bin/python2.6) interface="(unset)" member="(unset)" error
> name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
> comm="/usr/sbin/bluetoothd))
> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
> src/device.c:device_probe_drivers() Probe drivers for
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
> input/manager.c:hid_device_probe() path
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_ref() 0xb899f6b8: ref=3
> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
> input/device.c:input_device_new() Registered interface org.bluez.Input
> on path /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_unref() 0xb899f6b8: ref=2
>
> agent.c:
>
> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
> src/device.c:device_create() Creating device
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_ref() 0xb899f6b8: ref=1
> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
> src/device.c:bonding_request_new()
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
> src/device.c:bonding_request_new() Temporary agent registered for
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at
> :1.35:/org/bluez/agent_8004
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: Authentication requested
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: link_key_request
> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
> src/security.c:link_key_request() kernel auth requirements = 0x03
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: pin_code_request
> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
> src/device.c:device_request_authentication()
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
> authentication
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]: link_key_notify
> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
> 0xff new key type 0x00
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
> auth 0xff
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
> 0x00
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_ref() 0xb899f6b8: ref=2
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
> Releasing agent :1.35, /org/bluez/agent_8004
> Sep 23 00:14:38 Zatoichi dbus-daemon: [system] Rejected send message,
> 1 matched rules; type="method_return", sender=":1.35" (uid=1000
> pid=8004 comm="./agent) interface="(unset)" member="(unset)" error
> name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
> comm="/usr/sbin/bluetoothd))
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/device.c:discover_services_req_exit() DiscoverServices requestor
> exited
> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_unref() 0xb899f6b8: ref=1
> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
> src/adapter.c:adapter_remove_connection() Removing temporary device
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
> src/device.c:device_remove() Removing device
> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
> src/device.c:btd_device_unref() 0xb899f6b8: ref=0
> Sep 23 00:14:40 Zatoichi bluetoothd[7042]: src/device.c:device_free() 0xb899f6b8
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 2/2] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Alan Ott @ 2010-09-23 14:16 UTC (permalink / raw)
To: Ville Tervo
Cc: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Marcel Holtmann,
Stephane Chatty, Michael Poole, David S. Miller, Bastien Nocera,
Eric Dumazet, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20100923115108.GC2379@null>
On Sep 23, 2010, at 7:51 AM, Ville Tervo wrote:
> Hi Alan,
>
> One comment.
>
> How about a variable called ret and using that to return len or
> errno? It
> would eliminate code dublication.
>
Hi Ville,
Where specifically? In which function? I've gone through it a couple
of times and failed to find return statements which are superfluous.
Maybe I'm missing something fundamental?
Alan.
^ permalink raw reply
* RE: Where "destroying" function definition is ?
From: Waldemar.Rymarkiewicz @ 2010-09-23 14:32 UTC (permalink / raw)
To: michalski.raf, linux-bluetooth
In-Reply-To: <AANLkTinyQbC30-11CgVtjAhcnbykatBFJJ7rxC4v019L@mail.gmail.com>
Hi Robert,
>-----Original Message-----
>From: linux-bluetooth-owner@vger.kernel.org
>[mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of
>Rafał Michalski
>Sent: Thursday, September 23, 2010 2:07 PM
>To: linux-bluetooth@vger.kernel.org
>Subject: Where "destroying" function definition is ?
>
>Hi
>
>Does anybody know where "destroying" function is ? - pointer
>to this function is stored in "destroy" field of agent_request
>structure, but I can't find definition of this function and
>place where this pointer (non-NULL) is passed.
>This pointer is used as below - this is a piece of code from
>BlueZ (release 4.71)
>- src/agent.c file.
>
>static void agent_request_free(struct agent_request *req,
>gboolean destroy) {
> if (req->msg)
> dbus_message_unref(req->msg);
> if (req->call)
> dbus_pending_call_unref(req->call);
> if (req->agent && req->agent->request)
> req->agent->request = NULL;
> if (destroy && req->destroy)
> req->destroy(req->user_data);
> /* where is the function that destroy
>points to ??? */
> g_free(req);
>}
>
>Thanks for any help.
>
>Best regards
>Rafał Michalski
I'm not pretty sure but this feature seems be not used :)
In device.c function device_request_authentication() calls agent_request_* with NULL as the last param which is fact is a pointer to "distroying" function.
Regards,
/Waldek
^ permalink raw reply
* [PATCH] Fix problem with EIR data when setting the name
From: Lukasz Pawlik @ 2010-09-23 14:53 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-problem-with-EIR-data-when-setting-the-name.patch --]
[-- Type: text/x-patch, Size: 814 bytes --]
From 32c3108cc8a0734f3ee1187e9326dc7b84a332d7 Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Thu, 23 Sep 2010 16:27:39 +0200
Subject: [PATCH] Fix problem with EIR data when setting the name
Previously changed BT fiendly name was not reflected until BT adapter reboot.
This patch fix this problem. Now changed name is reflected without need of
rebooting adapter.
---
src/adapter.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 9b638cf..0e9be5f 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1031,6 +1031,7 @@ static DBusMessage *set_name(DBusConnection *conn, DBusMessage *msg,
return failed_strerror(msg, err);
adapter->name_stored = TRUE;
+ update_ext_inquiry_response(adapter);
}
done:
--
1.7.0.4
^ permalink raw reply related
* Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Claudio Takahasi @ 2010-09-23 16:19 UTC (permalink / raw)
To: BlueZ development
The following changes since commit e7b1d878d15c0eb1bc0109c19cbdf5f84a29394d:
Fix coding style issues in attribute client code (2010-09-22 16:33:15 -0400)
are available in the git repository at:
git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
Claudio Takahasi (23):
Add LE start and stop scanning
Remove RSSI field from the advertising report event
Decoding the RSSI parameter from the advertising report event
Send Discovering property "FALSE" when the interleave finishes
Add length argument on hciops start discovery function
Stop inquiry using the length parameter
Fix remote name resolution for interleave discovery
Add Write LE host supported function
Set the LE host supported and disable simultaneous LE and BR/EDR flags
Add extended feature mask constants definition
Read the local extended features
Stop LE scanning when discovery is suspended
Rename hciops {start, stop}_discovery to {start, stop}_inquiry
Don't enter on interleave mode if there isn't active sessions
Code cleanup: improving inquiry logic
Clear the remote device found list in the state transition
Fix periodic inquiry signals
Fixing DeviceDisappeared signal
Postpone discovery if still resolving names
Add adapter discovery type function
Do not send another Discovering TRUE signal if still resolving names
Forcing periodic inquiry exit
Fix interleave scanning
Vinicius Costa Gomes (1):
Add BR/EDR LE interleaved discovery
lib/hci.c | 29 +++++
lib/hci.h | 17 +++-
lib/hci_lib.h | 1 +
plugins/hciops.c | 53 +++++++++-
src/adapter.c | 302 +++++++++++++++++++++++++++++++++++++-----------------
src/adapter.h | 37 ++++---
src/dbus-hci.c | 45 +++++++--
src/dbus-hci.h | 1 +
src/security.c | 133 ++++++++++++++----------
9 files changed, 436 insertions(+), 182 deletions(-)
Implements interleave discovery for dual mode adapters(LE and BR/EDR).
Now, the behavior is:
1) for single mode: LE scanning for 5.12 seconds every DiscoverSchedulerInterval
2) for BR/EDR only: still the same
3) for dual mode: inquiry(5.12) sec, LE scanning(5.12) sec, resolve
names. The next discovery interval is controlled by
DiscoverSchedulerInterval.
Signals still the same, the idea is try to hide from the users/apps
the discovery internals. No mater the adapter type(LE only, BR/EDR or
Dual Mode)
PropertyChanged("Discovering", TRUE/FALSE) is sent to notify when a
new discovery "session" starts/finishes. Found LE devices are reported
using DeviceFound() signals.
Regards,
Claudio
--
--
Claudio Takahasi
Instituto Nokia de Tecnologia
Recife - Pernambuco - Brasil
+55 81 30879999
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Ville Tervo @ 2010-09-23 16:25 UTC (permalink / raw)
To: ext Alan Ott
Cc: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Marcel Holtmann,
Stephane Chatty, Michael Poole, David S. Miller, Bastien Nocera,
Eric Dumazet, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <1281990059-3562-1-git-send-email-alan@signal11.us>
Hi Alan,
On Mon, Aug 16, 2010 at 10:20:57PM +0200, ext Alan Ott wrote:
> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
I gave a try to to this patch using your test tool [1] and very old BT
keyboard. I don't have anything else ATM to test with. Is there some BT hid
devices which support setting and getting features?
Shouldn't HIDIOCSFEATURE's bt version have similar wait as HIDIOCGFEATURE to
get report status back from the device? or is there even any status coming back
in successful case? Sorry I'm a newbie with HID and trying to understand how
this should work.
Now it just returns num of send bytes even if the remote device returned some
error. Which one is the expected behavior?
Other problem is that Get report is getting now handshake from set report.
2010-09-23 17:55:46.680612 < ACL data: handle 38 flags 0x02 dlen 9
L2CAP(d): cid 0x008b len 5 [psm 17]
HIDP: Set report: Feature report
0000: 09 ff ff ff ....
2010-09-23 17:55:46.680653 < ACL data: handle 38 flags 0x02 dlen 6
L2CAP(d): cid 0x008b len 2 [psm 17]
HIDP: Get report: Feature report
0000: 09 .
2010-09-23 17:55:46.697577 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 38 packets 1
2010-09-23 17:55:46.698579 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 38 packets 1
2010-09-23 17:55:46.776827 > ACL data: handle 38 flags 0x02 dlen 5
L2CAP(d): cid 0x0040 len 1 [psm 17]
HIDP: Handshake: Invalid parameter
2010-09-23 17:55:46.777069 < ACL data: handle 38 flags 0x02 dlen 7
L2CAP(d): cid 0x008b len 3 [psm 17]
HIDP: Data: Output report
0000: 01 77 .w
2010-09-23 17:55:46.797577 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 38 packets 1
2010-09-23 17:55:46.816826 > ACL data: handle 38 flags 0x02 dlen 5
L2CAP(d): cid 0x0040 len 1 [psm 17]
HIDP: Handshake: Invalid parameter
2010-09-23 17:55:46.856828 > ACL data: handle 38 flags 0x02 dlen 5
L2CAP(d): cid 0x0040 len 1 [psm 17]
HIDP: Handshake: Unsupported request
[1] http://lkml.org/lkml/2010/6/17/414
--
Ville the HID newbie
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Ping Cheng @ 2010-09-23 17:07 UTC (permalink / raw)
To: Ville Tervo, Przemysław Firszt
Cc: ext Alan Ott, Jiri Kosina, Stefan Achatz, Antonio Ospite,
Alexey Dobriyan, Tejun Heo, Alan Stern, Greg Kroah-Hartman,
Marcel Holtmann, Stephane Chatty, Michael Poole, David S. Miller,
Bastien Nocera, Eric Dumazet, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20100923162521.GA15641@null>
On Thu, Sep 23, 2010 at 9:25 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> Hi Alan,
>
> On Mon, Aug 16, 2010 at 10:20:57PM +0200, ext Alan Ott wrote:
>> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
>
> I gave a try to to this patch using your test tool [1] and very old BT
> keyboard. I don't have anything else ATM to test with. Is there some BT hid
> devices which support setting and getting features?
As far as I know Wacom BT devices (Graphire and Intuos4) need to get
and set features.
Przemo,
Do you have time to test the patchset with your Graphire BT and
provide your result here?
Thank you,
Ping
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Luiz Augusto von Dentz @ 2010-09-23 17:55 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTindKFz1fx9cJMu9aSpehG5LaUHHO7TkgWqMzqj=@mail.gmail.com>
Hi Claudio,
On Thu, Sep 23, 2010 at 7:19 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Implements interleave discovery for dual mode adapters(LE and BR/EDR).
> Now, the behavior is:
> 1) for single mode: LE scanning for 5.12 seconds every DiscoverSchedulerInterval
> 2) for BR/EDR only: still the same
> 3) for dual mode: inquiry(5.12) sec, LE scanning(5.12) sec, resolve
> names. The next discovery interval is controlled by
> DiscoverSchedulerInterval.
Is that enough time to discover devices around? I remember tweaking
the interval so that it doesn't cause too much noise/too many new
devices found or disappearing in each round, so at least to BR/EDR
5.12 sec. sounds too little time, also does LE needs name resolving
too?
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Pull request: git://git.infradead.org/users/cktakahasi/bluez.git for-upstream
From: Claudio Takahasi @ 2010-09-23 18:07 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: BlueZ development
In-Reply-To: <AANLkTinAd=8HhDWBwgikS36zni6arb8WP9iXAZpqJ0Lk@mail.gmail.com>
On Thu, Sep 23, 2010 at 2:55 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Claudio,
>
> On Thu, Sep 23, 2010 at 7:19 PM, Claudio Takahasi
> <claudio.takahasi@openbossa.org> wrote:
>> Implements interleave discovery for dual mode adapters(LE and BR/EDR).
>> Now, the behavior is:
>> 1) for single mode: LE scanning for 5.12 seconds every DiscoverSchedulerInterval
>> 2) for BR/EDR only: still the same
>> 3) for dual mode: inquiry(5.12) sec, LE scanning(5.12) sec, resolve
>> names. The next discovery interval is controlled by
>> DiscoverSchedulerInterval.
>
> Is that enough time to discover devices around? I remember tweaking
> the interval so that it doesn't cause too much noise/too many new
> devices found or disappearing in each round, so at least to BR/EDR
> 5.12 sec. sounds too little time, also does LE needs name resolving
> too?
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
Hi Luiz,
5.12sec is based on the SPEC recommendation(core page 1746), we can
change it to 10.24s or add a config option.
For LE, there is a characteristic called "Device Name" UUID 0x2A00,
this piece is missing.
Regards,
Claudio
--
--
Claudio Takahasi
Instituto Nokia de Tecnologia
Recife - Pernambuco - Brasil
+55 81 30879999
^ permalink raw reply
* Re: Bluez simple-agent vs agent
From: Viswanathan Sankararam @ 2010-09-23 18:50 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTikAHAKe2WDMuAKEvCXh6jxGXFYYhfWPJkCGXUSp@mail.gmail.com>
Anyone, any ideas?
On Thu, Sep 23, 2010 at 6:36 AM, Paul Matz <paul@osterhoutgroup.com> wrote:
> This is a script that will allow us to generate the proper dbus
> messages for the pin exchange. I'm not really sure how it works since
> I haven't read much about the dbus IPC protocol. Interestingly
> enough, it's checked into the linux kernel tree. Could this be the
> source to the simple-agent binary in the bluez tar file?
> http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=test/simple-agent;hb=HEAD
>
> This is the python library that is required by the simple-agent script.
> http://dbus.freedesktop.org/releases/dbus-python/
>
> This works on a desktop, but we have an embedded system we are working
> on that does not have the python stuff installed.
> What I'm trying to figure out is how to create an agent that does what
> the python script does.
> One other problem I've got is that I can't get bluetoothd to generate
> debug output. Starting it with -d, where does it write it's debug
> output? /var/log/messages? Doesn't seem to.
>
> -PEM
>
> On Thu, Sep 23, 2010 at 12:46 AM, Viswanathan Sankararam
> <developervishwa@gmail.com> wrote:
>>
>> All,
>>
>> I am new to bluetooth and bluez. I am having problems pairing my
>> bluetooth keyboard to my target that does not have python and so in
>> order to pair, I have compiled the agent application. My target has
>> Bluez 4.47. But I have not been able to get it to pair. After running
>>
>> agent -a hci0 1234 00:1F:20:06:47:65
>>
>> I get asked to enter the pin on the bt keyboard and then it says Agent
>> is released. When I list devices using
>>
>> dbus-send --system --dest=org.bluez --print-reply $BTADAPTER
>> org.bluez.Adapter.ListDevices
>>
>> I see it in the list and when I repeat the command, it disappears.
>>
>> When I log on to my gentoo machine to pair the bt keyboard, I am able
>> to pair with the simple-agent python script but not the agent
>> application. The way the agent application behaves is the same as it
>> behaves when I use it on the target.My gentoo system uses Bluez 4.69.
>> Below is the log when I run bluetoothd with the -d option for the
>> simple-agent case and the agent C program case. As you can see, in the
>> simple-agent case, the device_probe_drivers gets called but in the
>> agent.c case, discover_services_req_exit gets called. This is the
>> place where they diverge. Also, I am not sure why the dbus system
>> daemon is rejecting a message from agent to org.bluez. I am nto sure
>> if its related. I am not able to proceed from here. Has any one faced
>> this kind of issue? Please advice me on how to proceed. I would really
>> appreciate it.
>>
>> Thanks
>> Vishwa
>>
>> simple-agent:
>>
>> Sep 22 22:59:40 Zatoichi
>> bluetoothd[7042]:src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>> src/device.c:device_create() Creating device
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_ref() 0xb899f6b8: ref=1
>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>> src/device.c:bonding_request_new()
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>> src/device.c:bonding_request_new() Temporary agent registered for
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at :1.29:/test/agent
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: Authentication requested
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: link_key_request
>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>> src/security.c:link_key_request() kernel auth requirements = 0x03
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: pin_code_request
>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>> src/device.c:device_request_authentication()
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
>> authentication
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]: link_key_notify
>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
>> 0xff new key type 0x00
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
>> auth 0xff
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
>> 0x00
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_ref() 0xb899f6b8: ref=2
>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
>> Releasing agent :1.29, /test/agent
>> Sep 22 22:59:47 Zatoichi dbus-daemon: [system] Rejected send message,
>> 1 matched rules; type="method_return", sender=":1.29" (uid=0 pid=7790
>> comm="/usr/bin/python2.6) interface="(unset)" member="(unset)" error
>> name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
>> comm="/usr/sbin/bluetoothd))
>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>> src/device.c:device_probe_drivers() Probe drivers for
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>> input/manager.c:hid_device_probe() path
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_ref() 0xb899f6b8: ref=3
>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>> input/device.c:input_device_new() Registered interface org.bluez.Input
>> on path /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_unref() 0xb899f6b8: ref=2
>>
>> agent.c:
>>
>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>> src/device.c:device_create() Creating device
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_ref() 0xb899f6b8: ref=1
>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>> src/device.c:bonding_request_new()
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>> src/device.c:bonding_request_new() Temporary agent registered for
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at
>> :1.35:/org/bluez/agent_8004
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: Authentication requested
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: link_key_request
>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>> src/security.c:link_key_request() kernel auth requirements = 0x03
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: pin_code_request
>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>> src/device.c:device_request_authentication()
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
>> authentication
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]: link_key_notify
>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
>> 0xff new key type 0x00
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
>> auth 0xff
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
>> 0x00
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_ref() 0xb899f6b8: ref=2
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
>> Releasing agent :1.35, /org/bluez/agent_8004
>> Sep 23 00:14:38 Zatoichi dbus-daemon: [system] Rejected send message,
>> 1 matched rules; type="method_return", sender=":1.35" (uid=1000
>> pid=8004 comm="./agent) interface="(unset)" member="(unset)" error
>> name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
>> comm="/usr/sbin/bluetoothd))
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/device.c:discover_services_req_exit() DiscoverServices requestor
>> exited
>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_unref() 0xb899f6b8: ref=1
>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
>> src/adapter.c:adapter_remove_connection() Removing temporary device
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
>> src/device.c:device_remove() Removing device
>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
>> src/device.c:btd_device_unref() 0xb899f6b8: ref=0
>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]: src/device.c:device_free() 0xb899f6b8
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Przemo Firszt @ 2010-09-23 20:16 UTC (permalink / raw)
To: Ping Cheng
Cc: Ville Tervo, ext Alan Ott, Jiri Kosina, Stefan Achatz,
Antonio Ospite, Alexey Dobriyan, Tejun Heo, Alan Stern,
Greg Kroah-Hartman, Marcel Holtmann, Stephane Chatty,
Michael Poole, David S. Miller, Bastien Nocera, Eric Dumazet,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, linux-bluetooth@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <AANLkTinJXYbZh_MvG81iJMu84LKBOKL3s-Gbfe77Vq7q@mail.gmail.com>
Dnia 2010-09-23, czw o godzinie 10:07 -0700, Ping Cheng pisze:
> On Thu, Sep 23, 2010 at 9:25 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > Hi Alan,
> >
> > On Mon, Aug 16, 2010 at 10:20:57PM +0200, ext Alan Ott wrote:
> >> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
> >
> > I gave a try to to this patch using your test tool [1] and very old BT
> > keyboard. I don't have anything else ATM to test with. Is there some BT hid
> > devices which support setting and getting features?
>
> As far as I know Wacom BT devices (Graphire and Intuos4) need to get
> and set features.
>
> Przemo,
>
> Do you have time to test the patchset with your Graphire BT and
> provide your result here?
Hi Ping,
Speed switching works as expected.
Tested on HP NC4200 with internal and external bluetooth modules:
Linux pldmachine 2.6.35-07788-g320b2b8-dirty #15 Thu Sep 23 19:55:03 IST
2010 i686 Intel(R)_Pentium(R)_M_processor_1.86GHz PLD Linux
ID 03f0:011d Hewlett-Packard Integrated Bluetooth Module
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
and Wacom Pen Tablet CTE-630BT
Tested-by: Przemo Firszt <przemo@firszt.eu>
--
Regards,
Przemo Firszt <przemo@firszt.eu>
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Alan Ott @ 2010-09-23 23:40 UTC (permalink / raw)
To: Ville Tervo
Cc: Jiri Kosina, Stefan Achatz, Antonio Ospite, Alexey Dobriyan,
Tejun Heo, Alan Stern, Greg Kroah-Hartman, Marcel Holtmann,
Stephane Chatty, Michael Poole, David S. Miller, Bastien Nocera,
Eric Dumazet, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <20100923162521.GA15641@null>
On 09/23/2010 12:25 PM, Ville Tervo wrote:
> Hi Alan,
>
> On Mon, Aug 16, 2010 at 10:20:57PM +0200, ext Alan Ott wrote:
>
>> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
>>
>
> I gave a try to to this patch using your test tool [1] and very old BT
> keyboard. I don't have anything else ATM to test with. Is there some BT hid
> devices which support setting and getting features?
>
A keyboard is the only BT device I've used which has feature reports.
> Shouldn't HIDIOCSFEATURE's bt version have similar wait as HIDIOCGFEATURE to
> get report status back from the device? or is there even any status coming back
> in successful case? Sorry I'm a newbie with HID and trying to understand how
> this should work.
>
> Now it just returns num of send bytes even if the remote device returned some
> error. Which one is the expected behavior?
>
I made it function the same as the existing hidp_output_raw_report().
Nothing in net/bluetooth/hidp/core.c is acked at all. I'm not sure of
the reasons.
Jiri, Marcel, any ideas?
> Other problem is that Get report is getting now handshake from set report.
>
>
>
Yeah, that makes sense. I hadn't considered the set_report failing. In
that case, I guess it means we _must_ wait for an ack for sent packets.
Anyone else agree or disagree?
Alan.
^ permalink raw reply
* Re: Bluez simple-agent vs agent
From: Viswanathan Sankararam @ 2010-09-24 1:25 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=9o+9KFNTGcYBZd0z+kYVwBj-Z1LxwdPsjTSfw@mail.gmail.com>
All, the following is the log I get on my target when I try to pair.
Any help with this is apprecaited. I see a message saying
HCIGETAUTHINFO failed. Can someone explain what this is and if it may
the reason for the issue? It seems to happen when the function
hcid_dbus_link_key_notify executes.
Thanks
Vishwa
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
adapter_get_device(00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
adapter_create_device(00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: Creating device
/org/bluez/1071/hci0/dev_00_1F_20_06_47_65
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
btd_device_ref(0x8052ae8): ref=1
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
/org/bluez/1071/hci0/dev_00_1F_20_06_47_65: requesting bonding
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: Temporary agent
registered for /org/bluez/1071/hci0/dev_00_1F_20_06_47_65 at
:1.4:/org/bluez/agent_1101
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
adapter_get_device(00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: link_key_request
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: kernel auth
requirements = 0x00
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: pin_code_request
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
adapter_get_device(00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
/org/bluez/1071/hci0/dev_00_1F_20_06_47_65: requesting agent
authentication
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: link_key_notify
(sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
adapter_get_device(00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: HCIGETAUTHINFO
failed: Invalid argument (22)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: local auth 0xff and
remote auth 0xff
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: storing link key of type 0x00
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
hcid_dbus_bonding_process_complete: status=00
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
adapter_get_device(00:1F:20:06:47:65)
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: Releasing agent
:1.4, /org/bluez/agent_1101
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: DiscoverServices
requestor exited
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: Removing temporary
device /org/bluez/1071/hci0/dev_00_1F_20_06_47_65
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: Removing device
/org/bluez/1071/hci0/dev_00_1F_20_06_47_65
I//system/bin/bluetoothd( 1070): bluetoothd[1071]:
btd_device_unref(0x8052ae8): ref=0
I//system/bin/bluetoothd( 1070): bluetoothd[1071]: device_free(0x8052ae8)
On Thu, Sep 23, 2010 at 11:50 AM, Viswanathan Sankararam
<developervishwa@gmail.com> wrote:
> Anyone, any ideas?
>
> On Thu, Sep 23, 2010 at 6:36 AM, Paul Matz <paul@osterhoutgroup.com> wrote:
>> This is a script that will allow us to generate the proper dbus
>> messages for the pin exchange. I'm not really sure how it works since
>> I haven't read much about the dbus IPC protocol. Interestingly
>> enough, it's checked into the linux kernel tree. Could this be the
>> source to the simple-agent binary in the bluez tar file?
>> http://git.kernel.org/?p=bluetooth/bluez.git;a=blob_plain;f=test/simple-agent;hb=HEAD
>>
>> This is the python library that is required by the simple-agent script.
>> http://dbus.freedesktop.org/releases/dbus-python/
>>
>> This works on a desktop, but we have an embedded system we are working
>> on that does not have the python stuff installed.
>> What I'm trying to figure out is how to create an agent that does what
>> the python script does.
>> One other problem I've got is that I can't get bluetoothd to generate
>> debug output. Starting it with -d, where does it write it's debug
>> output? /var/log/messages? Doesn't seem to.
>>
>> -PEM
>>
>> On Thu, Sep 23, 2010 at 12:46 AM, Viswanathan Sankararam
>> <developervishwa@gmail.com> wrote:
>>>
>>> All,
>>>
>>> I am new to bluetooth and bluez. I am having problems pairing my
>>> bluetooth keyboard to my target that does not have python and so in
>>> order to pair, I have compiled the agent application. My target has
>>> Bluez 4.47. But I have not been able to get it to pair. After running
>>>
>>> agent -a hci0 1234 00:1F:20:06:47:65
>>>
>>> I get asked to enter the pin on the bt keyboard and then it says Agent
>>> is released. When I list devices using
>>>
>>> dbus-send --system --dest=org.bluez --print-reply $BTADAPTER
>>> org.bluez.Adapter.ListDevices
>>>
>>> I see it in the list and when I repeat the command, it disappears.
>>>
>>> When I log on to my gentoo machine to pair the bt keyboard, I am able
>>> to pair with the simple-agent python script but not the agent
>>> application. The way the agent application behaves is the same as it
>>> behaves when I use it on the target.My gentoo system uses Bluez 4.69.
>>> Below is the log when I run bluetoothd with the -d option for the
>>> simple-agent case and the agent C program case. As you can see, in the
>>> simple-agent case, the device_probe_drivers gets called but in the
>>> agent.c case, discover_services_req_exit gets called. This is the
>>> place where they diverge. Also, I am not sure why the dbus system
>>> daemon is rejecting a message from agent to org.bluez. I am nto sure
>>> if its related. I am not able to proceed from here. Has any one faced
>>> this kind of issue? Please advice me on how to proceed. I would really
>>> appreciate it.
>>>
>>> Thanks
>>> Vishwa
>>>
>>> simple-agent:
>>>
>>> Sep 22 22:59:40 Zatoichi
>>> bluetoothd[7042]:src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
>>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>>> src/device.c:device_create() Creating device
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_ref() 0xb899f6b8: ref=1
>>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>>> src/device.c:bonding_request_new()
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
>>> Sep 22 22:59:40 Zatoichi bluetoothd[7042]:
>>> src/device.c:bonding_request_new() Temporary agent registered for
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at :1.29:/test/agent
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: Authentication requested
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: link_key_request
>>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>>> src/security.c:link_key_request() kernel auth requirements = 0x03
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]: pin_code_request
>>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 22 22:59:41 Zatoichi bluetoothd[7042]:
>>> src/device.c:device_request_authentication()
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
>>> authentication
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]: link_key_notify
>>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
>>> 0xff new key type 0x00
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
>>> auth 0xff
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
>>> 0x00
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_ref() 0xb899f6b8: ref=2
>>> Sep 22 22:59:47 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
>>> Releasing agent :1.29, /test/agent
>>> Sep 22 22:59:47 Zatoichi dbus-daemon: [system] Rejected send message,
>>> 1 matched rules; type="method_return", sender=":1.29" (uid=0 pid=7790
>>> comm="/usr/bin/python2.6) interface="(unset)" member="(unset)" error
>>> name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
>>> comm="/usr/sbin/bluetoothd))
>>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>>> src/device.c:device_probe_drivers() Probe drivers for
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>>> input/manager.c:hid_device_probe() path
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_ref() 0xb899f6b8: ref=3
>>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>>> input/device.c:input_device_new() Registered interface org.bluez.Input
>>> on path /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 22 22:59:48 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_unref() 0xb899f6b8: ref=2
>>>
>>> agent.c:
>>>
>>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_create_device() 00:1F:20:06:47:65
>>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>>> src/device.c:device_create() Creating device
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_ref() 0xb899f6b8: ref=1
>>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>>> src/device.c:bonding_request_new()
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting bonding
>>> Sep 23 00:14:34 Zatoichi bluetoothd[7042]:
>>> src/device.c:bonding_request_new() Temporary agent registered for
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65 at
>>> :1.35:/org/bluez/agent_8004
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: Authentication requested
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: link_key_request
>>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>>> src/security.c:link_key_request() kernel auth requirements = 0x03
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]: pin_code_request
>>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65)
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 23 00:14:35 Zatoichi bluetoothd[7042]:
>>> src/device.c:device_request_authentication()
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65: requesting agent
>>> authentication
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]: link_key_notify
>>> (sba=40:61:86:A5:0E:E1, dba=00:1F:20:06:47:65, type=0)
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_link_key_notify() key type 0x00 old key type
>>> 0xff new key type 0x00
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_link_key_notify() local auth 0x03 and remote
>>> auth 0xff
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_link_key_notify() storing link key of type
>>> 0x00
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/dbus-hci.c:hcid_dbus_bonding_process_complete() status=00
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_get_device() 00:1F:20:06:47:65
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_ref() 0xb899f6b8: ref=2
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]: src/agent.c:agent_release()
>>> Releasing agent :1.35, /org/bluez/agent_8004
>>> Sep 23 00:14:38 Zatoichi dbus-daemon: [system] Rejected send message,
>>> 1 matched rules; type="method_return", sender=":1.35" (uid=1000
>>> pid=8004 comm="./agent) interface="(unset)" member="(unset)" error
>>> name="(unset)" requested_reply=0 destination=":1.12" (uid=0 pid=7041
>>> comm="/usr/sbin/bluetoothd))
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/device.c:discover_services_req_exit() DiscoverServices requestor
>>> exited
>>> Sep 23 00:14:38 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_unref() 0xb899f6b8: ref=1
>>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
>>> src/adapter.c:adapter_remove_connection() Removing temporary device
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
>>> src/device.c:device_remove() Removing device
>>> /org/bluez/7041/hci0/dev_00_1F_20_06_47_65
>>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]:
>>> src/device.c:btd_device_unref() 0xb899f6b8: ref=0
>>> Sep 23 00:14:40 Zatoichi bluetoothd[7042]: src/device.c:device_free() 0xb899f6b8
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
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