* [PATCH 0/6] Support for ST-Ericsson CG2900 Connectivity Controller
From: Par-Gunnar Hjalmdahl @ 2010-09-24 13:44 UTC (permalink / raw)
To: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
This set of patches adds support for the ST-Ericsson CG2900 Connectivity Combo
Controller (GPS & Bluetooth & FM : GBF).
It contains a core framework where users can register for specific channels.
The core API also allows registration of handlers for specific chips as well as
the transports supported.
The channels are also exposed to User space through character devices.
There is a BlueZ driver module included which connects BlueZ to the CG2900
Bluetooth channels.
There is also an audio driver where audio stacks can set the CG2900 internal
audio paths, e.g. routing FM to I2S and Bluetooth to PCM.
There are already changes planned for this driver that we will submit when
ready:
Currently board specific functionality is directly included through a header
file and source file (cg2900_devices.c and .h). This will be changed by using
platform driver mechanism instead.
The CG2900 core framework still has chip specific dependencies. We have plans
to remove them in order to be able to connect any connectivity chip to
the framework.
Par-Gunnar Hjalmdahl (6):
This patch adds support for the ST-Ericsson CG2900 connectivity
controller. This patch contains the framework for registering
users, chip handlers, and transports as well as the needed files
towards the mach-ux500 board.
This patch adds support for the ST-Ericsson CG2900 connectivity
controller. This patch registers into the CG2900 framework. It
handles chip startup and shutdown together with firmware download.
It also handles Bluetooth and FM flow control due to special H4
channel management.
This patch adds support for the ST-Ericsson CG2690 connectivity
controller. This patch registers into the CG2900 framework. It
handles chip startup and shutdown together with firmware download.
This patch adds support for using UART as transport for the
ST-Ericsson CG2690 connectivity controller. This patch registers
into the CG2900 framework. It handles chip enable and disable as
well baud rate settings. It also assembles received packets into
full Bluetooth, GPS, and FM packets.
This patch adds support for controlling the audio paths within the
ST-Ericsson CG2900 connectivity controller. This patch registers as
a user into the CG2900 framework for the bt_audio and fm_audio
channels. It contains an API for controlling the audio paths that
can also be reached from User space using a char device.
This patch adds support for using the ST-Ericsson CG2900 connectivity
controller as a driver for the BlueZ Bluetooth stack. This patch
registers as a driver into the BlueZ framework and, when opened by
BlueZ, it registers as user for bt_cmd, bt_acl, and bt_evt
channels.
arch/arm/mach-ux500/Makefile | 5 +
arch/arm/mach-ux500/cg2900_devices.c | 353 +++
arch/arm/mach-ux500/include/mach/cg2900_devices.h | 120 +
drivers/bluetooth/Kconfig | 7 +
drivers/bluetooth/Makefile | 2 +
drivers/bluetooth/cg2900_hci.c | 896 ++++++++
drivers/mfd/Kconfig | 34 +
drivers/mfd/Makefile | 1 +
drivers/mfd/cg2900/Makefile | 14 +
drivers/mfd/cg2900/cg2900_audio.c | 2475 +++++++++++++++++++++
drivers/mfd/cg2900/cg2900_char_devices.c | 709 ++++++
drivers/mfd/cg2900/cg2900_char_devices.h | 36 +
drivers/mfd/cg2900/cg2900_chip.c | 2060 +++++++++++++++++
drivers/mfd/cg2900/cg2900_chip.h | 421 ++++
drivers/mfd/cg2900/cg2900_core.c | 2287 +++++++++++++++++++
drivers/mfd/cg2900/cg2900_core.h | 303 +++
drivers/mfd/cg2900/cg2900_debug.h | 77 +
drivers/mfd/cg2900/cg2900_uart.c | 1587 +++++++++++++
drivers/mfd/cg2900/hci_defines.h | 102 +
drivers/mfd/cg2900/stlc2690_chip.c | 1105 +++++++++
drivers/mfd/cg2900/stlc2690_chip.h | 37 +
include/linux/mfd/cg2900.h | 205 ++
include/linux/mfd/cg2900_audio.h | 583 +++++
23 files changed, 13419 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-ux500/cg2900_devices.c
create mode 100644 arch/arm/mach-ux500/include/mach/cg2900_devices.h
create mode 100644 drivers/bluetooth/cg2900_hci.c
create mode 100644 drivers/mfd/cg2900/Makefile
create mode 100644 drivers/mfd/cg2900/cg2900_audio.c
create mode 100644 drivers/mfd/cg2900/cg2900_char_devices.c
create mode 100644 drivers/mfd/cg2900/cg2900_char_devices.h
create mode 100644 drivers/mfd/cg2900/cg2900_chip.c
create mode 100644 drivers/mfd/cg2900/cg2900_chip.h
create mode 100644 drivers/mfd/cg2900/cg2900_core.c
create mode 100644 drivers/mfd/cg2900/cg2900_core.h
create mode 100644 drivers/mfd/cg2900/cg2900_debug.h
create mode 100644 drivers/mfd/cg2900/cg2900_uart.c
create mode 100644 drivers/mfd/cg2900/hci_defines.h
create mode 100644 drivers/mfd/cg2900/stlc2690_chip.c
create mode 100644 drivers/mfd/cg2900/stlc2690_chip.h
create mode 100644 include/linux/mfd/cg2900.h
create mode 100644 include/linux/mfd/cg2900_audio.h
^ permalink raw reply
* Re: Support for Device ID profile
From: Luiz Augusto von Dentz @ 2010-09-24 12:58 UTC (permalink / raw)
To: steven bluez; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinQOKoBCXgh1=wb9Z7w8A4w7vYFkSCoZvkspyYo@mail.gmail.com>
Hi Steven,
Yes, you can use DeviceID on main.conf to add that, but as you see it
is pretty limited so we are planning to have a better support for
this, perhaps extend adapter driver interface where you can write a
plugin to fill this information.
Regards,
On Fri, Sep 24, 2010 at 11:54 AM, steven bluez <steven.bluez@gmail.com> wrote:
> Hi all,
> Is there any support for Device ID Profile in Bluez 4.XX? versions ?\
>
> Regards,
> Steven
> --
> 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
>
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH v4 2/2] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Antonio Ospite @ 2010-09-24 10:47 UTC (permalink / raw)
To: Alan Ott
Cc: Ville Tervo, Jiri Kosina, Stefan Achatz, 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: <89BCFDE1-0D39-4248-84B2-E02C1480E067@signal11.us>
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
On Thu, 23 Sep 2010 10:16:43 -0400
Alan Ott <alan@signal11.us> wrote:
>
> 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?
>
I guess he's referring to the return paths (normal, err_restartsys,
err_eio) in hidp_get_raw_report(), they could be merged into a
generic "out:" path by parametrizing the return value.
I don't know if Alan prefers explicit error paths, for me it's OK either
way.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Support for Device ID profile
From: steven bluez @ 2010-09-24 8:54 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
Is there any support for Device ID Profile in Bluez 4.XX? versions ?\
Regards,
Steven
^ permalink raw reply
* Re: Bluez simple-agent vs agent
From: Ville Tervo @ 2010-09-24 8:16 UTC (permalink / raw)
To: ext Viswanathan Sankararam; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTikE91qpOgsio9WRaunaAyX3JDWXX0Oz4DvUvspU@mail.gmail.com>
Hi,
Are you using some really old kernel?
On Fri, Sep 24, 2010 at 03:25:12AM +0200, ext Viswanathan Sankararam wrote:
> 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
> >>
> >
> --
> 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: 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
* 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: [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: 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: 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: 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: [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: [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
* 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
* [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
* 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
* 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
* 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
* [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
* 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
* 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
* [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
* 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
* 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
* 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
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