* Re: [KERNEL PATCH] HID: Add support for Sony BD Remote
From: Luiz Augusto von Dentz @ 2012-09-14 10:42 UTC (permalink / raw)
To: David Dillow
Cc: linux-bluetooth, David Herrmann, Bastien Nocera, Antonio Ospite
In-Reply-To: <1347591892.6145.14.camel@obelisk.thedillows.org>
Hi David,
On Fri, Sep 14, 2012 at 6:04 AM, David Dillow <dave@thedillows.org> wrote:
> We also gain support for the Logitech Harmony Adapter for PS3.
>
> Signed-off-by: David Dillow <dave@thedillows.org>
> --
> drivers/hid/Kconfig | 7 +
> drivers/hid/Makefile | 1 +
> drivers/hid/hid-core.c | 2 +
> drivers/hid/hid-ps3remote.c | 325 +++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 335 insertions(+), 0 deletions(-)
>
> On Thu, 2012-09-13 at 00:36 +0200, Antonio Ospite wrote:
> On Wed, 12 Sep 2012 22:26:04 +0200 David Herrmann wrote:
>> > So if the devices only need some short setup-command during
>> > initialization and then they send HID reports whenever a button is
>> > pressed, then everything should be very easy to get working. Even
>> > auto-reconnect and 10min idle-disconnect are _very_ easy to get
>> > working in the kernel with the current HID infrastructure.
>>
>> I too will take a look during the week-end about writing a kernel
>> driver, if it's not that much of an effort I might take the project
>> (no promises yet). I have a PS3 BD remote Bastien donated.
>
> Here's a first pass at a kernel driver to support the BD remote and
> Harmony PS adapter. I've tested it on Fedora 16 with single keypresses
> only, as I cannot send multiple simultaneous keypresses with the
> Harmony. This patch is against kernel.org's bluetooth.git as of an hour
> ago, but should apply to other versions without much fuss.
Great that you are looking into it.
> Antonio, if you could test this with the real remote you have, I'd be
> very appreciative.
>
> David, could you point me at the controls for the 10min idle-disconnect?
I suppose we can just continue using input.conf:IdleTimeout (which
passed via ioctl in the struct hidp_connadd_req.idle_to) or do you
think this would be useful for other transports, at least for USB it
does not make much sense since the cable will stay connected.
> auto-connect and idle-disconnect seem to be working on my Fedora 16 box,
> though it looks like the Harmony adapter is initiating the disconnect --
> this is likely an area for improvement with the Sony remote.
Btw, it would probably be a good to add a proper defines for 0x0306
e.g. USB_DEVICE_ID_SONY_PS3_REMOTE and
USB_DEVICE_ID_LOGITECH_HARMONY_ADAPTER
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCHv4 16/17] Bluetooth: A2MP: Add fallback to normal l2cap init sequence
From: Andrei Emeltchenko @ 2012-09-14 10:29 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo
In-Reply-To: <alpine.DEB.2.02.1209130935110.19321@mathewm-linux>
Hi Mat,
On Thu, Sep 13, 2012 at 09:39:57AM -0700, Mat Martineau wrote:
> >From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> >When there is no remote AMP controller found fallback to normal
> >L2CAP sequence.
> >
> >Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >---
> >include/net/bluetooth/l2cap.h | 1 +
> >net/bluetooth/a2mp.c | 28 ++++++++++++++++++++++++++++
> >net/bluetooth/l2cap_core.c | 2 +-
> >3 files changed, 30 insertions(+), 1 deletion(-)
> >
> >diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> >index aba830f..0967f9e 100644
> >--- a/include/net/bluetooth/l2cap.h
> >+++ b/include/net/bluetooth/l2cap.h
> >@@ -769,5 +769,6 @@ int l2cap_ertm_init(struct l2cap_chan *chan);
> >void l2cap_chan_add(struct l2cap_conn *conn, struct l2cap_chan *chan);
> >void __l2cap_chan_add(struct l2cap_conn *conn, struct l2cap_chan *chan);
> >void l2cap_chan_del(struct l2cap_chan *chan, int err);
> >+void l2cap_send_conn_req(struct l2cap_chan *chan);
> >
> >#endif /* __L2CAP_H */
> >diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c
> >index 39e0f95..05522ea 100644
> >--- a/net/bluetooth/a2mp.c
> >+++ b/net/bluetooth/a2mp.c
> >@@ -181,6 +181,7 @@ static int a2mp_discover_rsp(struct amp_mgr *mgr, struct sk_buff *skb,
> > u16 len = le16_to_cpu(hdr->len);
> > struct a2mp_cl *cl;
> > u16 ext_feat;
> >+ bool found = false;
> >
> > if (len < sizeof(*rsp))
> > return -EINVAL;
> >@@ -211,6 +212,7 @@ static int a2mp_discover_rsp(struct amp_mgr *mgr, struct sk_buff *skb,
> > if (cl->id != HCI_BREDR_ID && cl->type == HCI_AMP) {
> > struct a2mp_info_req req;
> >
> >+ found = true;
> > req.id = cl->id;
> > a2mp_send(mgr, A2MP_GETINFO_REQ, __next_ident(mgr),
> > sizeof(req), &req);
> >@@ -220,6 +222,32 @@ static int a2mp_discover_rsp(struct amp_mgr *mgr, struct sk_buff *skb,
> > cl = (void *) skb_pull(skb, sizeof(*cl));
> > }
> >
> >+ /* Fall back to L2CAP init sequence */
> >+ if (!found) {
> >+ struct l2cap_conn *conn = mgr->l2cap_conn;
> >+ struct l2cap_chan *chan;
> >+
> >+ mutex_lock(&conn->chan_lock);
> >+
> >+ list_for_each_entry(chan, &conn->chan_l, list) {
> >+
> >+ BT_DBG("chan %p state %s", chan,
> >+ state_to_string(chan->state));
> >+
> >+ if (chan->chan_type == L2CAP_CHAN_CONN_FIX_A2MP)
> >+ continue;
> >+
> >+ l2cap_chan_lock(chan);
> >+
> >+ if (chan->state == BT_CONNECT)
> >+ l2cap_send_conn_req(chan);
> >+
> >+ l2cap_chan_unlock(chan);
> >+ }
> >+
> >+ mutex_unlock(&conn->chan_lock);
> >+ }
> >+
> > return 0;
> >}
> >
> >diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> >index cfe047f..d2ab82c 100644
> >--- a/net/bluetooth/l2cap_core.c
> >+++ b/net/bluetooth/l2cap_core.c
> >@@ -958,7 +958,7 @@ static bool __amp_capable(struct l2cap_chan *chan)
> > return false;
> >}
> >
> >-static void l2cap_send_conn_req(struct l2cap_chan *chan)
> >+void l2cap_send_conn_req(struct l2cap_chan *chan)
> >{
> > struct l2cap_conn *conn = chan->conn;
> > struct l2cap_conn_req req;
> >--
> >1.7.9.5
> >
> >
>
> Here's another place where we have duplicated functionality. This
> patch has BR/EDR fallback too:
>
> [RFCv1 13/20] Bluetooth: Handle physical link completion
>
> You can call l2cap_physical_cfm() with a failure result instead of
> calling l2cap_send_conn_req() directly.
I suppose there is no such function yet, otherwise this can be done.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCH] Bluetooth: Free the l2cap channel list only when refcount is zero
From: Maxim Levitsky @ 2012-09-14 10:26 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Jaganath, linux-bluetooth, s.syam
In-Reply-To: <20120914094458.GD7483@aemeltch-MOBL1>
On Fri, 2012-09-14 at 12:45 +0300, Andrei Emeltchenko wrote:
> Hi Maxim,
>
> On Fri, Sep 14, 2012 at 02:56:21AM +0300, Maxim Levitsky wrote:
> > On Fri, 2012-07-13 at 16:56 +0530, Jaganath wrote:
> > > Hi Andrei,
> > >
> > > --------------------------------------------------
> > > From: "Andrei Emeltchenko" <andrei.emeltchenko.news@gmail.com>
> > > Sent: Friday, July 13, 2012 2:19 PM
> > > To: "Jaganath Kanakkassery" <jaganath.k@samsung.com>
> > > Cc: <linux-bluetooth@vger.kernel.org>; <s.syam@samsung.com>
> > > Subject: Re: [PATCH] Bluetooth: Free the l2cap channel list only when
> > > refcount is zero
> > >
> > > > Hi Jaganath,
> > > >
> > > > On Fri, Jul 13, 2012 at 01:22:03PM +0530, Jaganath Kanakkassery wrote:
> > > >> Move the l2cap channel list chan->global_l under the refcnt
> > > >> protection and free it based on the refcnt.
> > > >
> > > > The idea is good.
> > > >
> > Note that in 3.6-rc5 which soon to be released, it trivial to trigger a
> > crash by suspending the system with a2dp headphones connected.
> > I also have seem (and I strongly suspect the same) crash in 3.5
> > This patch seems to fix this so far.
> > Could you sent it to Linus, to fix this kernel panic?
>
> AFAIK the updated patch has been applied. Concerning your crash you can
> also check my patch in the mail archive "Bluetooth: Add refcnt to l2cap_conn"
>
> Best regards
> Andrei Emeltchenko
I'll will.
Even if it is applied, its not yet in Linus's tree of today.
Thanks for your patch!
Best regards,
Maxim Levitsky
>
> >
> > Best regards,
> > Maxim Levitsky
> >
> > PS:
> > The backtrace:
> >
> >
> > fg80211: Calling CRDA to update world regulatory domain
> > cfg80211: World regulatory domain updated:
> > cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> > max_eirp)
> > cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000
> > mBm)2
> > cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> > cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000
> > mBm)T:
> > cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> > cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> > 8
> > cfg80211: World regulatory domain updated:
> > cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> > max_eirp)
> > cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000
> > mBm)<
> > cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000
> > mBm)P@
> > cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> > cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> > cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> > general protection fault: 0000 [#1] PREEMPT SMP
> > Modules linked in: hidp af_packet bnep rfcomm iwl3945
> > snd_hda_codec_realtek iwlegacy mac80211 snd_hda_intel nfsd btusb
> > snd_hda_codec uvcvideo snd_hwdep videobuf2_core snd_pcm bluetooth
> > videobuf2_vmalloc videobuf2_memops nfs_acl auth_rpcgss r592 cfg80211
> > microcode nfs psmouse memstick serio_raw snd_page_alloc ene_ir battery
> > ac lockd sunrpc rc_lirc ir_lirc_codec lirc_dev ir_rc6_decoder
> > firewire_net iTCO_wdt firewire_sbp2 nouveau ttm drm_kms_helper mxm_wmi
> > usb_storage video wmi uhci_hcd sdhci_pci firewire_ohci firewire_core
> > sdhci mmc_core atkbd ehci_hcd thermal [last unloaded: tg3]
> > CPU 0
> > Pid: 3512, comm: bluetoothd Not tainted 3.6.0-rc5+ #34 Acer Aspire
> > 5720 /Nettiling?b
> > RIP: 0010:[<ffffffffa03a1d56>] [<ffffffffa03a1d56>] l2cap_chan_destroy
> > +0x46/0xb0 [bluetooth]
> > RSP: 0018:ffff8800619dbca8 EFLAGS: 00010296
> > RAX: dead000000200200 RBX: ffff88007d3f1000 RCX: dead000000100100
> > RDX: dead000000100100 RSI: dead000000200200 RDI: ffffffffa03b7cc0
> > RBP: ffff8800619dbcb8 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0001cc0f349b43de R11: ffffffffa03a1d2d R12: ffff88007d3f1000
> > R13: ffff88007d3f1014 R14: ffff88005f922570 R15: ffff88005f9229e0
> > FS: 00007f8aa4634740(0000) GS:ffff88007fa00000(0000)
> > knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f8aa46b7d90 CR3: 000000005f945000 CR4: 00000000000007f0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > Process bluetoothd (pid: 3512, threadinfo ffff8800619da000, task
> > ffff88005ec4bde0)
> > Stack:
> > ffff8800619dbcd8 ffff880079945800 ffff8800619dbcd8 ffffffffa03a7b3c
> > ffff88007d3f1000 ffff88005f922800 ffff8800619dbce8 ffffffffa03a7b85
> > ffff8800619dbd48 ffffffffa03a231e ffff88007d3f14a0 ffff88005f9229f0
> > Call Trace:
> > [<ffffffffa03a7b3c>] l2cap_sock_kill+0x7c/0xb0 [bluetooth]
> > [<ffffffffa03a7b85>] l2cap_sock_close_cb+0x15/0x20 [bluetooth]
> > [<ffffffffa03a231e>] l2cap_conn_del+0x11e/0x1f0 [bluetooth]
> > [<ffffffffa038301a>] ? hci_dev_do_close+0x18a/0x370 [bluetooth]
> > [<ffffffffa03a6db3>] l2cap_disconn_cfm+0x53/0x60 [bluetooth]
> > [<ffffffffa0388c55>] hci_conn_hash_flush+0x95/0x100 [bluetooth]
> > [<ffffffffa038302a>] hci_dev_do_close+0x19a/0x370 [bluetooth]
> > [<ffffffffa0384af0>] hci_dev_close+0x50/0x80 [bluetooth]
> > [<ffffffffa039af3a>] hci_sock_ioctl+0x15a/0x420 [bluetooth]
> > [<ffffffff8144c6e0>] sock_do_ioctl+0x30/0x60
> > [<ffffffff8105f3e0>] ? task_work_run+0x30/0xa0
> > [<ffffffff8144d570>] sock_ioctl+0x290/0x2b0
> > [<ffffffff81147f20>] do_vfs_ioctl+0x580/0x5e0
> > [<ffffffff8151630b>] ? _raw_spin_unlock_irq+0x3b/0x60
> > [<ffffffff81147fcf>] sys_ioctl+0x4f/0x80
> > [<ffffffff81517016>] system_call_fastpath+0x1a/0x1f
> > Code: 17 e1 48 8b 93 80 04 00 00 48 b9 00 01 10 00 00 00 ad de 48 8b 83
> > 88 04 00 00 48 c7 c7 c0 7c 3b a0 48 be 00 02 20 00 00 00 ad de <48> 89
> > 42 08 48 89 10 48 89 8b 80 04 00 00 48 89 b3 88 04 00 00
> > "RIP [<ffffffffa03a1d56>] l2cap_chan_destroy+0x46/0xb0 [bluetooth]
> > RSP <ffff8800619dbca8>
> > ---[ end trace 6e537072816e99b2 ]---+qZ
> > Kernel panic - not syncing: Fatal exception
> > fpanic occurred, switching back to text console
> > Rebooting in 10 seconds..
> > ACPI MEMORY or I/O RESET_REG.
> >
--
Best regards,
Maxim Levitsky
Visit my blog: http://maximlevitsky.wordpress.com
Warning: Above blog contains rants.
^ permalink raw reply
* Re: [PATCH obexd v1 2/3] MAP: Add set read status function
From: Luiz Augusto von Dentz @ 2012-09-14 10:25 UTC (permalink / raw)
To: Sunil Kumar Behera; +Cc: linux-bluetooth
In-Reply-To: <1347543808-1220-1-git-send-email-sunil.behera@samsung.com>
Hi Sunil,
On Thu, Sep 13, 2012 at 4:43 PM, Sunil Kumar Behera
<sunil.behera@samsung.com> wrote:
> This function will inform MAP server to modify the
> read status of a given message.
> ---
> plugins/mas.c | 25 +++++++++++++++++++++++++
> plugins/messages-dummy.c | 6 ++++++
> plugins/messages-tracker.c | 6 ++++++
> plugins/messages.h | 13 +++++++++++++
> 4 files changed, 50 insertions(+)
>
> diff --git a/plugins/mas.c b/plugins/mas.c
> index f2ff9e6..14e7478 100644
> --- a/plugins/mas.c
> +++ b/plugins/mas.c
> @@ -46,6 +46,8 @@
>
> #include "messages.h"
>
> +#define READ_STATUS_REQ 0
> +
> /* Channel number according to bluez doc/assigned-numbers.txt */
> #define MAS_CHANNEL 16
>
> @@ -499,6 +501,20 @@ static void update_inbox_cb(void *session, int err, void *user_data)
> obex_object_set_io_flags(mas, G_IO_OUT, 0);
> }
>
> +static void set_read_status_cb(void *session, int err, void *user_data)
> +{
> + struct mas_session *mas = user_data;
> +
> + DBG("");
> +
> + mas->finished = TRUE;
> +
> + if (err < 0)
> + obex_object_set_io_flags(mas, G_IO_ERR, err);
> + else
> + obex_object_set_io_flags(mas, G_IO_OUT, 0);
> +}
> +
> static int mas_setpath(struct obex_session *os, void *user_data)
> {
> const char *name;
> @@ -677,6 +693,15 @@ static void *message_set_status_open(const char *name, int oflag, mode_t mode,
> return NULL;
> }
>
> + if (indicator == READ_STATUS_REQ)
> + *err = messages_set_read(mas->backend_data, name, value,
> + set_read_status_cb, mas);
> + else
> + *err = -EBADR;
> +
> + if (*err < 0)
> + return NULL;
> +
> return mas;
> }
>
> diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
> index a47f143..78e20ae 100644
> --- a/plugins/messages-dummy.c
> +++ b/plugins/messages-dummy.c
> @@ -353,6 +353,12 @@ int messages_update_inbox(void *session, messages_update_inbox_cb callback,
> return -ENOSYS;
> }
>
> +int messages_set_read(void *session, const char *handle, uint8_t value,
> + messages_set_read_cb callback, void *user_data)
> +{
> + return -ENOSYS;
> +}
> +
> void messages_abort(void *s)
> {
> struct session *session = s;
> diff --git a/plugins/messages-tracker.c b/plugins/messages-tracker.c
> index 92c1767..1516dc7 100644
> --- a/plugins/messages-tracker.c
> +++ b/plugins/messages-tracker.c
> @@ -327,6 +327,12 @@ int messages_update_inbox(void *session, messages_update_inbox_cb callback,
> return -ENOSYS;
> }
>
> +int messages_set_read(void *session, const char *handle, uint8_t value,
> + messages_set_read_cb callback, void *user_data)
> +{
> + return -ENOSYS;
> +}
> +
> void messages_abort(void *session)
> {
> }
> diff --git a/plugins/messages.h b/plugins/messages.h
> index 669f7c2..45579d3 100644
> --- a/plugins/messages.h
> +++ b/plugins/messages.h
> @@ -279,6 +279,19 @@ typedef void (*messages_update_inbox_cb)(void *session, int err,
>
> int messages_update_inbox(void *session, messages_update_inbox_cb callback,
> void *user_data);
> +/* Informs Message Server to modify read status of a given message.
> + *
> + * session: Backend session.
> + * handle: Unique identifier to the message.
> + * value: Indicates the new value of the read status for a given message.
> + * Callback shall be called for every read status update request
> + * recieved from MCE.
> + * user_data: User data if any to be sent.
> + */
> +typedef void (*messages_set_read_cb)(void *session, int err, void *user_data);
> +
> +int messages_set_read(void *session, const char *handle, uint8_t value,
> + messages_set_read_cb callback, void *user_data);
>
> /* Aborts currently pending request.
> *
> --
> 1.7.9.5
These 3 patches are now upstream, note that I did some changes and
added another patch on top of them to unify the callback as the
callbacks were doing exactly the same including update.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCHv4 11/17] Bluetooth: Choose connection based on capabilities
From: Andrei Emeltchenko @ 2012-09-14 9:57 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo
In-Reply-To: <alpine.DEB.2.02.1209130916550.19321@mathewm-linux>
Hi Mat,
On Thu, Sep 13, 2012 at 09:26:27AM -0700, Mat Martineau wrote:
...
> >+static void l2cap_choose_conn(struct l2cap_chan *chan)
>
> I find this function name a little confusing - "choose" sounds like
> it is just making a decision. This function also takes the action
> of starting physical link setup or sending a connection request,
> which is more than just "choosing".
>
> l2cap_start_connection, maybe?
Sounds good to me. Will change.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCHv4 07/17] Bluetooth: AMP: Remote AMP ctrl definitions
From: Andrei Emeltchenko @ 2012-09-14 9:56 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo
In-Reply-To: <alpine.DEB.2.02.1209130846560.19321@mathewm-linux>
Hi Mat,
On Thu, Sep 13, 2012 at 08:50:24AM -0700, Mat Martineau wrote:
...
> >+struct amp_ctrl {
> >+ struct list_head list;
> >+ struct kref kref;
> >+ __u8 id;
> >+ __u16 assoc_len_so_far;
> >+ __u16 assoc_rem_len;
> >+ __u16 assoc_len;
> >+ __u8 *assoc;
> >+};
>
> I think you have the necessary information here. There should be no
> need to also track the remote device in the amp_ctrl struct because
> the amp_mgr that owns the list of controllers is only referring to
> one remote device, right?
amp_mgr tracks the list of remote AMP controllers found in the A2MP
Discover Response. It is not limited to one remote controller.
Though it is usually only one AMP controller but Spec says that:
<------8<-------------------------------------------------------------------------
| Controller List (3 or more octets)
| Controller List is variable in length. It consists of 1 or more entry.
| Each entry is comprised of a Controller ID, a Controller Type and a Controller
| status.
<------8<-------------------------------------------------------------------------
Then for each controller we send A2MP Getinfo Request.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCH] Bluetooth: Free the l2cap channel list only when refcount is zero
From: Andrei Emeltchenko @ 2012-09-14 9:45 UTC (permalink / raw)
To: Maxim Levitsky; +Cc: Jaganath, linux-bluetooth, s.syam
In-Reply-To: <1347580581.5975.4.camel@maxim-laptop>
Hi Maxim,
On Fri, Sep 14, 2012 at 02:56:21AM +0300, Maxim Levitsky wrote:
> On Fri, 2012-07-13 at 16:56 +0530, Jaganath wrote:
> > Hi Andrei,
> >
> > --------------------------------------------------
> > From: "Andrei Emeltchenko" <andrei.emeltchenko.news@gmail.com>
> > Sent: Friday, July 13, 2012 2:19 PM
> > To: "Jaganath Kanakkassery" <jaganath.k@samsung.com>
> > Cc: <linux-bluetooth@vger.kernel.org>; <s.syam@samsung.com>
> > Subject: Re: [PATCH] Bluetooth: Free the l2cap channel list only when
> > refcount is zero
> >
> > > Hi Jaganath,
> > >
> > > On Fri, Jul 13, 2012 at 01:22:03PM +0530, Jaganath Kanakkassery wrote:
> > >> Move the l2cap channel list chan->global_l under the refcnt
> > >> protection and free it based on the refcnt.
> > >
> > > The idea is good.
> > >
> Note that in 3.6-rc5 which soon to be released, it trivial to trigger a
> crash by suspending the system with a2dp headphones connected.
> I also have seem (and I strongly suspect the same) crash in 3.5
> This patch seems to fix this so far.
> Could you sent it to Linus, to fix this kernel panic?
AFAIK the updated patch has been applied. Concerning your crash you can
also check my patch in the mail archive "Bluetooth: Add refcnt to l2cap_conn"
Best regards
Andrei Emeltchenko
>
> Best regards,
> Maxim Levitsky
>
> PS:
> The backtrace:
>
>
> fg80211: Calling CRDA to update world regulatory domain
> cfg80211: World regulatory domain updated:
> cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000
> mBm)2
> cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000
> mBm)T:
> cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> 8
> cfg80211: World regulatory domain updated:
> cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
> max_eirp)
> cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000
> mBm)<
> cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000
> mBm)P@
> cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> general protection fault: 0000 [#1] PREEMPT SMP
> Modules linked in: hidp af_packet bnep rfcomm iwl3945
> snd_hda_codec_realtek iwlegacy mac80211 snd_hda_intel nfsd btusb
> snd_hda_codec uvcvideo snd_hwdep videobuf2_core snd_pcm bluetooth
> videobuf2_vmalloc videobuf2_memops nfs_acl auth_rpcgss r592 cfg80211
> microcode nfs psmouse memstick serio_raw snd_page_alloc ene_ir battery
> ac lockd sunrpc rc_lirc ir_lirc_codec lirc_dev ir_rc6_decoder
> firewire_net iTCO_wdt firewire_sbp2 nouveau ttm drm_kms_helper mxm_wmi
> usb_storage video wmi uhci_hcd sdhci_pci firewire_ohci firewire_core
> sdhci mmc_core atkbd ehci_hcd thermal [last unloaded: tg3]
> CPU 0
> Pid: 3512, comm: bluetoothd Not tainted 3.6.0-rc5+ #34 Acer Aspire
> 5720 /Nettiling?b
> RIP: 0010:[<ffffffffa03a1d56>] [<ffffffffa03a1d56>] l2cap_chan_destroy
> +0x46/0xb0 [bluetooth]
> RSP: 0018:ffff8800619dbca8 EFLAGS: 00010296
> RAX: dead000000200200 RBX: ffff88007d3f1000 RCX: dead000000100100
> RDX: dead000000100100 RSI: dead000000200200 RDI: ffffffffa03b7cc0
> RBP: ffff8800619dbcb8 R08: 0000000000000000 R09: 0000000000000000
> R10: 0001cc0f349b43de R11: ffffffffa03a1d2d R12: ffff88007d3f1000
> R13: ffff88007d3f1014 R14: ffff88005f922570 R15: ffff88005f9229e0
> FS: 00007f8aa4634740(0000) GS:ffff88007fa00000(0000)
> knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f8aa46b7d90 CR3: 000000005f945000 CR4: 00000000000007f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process bluetoothd (pid: 3512, threadinfo ffff8800619da000, task
> ffff88005ec4bde0)
> Stack:
> ffff8800619dbcd8 ffff880079945800 ffff8800619dbcd8 ffffffffa03a7b3c
> ffff88007d3f1000 ffff88005f922800 ffff8800619dbce8 ffffffffa03a7b85
> ffff8800619dbd48 ffffffffa03a231e ffff88007d3f14a0 ffff88005f9229f0
> Call Trace:
> [<ffffffffa03a7b3c>] l2cap_sock_kill+0x7c/0xb0 [bluetooth]
> [<ffffffffa03a7b85>] l2cap_sock_close_cb+0x15/0x20 [bluetooth]
> [<ffffffffa03a231e>] l2cap_conn_del+0x11e/0x1f0 [bluetooth]
> [<ffffffffa038301a>] ? hci_dev_do_close+0x18a/0x370 [bluetooth]
> [<ffffffffa03a6db3>] l2cap_disconn_cfm+0x53/0x60 [bluetooth]
> [<ffffffffa0388c55>] hci_conn_hash_flush+0x95/0x100 [bluetooth]
> [<ffffffffa038302a>] hci_dev_do_close+0x19a/0x370 [bluetooth]
> [<ffffffffa0384af0>] hci_dev_close+0x50/0x80 [bluetooth]
> [<ffffffffa039af3a>] hci_sock_ioctl+0x15a/0x420 [bluetooth]
> [<ffffffff8144c6e0>] sock_do_ioctl+0x30/0x60
> [<ffffffff8105f3e0>] ? task_work_run+0x30/0xa0
> [<ffffffff8144d570>] sock_ioctl+0x290/0x2b0
> [<ffffffff81147f20>] do_vfs_ioctl+0x580/0x5e0
> [<ffffffff8151630b>] ? _raw_spin_unlock_irq+0x3b/0x60
> [<ffffffff81147fcf>] sys_ioctl+0x4f/0x80
> [<ffffffff81517016>] system_call_fastpath+0x1a/0x1f
> Code: 17 e1 48 8b 93 80 04 00 00 48 b9 00 01 10 00 00 00 ad de 48 8b 83
> 88 04 00 00 48 c7 c7 c0 7c 3b a0 48 be 00 02 20 00 00 00 ad de <48> 89
> 42 08 48 89 10 48 89 8b 80 04 00 00 48 89 b3 88 04 00 00
> "RIP [<ffffffffa03a1d56>] l2cap_chan_destroy+0x46/0xb0 [bluetooth]
> RSP <ffff8800619dbca8>
> ---[ end trace 6e537072816e99b2 ]---+qZ
> Kernel panic - not syncing: Fatal exception
> fpanic occurred, switching back to text console
> Rebooting in 10 seconds..
> ACPI MEMORY or I/O RESET_REG.
>
^ permalink raw reply
* Re: Wii Balance Board vs. bluez
From: David Herrmann @ 2012-09-14 9:02 UTC (permalink / raw)
To: Florian Echtler; +Cc: linux-bluetooth
In-Reply-To: <5052519F.30803@butterbrot.org>
Hi Florian
On Thu, Sep 13, 2012 at 2:35 PM, Florian Echtler <floe@butterbrot.org> wrote:
> On 13.09.2012 16:39, David Herrmann wrote:
>>>
>>> Please see the appended patch. You have to apply it to your kernel
>>> tree and recompile the hid-wiimote driver. No other sources are
>>> changed so you don't need to reboot or install the new kernel. Just
>>> install the new hid-wiimote.ko module.
>>>
>>> One of the 5 input devices should then report the wiimote weight
>>> sensor data. (the input device with name "Wii Remote Balance Board").
>>
>> Forgot to attach the patch... Here it is.
>
> Awesome - works as expected, weight sensor data can be read from one of the
> event devices.
Good to hear. I hate writing drivers for devices I don't have...
Thanks for testing!
> I've attached an additional patch on top of yours to also read the
> calibration data (24 bytes at address 0xa40024). Calibration data is applied
> in handler_balance_board, resulting values are in units of 10 grams.
> Although this looks correct to me, I'm not getting any events with my patch
> applied - I suspect some connection to the min/max input values. Do you have
> any ideas what's wrong?
Ah, yeah I forgot to change the min/max values of ABS_HAT**. I will
fix that. The calibration data looks also nice. I have no idea what
went wrong, but you should definitely initialize it to some sane value
and fallback to this if you cannot read the data from the device. I
would also like to split this into two patches. The first one without
calibration and the second one applies the calibration data.
I will try to resend these this afternoon, otherwise, I will not have
time until Sunday afternoon. Sorry.
Thanks for the efforts!
David
^ permalink raw reply
* Re: Connecting to Bluetooth Low Energy devices
From: Philipp Claves @ 2012-09-14 8:55 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <CAJdJm_MY_TZqay8L0=qOXy3kFkM4RMsXgRKKh1nK7ukokB7WqA@mail.gmail.com>
Hi Anderson
On Thu, Sep 13, 2012 at 12:54:26, Anderson Lizardo wrote:
> Hi Philipp,
>
> On Thu, Sep 13, 2012 at 11:34 AM, Philipp Claves
>
> <claves@budelmann-elektronik.com> wrote:
> > Hello
> >
> > Trying to get started with Bluetooth Low Energy devices, i used hcitool
> > and gatttool to enumerate device attributes, but did not get far:
> >
> > # hcitool lescan
> > LE Scan ...
> > <MAC-Device1> Battery V1.0
> > <MAC-Device1> (unknown)
> > <MAC-Device2> Battery V1.0
> > <MAC-Device2> (unknown)
> > ^C
> >
> > # gatttool -b <MAC-Device1> -I
> > [ ][<MAC-Device1>][LE]> connect
> > Connecting... connect error: connect error: Connection refused (111)
> > [ ][<MAC-Device1>][LE]>
> >
> > This is all i get.
>
> Which kernel version are you running?
Linux 3.5.3
Which is the minimum version required?
>
> > Am i doing something obviously wrong?
> > Any tips where to get more information about the error (dmesg shows
> > nothing)?
> run "hcidump -X" and check the logs while you run "hcitool lescan".
> Then check the type of advertising those devices are sending. They
> should be connectable advertisings to be able to connect to them. Also
> check the address type, if it is "Random" you need to pass "-t random"
> to gatttool.
Thanks, -t random did the trick.
But it's still strange, the device addresses never changed even once while
working with them. The bluetooth SIG talk about LE adresses mentioned random
adresses to change every 15 minutes or so....
I need to investigate this more.
Thanks for your help!
Philipp Claves
--
Budelmann Elektronik GmbH
Von-Renesse-Weg 60
48163 Münster
Germany
Tel. +49 (0)2501 9208440
Fax +49 (0)2501 5887024
claves@budelmann-elektronik.com
www.budelmann-elektronik.com
^ permalink raw reply
* Re: [PATCHv4 06/17] Bluetooth: AMP: Physical link struct and heplers
From: Andrei Emeltchenko @ 2012-09-14 7:50 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo
In-Reply-To: <alpine.DEB.2.02.1209130835240.19321@mathewm-linux>
Hi Mat,
On Thu, Sep 13, 2012 at 08:40:59AM -0700, Mat Martineau wrote:
> >From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> >Define physical link structures. Physical links are represented by
> >hci_conn structure. For BR/EDR we use type ACL_LINK and for AMP
> >we use AMP_LINK.
> >
> >Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >---
> >include/net/bluetooth/hci.h | 1 +
> >include/net/bluetooth/hci_core.h | 20 ++++++++++++++++++
> >include/net/bluetooth/pal.h | 26 +++++++++++++++++++++++
> >net/bluetooth/Makefile | 2 +-
> >net/bluetooth/a2mp.c | 1 +
> >net/bluetooth/pal.c | 42 ++++++++++++++++++++++++++++++++++++++
> >6 files changed, 91 insertions(+), 1 deletion(-)
> >create mode 100644 include/net/bluetooth/pal.h
> >create mode 100644 net/bluetooth/pal.c
> >
> >diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
> >index 1cb8b55..4c41b8c 100644
> >--- a/include/net/bluetooth/hci.h
> >+++ b/include/net/bluetooth/hci.h
> >@@ -207,6 +207,7 @@ enum {
> >#define ESCO_LINK 0x02
> >/* Low Energy links do not have defined link type. Use invented one */
> >#define LE_LINK 0x80
> >+#define AMP_LINK 0x81
> >
> >/* LMP features */
> >#define LMP_3SLOT 0x01
> >diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> >index 1174218..4ae5293 100644
> >--- a/include/net/bluetooth/hci_core.h
> >+++ b/include/net/bluetooth/hci_core.h
> >@@ -316,6 +316,7 @@ struct hci_conn {
> >
> > __u8 remote_cap;
> > __u8 remote_auth;
> >+ __u8 remote_id;
> > bool flush_key;
> >
> > unsigned int sent;
> >@@ -510,6 +511,25 @@ static inline struct hci_conn *hci_conn_hash_lookup_handle(struct hci_dev *hdev,
> > return NULL;
> >}
> >
> >+static inline struct hci_conn *hci_conn_hash_lookup_id(struct hci_dev *hdev,
> >+ __u8 remote_id)
> >+{
> >+ struct hci_conn_hash *h = &hdev->conn_hash;
> >+ struct hci_conn *c;
> >+
> >+ rcu_read_lock();
> >+
> >+ list_for_each_entry_rcu(c, &h->list, list) {
> >+ if (c->remote_id == remote_id) {
> >+ rcu_read_unlock();
> >+ return c;
> >+ }
> >+ }
> >+ rcu_read_unlock();
> >+
> >+ return NULL;
> >+}
> >+
>
> If there are multiple AMP physical links to different devices, the
> remote_id probably isn't enough information to look up a physical
> link. Most of the time the remote_id will be "1", so there will
> probably be multiple hci_conns with the same remote_id.
I am thinking then we might use dst address and use function below.
>
> l2cap_conn + remote_id should be unique, though.
>
> >static inline struct hci_conn *hci_conn_hash_lookup_ba(struct hci_dev *hdev,
> > __u8 type, bdaddr_t *ba)
> >{
like
hci_conn_hash_lookup_ba(hdev, AMP_LINK, dst)
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCHv4 04/17] Bluetooth: AMP: Use HCI cmd to Read Loc AMP Assoc
From: Andrei Emeltchenko @ 2012-09-14 6:58 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo
In-Reply-To: <alpine.DEB.2.02.1209130814370.19321@mathewm-linux>
Hi Mat,
On Thu, Sep 13, 2012 at 08:28:06AM -0700, Mat Martineau wrote:
> >When receiving A2MP Get AMP Assoc Request execute Read Local AMP Assoc
> >HCI command to AMP controller. If the AMP Assoc data is larger then it
> >can fit to HCI event only fragment is read. When all fragments are read
> >send A2MP Get AMP Assoc Response.
> >
> >Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
...
> >+void a2mp_send_getampassoc_rsp(struct hci_dev *hdev, u8 status)
> >+{
> >+ struct amp_mgr *mgr;
> >+ struct amp_assoc *loc_assoc = &hdev->loc_assoc;
> >+ struct a2mp_amp_assoc_rsp *rsp;
> >+ size_t len;
> >+
> >+ mgr = amp_mgr_lookup_by_state(READ_LOC_AMP_ASSOC);
>
> What if multiple amp managers are in the READ_LOC_AMP_ASSOC state?
> Is that possible if multiple remote devices send GETAMPASSOC at the
> same time?
In this very unrealistic case I still do not see a problem. All those HCI
requests would be serialized and response would be sent for all AMP
managers.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCHv4 02/17] Bluetooth: A2MP: Create amp_mgr global list
From: Andrei Emeltchenko @ 2012-09-14 6:40 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, gustavo
In-Reply-To: <alpine.DEB.2.02.1209130802210.19321@mathewm-linux>
Hi Mat,
On Thu, Sep 13, 2012 at 08:02:58AM -0700, Mat Martineau wrote:
...
> >@@ -550,6 +558,10 @@ static struct amp_mgr *amp_mgr_create(struct l2cap_conn *conn)
> >
> > conn->hcon->amp_mgr = mgr;
> >
> >+ mutex_lock(&_mgr_list_lock);
> >+ list_add(&mgr->list, &_mgr_list);
> >+ mutex_unlock(&_mgr_list_lock);
> >+
> > kref_init(&mgr->kref);
>
> Should the reference count be initialized before adding to the list?
will change this.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* [KERNEL PATCH] HID: Add support for Sony BD Remote
From: David Dillow @ 2012-09-14 3:04 UTC (permalink / raw)
To: linux-bluetooth
Cc: David Herrmann, Luiz Augusto von Dentz, Bastien Nocera,
Antonio Ospite
In-Reply-To: <20120913003628.ce5babb2a66d09fe17fa15de@studenti.unina.it>
We also gain support for the Logitech Harmony Adapter for PS3.
Signed-off-by: David Dillow <dave@thedillows.org>
--
drivers/hid/Kconfig | 7 +
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c | 2 +
drivers/hid/hid-ps3remote.c | 325 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 335 insertions(+), 0 deletions(-)
On Thu, 2012-09-13 at 00:36 +0200, Antonio Ospite wrote:
On Wed, 12 Sep 2012 22:26:04 +0200 David Herrmann wrote:
> > So if the devices only need some short setup-command during
> > initialization and then they send HID reports whenever a button is
> > pressed, then everything should be very easy to get working. Even
> > auto-reconnect and 10min idle-disconnect are _very_ easy to get
> > working in the kernel with the current HID infrastructure.
>
> I too will take a look during the week-end about writing a kernel
> driver, if it's not that much of an effort I might take the project
> (no promises yet). I have a PS3 BD remote Bastien donated.
Here's a first pass at a kernel driver to support the BD remote and
Harmony PS adapter. I've tested it on Fedora 16 with single keypresses
only, as I cannot send multiple simultaneous keypresses with the
Harmony. This patch is against kernel.org's bluetooth.git as of an hour
ago, but should apply to other versions without much fuss.
Antonio, if you could test this with the real remote you have, I'd be
very appreciative.
David, could you point me at the controls for the 10min idle-disconnect?
auto-connect and idle-disconnect seem to be working on my Fedora 16 box,
though it looks like the Harmony adapter is initiating the disconnect --
this is likely an area for improvement with the Sony remote.
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index fbf4950..7e6ab25 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -534,6 +534,13 @@ config HID_PRIMAX
Support for Primax devices that are not fully compliant with the
HID standard.
+config HID_PS3REMOTE
+ tristate "Sony PS3 Bluetooth BD Remote"
+ depends on BT_HIDP
+ ---help---
+ Support for Sony PS3 Bluetooth BD Remote and Logitech Harmony Adapter
+ for PS3.
+
config HID_ROCCAT
tristate "Roccat device support"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index f975485..333ed6c 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_HID_PANTHERLORD) += hid-pl.o
obj-$(CONFIG_HID_PETALYNX) += hid-petalynx.o
obj-$(CONFIG_HID_PICOLCD) += hid-picolcd.o
obj-$(CONFIG_HID_PRIMAX) += hid-primax.o
+obj-$(CONFIG_HID_PS3REMOTE) += hid-ps3remote.o
obj-$(CONFIG_HID_ROCCAT) += hid-roccat.o hid-roccat-common.o \
hid-roccat-arvo.o hid-roccat-isku.o hid-roccat-kone.o \
hid-roccat-koneplus.o hid-roccat-kovaplus.o hid-roccat-pyra.o \
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 60ea284..1838c12 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1591,6 +1591,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_RUMBLEPAD2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACETRAVELLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_SPACENAVIGATOR) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0x0306) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICOLCD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICOLCD_BOOTLOADER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_COMFORT_MOUSE_4500) },
@@ -1641,6 +1642,7 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, 0x0306) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff --git a/drivers/hid/hid-ps3remote.c b/drivers/hid/hid-ps3remote.c
new file mode 100644
index 0000000..a87346e
--- /dev/null
+++ b/drivers/hid/hid-ps3remote.c
@@ -0,0 +1,325 @@
+/*
+ * HID driver for Sony PS3 BD Remote
+ *
+ * Copyright (c) 2012 David Dillow <dave@thedillows.org>
+ * Based on a blend of the bluez fakehid user-space code by Marcel Holtmann
+ * and other kernel HID drivers.
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include <linux/device.h>
+#include <linux/hid.h>
+#include <linux/module.h>
+
+#include "hid-ids.h"
+
+enum ps3remote_special_keys {
+ PS3R_BIT_PS = 0,
+ PS3R_BIT_ENTER = 3,
+ PS3R_BIT_L2 = 8,
+ PS3R_BIT_R2 = 9,
+ PS3R_BIT_L1 = 10,
+ PS3R_BIT_R1 = 11,
+ PS3R_BIT_TRIANGLE = 12,
+ PS3R_BIT_CIRCLE = 13,
+ PS3R_BIT_CROSS = 14,
+ PS3R_BIT_SQUARE = 15,
+ PS3R_BIT_SELECT = 16,
+ PS3R_BIT_L3 = 17,
+ PS3R_BIT_R3 = 18,
+ PS3R_BIT_START = 19,
+ PS3R_BIT_UP = 20,
+ PS3R_BIT_RIGHT = 21,
+ PS3R_BIT_DOWN = 22,
+ PS3R_BIT_LEFT = 23,
+};
+
+static unsigned int ps3remote_bits[] = {
+ [PS3R_BIT_ENTER] = 0x0b,
+ [PS3R_BIT_PS] = 0x43,
+ [PS3R_BIT_SQUARE] = 0x5f,
+ [PS3R_BIT_CROSS] = 0x5e,
+ [PS3R_BIT_CIRCLE] = 0x5d,
+ [PS3R_BIT_TRIANGLE] = 0x5c,
+ [PS3R_BIT_R1] = 0x5b,
+ [PS3R_BIT_L1] = 0x5a,
+ [PS3R_BIT_R2] = 0x59,
+ [PS3R_BIT_L2] = 0x58,
+ [PS3R_BIT_LEFT] = 0x57,
+ [PS3R_BIT_DOWN] = 0x56,
+ [PS3R_BIT_RIGHT] = 0x55,
+ [PS3R_BIT_UP] = 0x54,
+ [PS3R_BIT_START] = 0x53,
+ [PS3R_BIT_R3] = 0x52,
+ [PS3R_BIT_L3] = 0x51,
+ [PS3R_BIT_SELECT] = 0x50,
+};
+
+const static unsigned int ps3remote_keymap[] = {
+ [0x16] = KEY_EJECTCD,
+ [0x64] = KEY_AUDIO,
+ [0x65] = KEY_ANGLE,
+ [0x63] = KEY_SUBTITLE,
+ [0x0f] = KEY_CLEAR,
+ [0x28] = KEY_TIME,
+ [0x00] = KEY_1,
+ [0x01] = KEY_2,
+ [0x02] = KEY_3,
+ [0x03] = KEY_4,
+ [0x04] = KEY_5,
+ [0x05] = KEY_6,
+ [0x06] = KEY_7,
+ [0x07] = KEY_8,
+ [0x08] = KEY_9,
+ [0x09] = KEY_0,
+ [0x81] = KEY_RED,
+ [0x82] = KEY_GREEN,
+ [0x80] = KEY_BLUE,
+ [0x83] = KEY_YELLOW,
+ [0x70] = KEY_INFO, /* display */
+ [0x1a] = KEY_MENU, /* top menu */
+ [0x40] = KEY_CONTEXT_MENU, /* pop up/menu */
+ [0x0e] = KEY_ESC, /* return */
+ [0x5c] = KEY_OPTION, /* options/triangle */
+ [0x5d] = KEY_BACK, /* back/circle */
+ [0x5f] = KEY_SCREEN, /* view/square */
+ [0x5e] = BTN_0, /* cross */
+ [0x54] = KEY_UP,
+ [0x56] = KEY_DOWN,
+ [0x57] = KEY_LEFT,
+ [0x55] = KEY_RIGHT,
+ [0x0b] = KEY_ENTER,
+ [0x5a] = BTN_TL, /* L1 */
+ [0x58] = BTN_TL2, /* L2 */
+ [0x51] = BTN_THUMBL, /* L3 */
+ [0x5b] = BTN_TR, /* R1 */
+ [0x59] = BTN_TR2, /* R2 */
+ [0x52] = BTN_THUMBR, /* R3 */
+ [0x43] = KEY_HOMEPAGE, /* PS button */
+ [0x50] = KEY_SELECT,
+ [0x53] = BTN_START,
+ [0x33] = KEY_REWIND, /* scan back */
+ [0x32] = KEY_PLAY,
+ [0x34] = KEY_FORWARD, /* scan forward */
+ [0x30] = KEY_PREVIOUS,
+ [0x38] = KEY_STOP,
+ [0x31] = KEY_NEXT,
+ [0x60] = KEY_FRAMEBACK, /* slow/step back */
+ [0x39] = KEY_PAUSE,
+ [0x61] = KEY_FRAMEFORWARD, /* slow/step forward */
+};
+
+static __u8 ps3remote_rdesc[] = {
+ 0x05, 0x01, /* USAGE PAGE (Generic Desktop) */
+ 0x09, 0x05, /* USAGE (Game Pad) */
+ 0xa1, 0x01, /* COLLECTION (Application) */
+ 0x05, 0x06, /* USAGE PAGE (Generic Device) */
+ 0x09, 0x20, /* USAGE (Battery Strength) */
+ 0x15, 0x00, /* LOGICAL MINIMUM (0) */
+ 0x25, 0x64, /* LOGICAL MAXIMUM (100) */
+ 0x75, 0x08, /* REPORT SIZE (8) */
+ 0x95, 0x01, /* REPORT COUNT (1) */
+ 0x81, 0x02, /* INPUT (Variable, Absolute) */
+ 0x05, 0x09, /* USAGE PAGE (Button) */
+ 0x19, 0x00, /* USAGE MINUMUM (0) */
+ 0x29, 0xfe, /* USAGE MAXIMUM (254) */
+ 0x15, 0x00, /* LOGICAL MINIMUM (0) */
+ 0x25, 0xfe, /* LOGICAL MAXIMUM (254) */
+ 0x75, 0x08, /* REPORT SIZE (8) */
+ 0x95, 0x01, /* REPORT COUNT (11) */
+ 0x81, 0x00, /* INPUT (Array, Absolute) */
+ 0xc0, /* END_COLLECTION */
+};
+
+struct ps3remote_data {
+ u8 report[12];
+ u8 last_key;
+ u32 last_mask;
+};
+
+static __u8 *ps3remote_fixup(struct hid_device *hdev, __u8 *rdesc,
+ unsigned int *rsize)
+{
+ *rsize = sizeof(ps3remote_rdesc);
+ return ps3remote_rdesc;
+}
+
+static int ps3remote_mapping(struct hid_device *hdev, struct hid_input *hi,
+ struct hid_field *field, struct hid_usage *usage,
+ unsigned long **bit, int *max)
+{
+ unsigned int key = usage->hid & HID_USAGE;
+
+ if ((usage->hid & HID_USAGE_PAGE) != HID_UP_BUTTON ||
+ key >= ARRAY_SIZE(ps3remote_keymap))
+ return -1;
+
+ key = ps3remote_keymap[key];
+ if (!key)
+ return -1;
+
+ hid_map_usage_clear(hi, usage, bit, max, EV_KEY, key);
+ return 1;
+}
+
+static void ps3remote_keychange(struct ps3remote_data *data, u8 key, u8 pressed)
+{
+ /*
+ * Update our report to include/exclude the key that changed, but
+ * make sure it doesn't get listed twice. It's OK if we don't have
+ * room to store a keypress, as that means 11 keys are simultaneously
+ * pressed.
+ */
+ u8 *p = memchr(data->report + 1, key, 11);
+ if (pressed) {
+ if (p)
+ return;
+
+ /* Not present, find a free spot to add it */
+ p = memchr(data->report + 1, 0xff, 11);
+ } else
+ key = 0xff;
+
+ if (p)
+ *p = key;
+}
+
+static int ps3remote_event(struct hid_device *hdev, struct hid_report *report,
+ u8 *raw_data, int size)
+{
+ struct ps3remote_data *data = hid_get_drvdata(hdev);
+ u32 mask, changed;
+ u8 key, pressed;
+ int i;
+
+ if (size != 12) {
+ hid_dbg(hdev, "unsupported report size\n");
+ return 1;
+ }
+
+ /* Battery appears to range from 0 to 5, convert into a percentage */
+ data->report[0] = raw_data[11] * 20;
+
+ /*
+ * Sometimes key presses are reported in the bitmask, sometimes
+ * standalone. It appears the bitmask is used for buttons that
+ * may pressed at the same time.
+ */
+ mask = be32_to_cpup((__be32 *) raw_data);
+ mask &= ~0xff000000;
+ key = raw_data[4];
+ pressed = raw_data[10];
+
+ changed = data->last_mask ^ mask;
+ if (changed) {
+ /* Update any changed multiple keypress reports */
+ for (i = 0; i < 24; i++) {
+ if ((changed & (1 << i)) && ps3remote_bits[i]) {
+ ps3remote_keychange(data, ps3remote_bits[i],
+ !!(mask & (1 << i)));
+ }
+ }
+ data->last_mask = mask;
+ } else if (pressed && key != 0xff) {
+ /* Single key pressed */
+ ps3remote_keychange(data, key, 1);
+ data->last_key = key;
+ } else if (!pressed && data->last_key != 0xff) {
+ /* Single key released */
+ ps3remote_keychange(data, data->last_key, 0);
+ data->last_key = 0xff;
+ } else {
+ hid_dbg(hdev, "Incoherent report, %06x %06x %02x %02x %02x\n",
+ mask, data->last_mask, key, data->last_key, pressed);
+ }
+
+ /* Substitue our updated report */
+ memcpy(raw_data, data->report, 12);
+ return 0;
+}
+
+static int ps3remote_probe(struct hid_device *hdev,
+ const struct hid_device_id *id)
+{
+ struct ps3remote_data *data;
+ int ret = -ENOMEM;
+
+ data = kmalloc(sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ hid_err(hdev, "Can't alloc private data\n");
+ goto err;
+ }
+
+ data->report[0] = 0;
+ memset(data->report + 1, 0xff, 11);
+ data->last_key = 0xff;
+ data->last_mask = 0;
+
+ hid_set_drvdata(hdev, data);
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ hid_err(hdev, "HID parse failed\n");
+ goto err;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret) {
+ hid_err(hdev, "HW start failed\n");
+ goto err;
+ }
+
+ return ret;
+
+err:
+ kfree(data);
+ return ret;
+}
+
+static void ps3remote_remove(struct hid_device *hdev)
+{
+ struct ps3remote_data *data = hid_get_drvdata(hdev);
+
+ hid_hw_stop(hdev);
+ kfree(data);
+}
+
+static const struct hid_device_id ps3remote_devices[] = {
+ /* PS3 BD Remote */
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, 0x0306) },
+ /* Logitech Harmony Adapter for PS3 */
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0x0306) },
+ { }
+};
+MODULE_DEVICE_TABLE(hid, ps3remote_devices);
+
+static struct hid_driver ps3remote_driver = {
+ .name = "ps3_remote",
+ .id_table = ps3remote_devices,
+ .probe = ps3remote_probe,
+ .remove = ps3remote_remove,
+ .report_fixup = ps3remote_fixup,
+ .input_mapping = ps3remote_mapping,
+ .raw_event = ps3remote_event,
+};
+
+static int __init ps3remote_init(void)
+{
+ return hid_register_driver(&ps3remote_driver);
+}
+
+static void __exit ps3remote_exit(void)
+{
+ hid_unregister_driver(&ps3remote_driver);
+}
+
+module_init(ps3remote_init);
+module_exit(ps3remote_exit);
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("David Dillow <dave@thedillows.org>");
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Free the l2cap channel list only when refcount is zero
From: Maxim Levitsky @ 2012-09-13 23:56 UTC (permalink / raw)
To: Jaganath; +Cc: Andrei Emeltchenko, linux-bluetooth, s.syam
In-Reply-To: <4368C8F191BB414F84A70D30771FE893@sisodomain.com>
On Fri, 2012-07-13 at 16:56 +0530, Jaganath wrote:
> Hi Andrei,
>
> --------------------------------------------------
> From: "Andrei Emeltchenko" <andrei.emeltchenko.news@gmail.com>
> Sent: Friday, July 13, 2012 2:19 PM
> To: "Jaganath Kanakkassery" <jaganath.k@samsung.com>
> Cc: <linux-bluetooth@vger.kernel.org>; <s.syam@samsung.com>
> Subject: Re: [PATCH] Bluetooth: Free the l2cap channel list only when
> refcount is zero
>
> > Hi Jaganath,
> >
> > On Fri, Jul 13, 2012 at 01:22:03PM +0530, Jaganath Kanakkassery wrote:
> >> Move the l2cap channel list chan->global_l under the refcnt
> >> protection and free it based on the refcnt.
> >
> > The idea is good.
> >
Note that in 3.6-rc5 which soon to be released, it trivial to trigger a
crash by suspending the system with a2dp headphones connected.
I also have seem (and I strongly suspect the same) crash in 3.5
This patch seems to fix this so far.
Could you sent it to Linus, to fix this kernel panic?
Best regards,
Maxim Levitsky
PS:
The backtrace:
fg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000
mBm)2
cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000
mBm)T:
cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
8
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain,
max_eirp)
cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000
mBm)<
cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000
mBm)P@
cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
general protection fault: 0000 [#1] PREEMPT SMP
Modules linked in: hidp af_packet bnep rfcomm iwl3945
snd_hda_codec_realtek iwlegacy mac80211 snd_hda_intel nfsd btusb
snd_hda_codec uvcvideo snd_hwdep videobuf2_core snd_pcm bluetooth
videobuf2_vmalloc videobuf2_memops nfs_acl auth_rpcgss r592 cfg80211
microcode nfs psmouse memstick serio_raw snd_page_alloc ene_ir battery
ac lockd sunrpc rc_lirc ir_lirc_codec lirc_dev ir_rc6_decoder
firewire_net iTCO_wdt firewire_sbp2 nouveau ttm drm_kms_helper mxm_wmi
usb_storage video wmi uhci_hcd sdhci_pci firewire_ohci firewire_core
sdhci mmc_core atkbd ehci_hcd thermal [last unloaded: tg3]
CPU 0
Pid: 3512, comm: bluetoothd Not tainted 3.6.0-rc5+ #34 Acer Aspire
5720 /Nettiling?b
RIP: 0010:[<ffffffffa03a1d56>] [<ffffffffa03a1d56>] l2cap_chan_destroy
+0x46/0xb0 [bluetooth]
RSP: 0018:ffff8800619dbca8 EFLAGS: 00010296
RAX: dead000000200200 RBX: ffff88007d3f1000 RCX: dead000000100100
RDX: dead000000100100 RSI: dead000000200200 RDI: ffffffffa03b7cc0
RBP: ffff8800619dbcb8 R08: 0000000000000000 R09: 0000000000000000
R10: 0001cc0f349b43de R11: ffffffffa03a1d2d R12: ffff88007d3f1000
R13: ffff88007d3f1014 R14: ffff88005f922570 R15: ffff88005f9229e0
FS: 00007f8aa4634740(0000) GS:ffff88007fa00000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8aa46b7d90 CR3: 000000005f945000 CR4: 00000000000007f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bluetoothd (pid: 3512, threadinfo ffff8800619da000, task
ffff88005ec4bde0)
Stack:
ffff8800619dbcd8 ffff880079945800 ffff8800619dbcd8 ffffffffa03a7b3c
ffff88007d3f1000 ffff88005f922800 ffff8800619dbce8 ffffffffa03a7b85
ffff8800619dbd48 ffffffffa03a231e ffff88007d3f14a0 ffff88005f9229f0
Call Trace:
[<ffffffffa03a7b3c>] l2cap_sock_kill+0x7c/0xb0 [bluetooth]
[<ffffffffa03a7b85>] l2cap_sock_close_cb+0x15/0x20 [bluetooth]
[<ffffffffa03a231e>] l2cap_conn_del+0x11e/0x1f0 [bluetooth]
[<ffffffffa038301a>] ? hci_dev_do_close+0x18a/0x370 [bluetooth]
[<ffffffffa03a6db3>] l2cap_disconn_cfm+0x53/0x60 [bluetooth]
[<ffffffffa0388c55>] hci_conn_hash_flush+0x95/0x100 [bluetooth]
[<ffffffffa038302a>] hci_dev_do_close+0x19a/0x370 [bluetooth]
[<ffffffffa0384af0>] hci_dev_close+0x50/0x80 [bluetooth]
[<ffffffffa039af3a>] hci_sock_ioctl+0x15a/0x420 [bluetooth]
[<ffffffff8144c6e0>] sock_do_ioctl+0x30/0x60
[<ffffffff8105f3e0>] ? task_work_run+0x30/0xa0
[<ffffffff8144d570>] sock_ioctl+0x290/0x2b0
[<ffffffff81147f20>] do_vfs_ioctl+0x580/0x5e0
[<ffffffff8151630b>] ? _raw_spin_unlock_irq+0x3b/0x60
[<ffffffff81147fcf>] sys_ioctl+0x4f/0x80
[<ffffffff81517016>] system_call_fastpath+0x1a/0x1f
Code: 17 e1 48 8b 93 80 04 00 00 48 b9 00 01 10 00 00 00 ad de 48 8b 83
88 04 00 00 48 c7 c7 c0 7c 3b a0 48 be 00 02 20 00 00 00 ad de <48> 89
42 08 48 89 10 48 89 8b 80 04 00 00 48 89 b3 88 04 00 00
"RIP [<ffffffffa03a1d56>] l2cap_chan_destroy+0x46/0xb0 [bluetooth]
RSP <ffff8800619dbca8>
---[ end trace 6e537072816e99b2 ]---+qZ
Kernel panic - not syncing: Fatal exception
fpanic occurred, switching back to text console
Rebooting in 10 seconds..
ACPI MEMORY or I/O RESET_REG.
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: John Tobias @ 2012-09-13 21:59 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CAJdJm_MFT=KTREZavd_oaOVT24+jUsAXH=d-K8F0Rwyi6V1rQg@mail.gmail.com>
Hi Anderson,
I added these line of codes in gatttool:
listen_start:
g_attrib_register(attrib, ATT_OP_READ_BY_TYPE_RESP, events_handler,
attrib, NULL);
Then, in events_handler I dumped the handles for
ATT_OP_READ_BY_TYPE_REQ and ATT_OP_READ_BY_TYPE_RESP:
ATT_OP_READ_BY_TYPE_REQ: handle = 0x1 value: ff ff 00 2a
ATT_OP_READ_BY_TYPE_RESP: handle = 0x207 value: 00 02 03 00 00 2a 04
00 02 05 00 01 2a 07 00 20 08 00 05 2a
ATT_OP_READ_BY_TYPE_RESP: handle = 0xb15 value: 00 02 0c 00 31 3d 35
06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
ATT_OP_READ_BY_TYPE_RESP: handle = 0xd15 value: 00 8a 0e 00 32 3d 35
06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1015 value: 00 88 11 00 33 3d
35 06 1e 60 70 a3 8d 4e 58 9c 2d 6a 3c 16
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1315 value: 00 9a 14 00 52 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1715 value: 00 9a 18 00 36 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1b15 value: 00 9a 1c 00 37 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x1f15 value: 00 8a 20 00 38 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2215 value: 00 98 23 00 40 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2615 value: 00 9a 27 00 41 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2a15 value: 00 98 2b 00 42 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x2e15 value: 00 88 2f 00 60 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x3115 value: 00 88 32 00 61 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x3415 value: 00 12 35 00 62 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
ATT_OP_READ_BY_TYPE_RESP: handle = 0x3715 value: 00 8a 38 00 39 72
3a 71 ae 82 0c ae e0 49 1d 18 c2 b4 d8 37
In hcidump:
ACL data: handle 76 flags 0x02 dlen 9
ATT: Error (0x01)
Error: Attribute not found (10)
Read By Type req (0x08) on handle 0x0039
In hcidump, the error was the attribute for handle 0x0039. How I can
respond to that request if the I did not receive the said handle?
Regards,
John
On Thu, Sep 13, 2012 at 1:18 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi John,
>
> On Thu, Sep 13, 2012 at 4:11 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hi Anderson,
>>
>> If I add a simple GATT/GAP server on gatttool, should I still use the
>> DBUS to listen or I can communicate directly to the kernel?.
>
> You either talk to bluetoothd (using D-Bus, like those test-* python
> scripts do), which will handle connections for you, or you talk
> directly to kernel using bluetooth socket (like gatttool does). You
> have more flexibility talking to the kernel directly, but your app
> will not be interoperable with other apps running at the same time,
> specially if they try to call connect() at the same time (one of them
> will get a EBUSY error).
>
> Using D-Bus, on the other hand, bluetoothd queues the connections properly.
>
> So you should use what is more appropriate for your use case.
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
^ permalink raw reply
* Re: Wii Balance Board vs. bluez
From: Florian Echtler @ 2012-09-13 21:35 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth
In-Reply-To: <CANq1E4S70tqhTG7PTMj5cHp45NLO9g4n1eLVaHJMuDZx1KMYjg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
On 13.09.2012 16:39, David Herrmann wrote:
>> Please see the appended patch. You have to apply it to your kernel
>> tree and recompile the hid-wiimote driver. No other sources are
>> changed so you don't need to reboot or install the new kernel. Just
>> install the new hid-wiimote.ko module.
>>
>> One of the 5 input devices should then report the wiimote weight
>> sensor data. (the input device with name "Wii Remote Balance Board").
> Forgot to attach the patch... Here it is.
Awesome - works as expected, weight sensor data can be read from one of
the event devices.
I've attached an additional patch on top of yours to also read the
calibration data (24 bytes at address 0xa40024). Calibration data is
applied in handler_balance_board, resulting values are in units of 10
grams. Although this looks correct to me, I'm not getting any events
with my patch applied - I suspect some connection to the min/max input
values. Do you have any ideas what's wrong?
Florian
--
SENT FROM MY DEC VT50 TERMINAL
[-- Attachment #2: balance_calibration.patch --]
[-- Type: text/x-patch, Size: 3806 bytes --]
diff -u a/hid-wiimote-ext.c b/hid-wiimote-ext.c
--- a/hid-wiimote-ext.c 2012-09-13 21:04:01.600494774 +0200
+++ b/hid-wiimote-ext.c 2012-09-13 23:30:57.416209821 +0200
@@ -28,6 +28,7 @@
bool mp_plugged;
bool motionp;
__u8 ext_type;
+ __u16 calib[4][3];
};
enum wiiext_type {
@@ -127,6 +128,7 @@
static __u8 ext_read(struct wiimote_ext *ext)
{
ssize_t ret;
+ __u8 buf[24];
__u8 rmem[2], wmem;
__u8 type = WIIEXT_NONE;
@@ -159,6 +161,29 @@
rmem[0], rmem[1]);
}
+ /* get balance board calibration */
+ if (type == WIIEXT_BALANCE_BOARD) {
+
+ ret = wiimote_cmd_read(ext->wdata, 0xa40024, buf, 24);
+ if (ret != 24)
+ type = WIIEXT_NONE;
+
+ ext->calib[0][0] = ((__u16)buf[ 0]<<8 | (__u16)buf[ 1]);
+ ext->calib[1][0] = ((__u16)buf[ 2]<<8 | (__u16)buf[ 3]);
+ ext->calib[2][0] = ((__u16)buf[ 4]<<8 | (__u16)buf[ 5]);
+ ext->calib[3][0] = ((__u16)buf[ 6]<<8 | (__u16)buf[ 7]);
+
+ ext->calib[0][1] = ((__u16)buf[ 8]<<8 | (__u16)buf[ 9]);
+ ext->calib[1][1] = ((__u16)buf[10]<<8 | (__u16)buf[11]);
+ ext->calib[2][1] = ((__u16)buf[12]<<8 | (__u16)buf[13]);
+ ext->calib[3][1] = ((__u16)buf[14]<<8 | (__u16)buf[15]);
+
+ ext->calib[0][2] = ((__u16)buf[16]<<8 | (__u16)buf[17]);
+ ext->calib[1][2] = ((__u16)buf[18]<<8 | (__u16)buf[19]);
+ ext->calib[2][2] = ((__u16)buf[20]<<8 | (__u16)buf[21]);
+ ext->calib[3][2] = ((__u16)buf[22]<<8 | (__u16)buf[23]);
+ }
+
wiimote_cmd_release(ext->wdata);
return type;
@@ -517,7 +542,9 @@
static void handler_balance_board(struct wiimote_ext *ext, const __u8 *payload)
{
- __s16 tr, br, tl, bl;
+ __s16 val[4]; /*tr, br, tl, bl;*/
+ unsigned long tmp;
+ __u8 i;
/* Byte | 8 7 6 5 4 3 2 1 |
* -----+--------------------------+
@@ -540,19 +567,28 @@
* The balance-board is never reported interleaved with motionp.
*/
- tr = payload[0] << 8;
- tr |= payload[1];
- br = payload[2] << 8;
- br |= payload[3];
- tl = payload[4] << 8;
- tl |= payload[5];
- bl = payload[6] << 8;
- bl |= payload[7];
-
- input_report_abs(ext->input, ABS_HAT0X, tl);
- input_report_abs(ext->input, ABS_HAT0Y, tr);
- input_report_abs(ext->input, ABS_HAT1X, bl);
- input_report_abs(ext->input, ABS_HAT1Y, br);
+ val[0] = payload[0] << 8;
+ val[0] |= payload[1];
+ val[1] = payload[2] << 8;
+ val[1] |= payload[3];
+ val[2] = payload[4] << 8;
+ val[2] |= payload[5];
+ val[3] = payload[6] << 8;
+ val[3] |= payload[7];
+
+ /* apply calibration data */
+ for( i = 0; i < 4; i++ ) {
+ if (val[i] < ext->calib[i][1])
+ tmp = 1700 * (val[i] - ext->calib[i][0]) / (ext->calib[i][1] - ext->calib[i][0]);
+ else
+ tmp = 1700 * (val[i] - ext->calib[i][1]) / (ext->calib[i][2] - ext->calib[i][1]) + 1700;
+ val[i] = tmp;
+ }
+
+ input_report_abs(ext->input, ABS_HAT0X, val[0]);
+ input_report_abs(ext->input, ABS_HAT0Y, val[1]);
+ input_report_abs(ext->input, ABS_HAT1X, val[2]);
+ input_report_abs(ext->input, ABS_HAT1Y, val[3]);
input_sync(ext->input);
}
@@ -707,10 +743,10 @@
set_bit(ABS_HAT2Y, ext->input->absbit);
set_bit(ABS_HAT3X, ext->input->absbit);
set_bit(ABS_HAT3Y, ext->input->absbit);
- input_set_abs_params(ext->input, ABS_HAT0X, -120, 120, 2, 4);
- input_set_abs_params(ext->input, ABS_HAT0Y, -120, 120, 2, 4);
- input_set_abs_params(ext->input, ABS_HAT1X, -30, 30, 1, 1);
- input_set_abs_params(ext->input, ABS_HAT1Y, -30, 30, 1, 1);
+ input_set_abs_params(ext->input, ABS_HAT0X, -20000, 20000, 2, 4);
+ input_set_abs_params(ext->input, ABS_HAT0Y, -20000, 20000, 2, 4);
+ input_set_abs_params(ext->input, ABS_HAT1X, -20000, 20000, 1, 1);
+ input_set_abs_params(ext->input, ABS_HAT1Y, -20000, 20000, 1, 1);
input_set_abs_params(ext->input, ABS_HAT2X, -30, 30, 1, 1);
input_set_abs_params(ext->input, ABS_HAT2Y, -30, 30, 1, 1);
input_set_abs_params(ext->input, ABS_HAT3X, -30, 30, 1, 1);
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: Anderson Lizardo @ 2012-09-13 20:18 UTC (permalink / raw)
To: John Tobias; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CACUGKYPf+2ZP6y5rfy8kbnanxCJt3pL800E6bHNO6WUSifQW+A@mail.gmail.com>
Hi John,
On Thu, Sep 13, 2012 at 4:11 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Anderson,
>
> If I add a simple GATT/GAP server on gatttool, should I still use the
> DBUS to listen or I can communicate directly to the kernel?.
You either talk to bluetoothd (using D-Bus, like those test-* python
scripts do), which will handle connections for you, or you talk
directly to kernel using bluetooth socket (like gatttool does). You
have more flexibility talking to the kernel directly, but your app
will not be interoperable with other apps running at the same time,
specially if they try to call connect() at the same time (one of them
will get a EBUSY error).
Using D-Bus, on the other hand, bluetoothd queues the connections properly.
So you should use what is more appropriate for your use case.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: Anderson Lizardo @ 2012-09-13 20:11 UTC (permalink / raw)
To: John Tobias; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CACUGKYNPWDCbQgtA6u33NXn_U3CMm9q6vGqEAaA9FOPPjqeJiw@mail.gmail.com>
Hi John,
On Thu, Sep 13, 2012 at 2:44 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Which messages did you see?
>
> The ran the bluetoothd with debug message:
>
> [snip]
This log just shows the temporary device being created due to the
connection made by gatttool. bluetoothd does not have any open socket
where the ATT requests could be handled (unless the connection was
created by bluetoothd itself and not gatttool).
If bluetoothd GATT server processed the ATT request sent by your
phone, you would see this:
bluetoothd[NNNN]: src/attrib-server.c:channel_handler() op 0x10
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: John Tobias @ 2012-09-13 20:11 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CACUGKYNPWDCbQgtA6u33NXn_U3CMm9q6vGqEAaA9FOPPjqeJiw@mail.gmail.com>
Hi Anderson,
If I add a simple GATT/GAP server on gatttool, should I still use the
DBUS to listen or I can communicate directly to the kernel?.
Regards,
John
On Thu, Sep 13, 2012 at 11:44 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Anderson,
>
>
>
> On Thu, Sep 13, 2012 at 11:36 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> Hi John,
>>
>> On Thu, Sep 13, 2012 at 2:18 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>>> Hi Anderson,
>>>
>>> Here's what I did:
>>>
>>> I set the EnableGatt=true and executed my bluetoothd. The debug
>>> messages of bluetoothd confirmed that it was responding to the request
>>> of my iPhone.
>>
>> Which messages did you see?
>
> The ran the bluetoothd with debug message:
>
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 19 bytes
> from management socket
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_connected() hci0
> device 6E:FA:41:C4:DA:AD connected eir_len 0
> bluetoothd[14762]: src/event.c:btd_event_conn_complete() Entry:
> btd_event_conn_complete
> bluetoothd[14762]: src/adapter.c:adapter_get_device() 6E:FA:41:C4:DA:AD
> bluetoothd[14762]: src/adapter.c:adapter_create_device() 6E:FA:41:C4:DA:AD
> bluetoothd[14762]: src/device.c:device_create() Creating device
> /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
> bluetoothd[14762]: src/device.c:btd_device_ref() 0xb8600018: ref=1
> bluetoothd[14762]: src/device.c:device_set_temporary() temporary 1
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 13 bytes
> from management socket
> bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_disconnected() hci0
> device 6E:FA:41:C4:DA:AD disconnected
> bluetoothd[14762]: src/event.c:btd_event_disconn_complete()
> bluetoothd[14762]: src/adapter.c:adapter_remove_connection()
> bluetoothd[14762]: src/adapter.c:adapter_remove_connection() Removing
> temporary device /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
> bluetoothd[14762]: src/device.c:device_remove() Removing device
> /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
> bluetoothd[14762]: src/device.c:btd_device_unref() 0xb8600018: ref=0
> bluetoothd[14762]: src/device.c:device_free() 0xb8600018
>
>
>
> I will look at the code you mention and will start from there.
>
> Regards,
>
> john
>
>>
>>>
>>> I used gatttool to connect to the device and read the characteristic..
>>
>> gatttool is only for testing. It will open a bluetooth socket and talk
>> directly with the kernel (without bluetoothd help). In fact, it runs
>> just fine without any bluetoothd running (you need to do a "hciconfig
>> hciX up" though).
>>
>> If you want your app to properly integrate with bluetoothd, you need
>> to create connections using BlueZ's D-Bus APIs.
>>
>> Take a look at some example code:
>>
>> test/test-device (if you need to do the pairing from your application)
>> test/test-attrib (if you want to talk to some profile not supported by
>> BlueZ yet)
>> test/test-thermometer (for GATT Health Thermometer)
>> test/test-proximity (for GATT Proximity)
>> ...
>>
>> if the profile you want to use is one of the official ones, we
>> encourage you implement them as a BlueZ plugin, and provide some D-Bus
>> API that your app (or other apps) can use. That way we avoid
>> duplicating profile implementations. See for example the thermometer
>> (HTP) and proximity (PXP) implementations in BlueZ.
>>
>> Some others are in process of being implemented upstream: Battery,
>> Heart Rate, and Server profiles (Time, Alert Notification, Phone Alert
>> Status).
>>
>> Best Regards,
>> --
>> Anderson Lizardo
>> Instituto Nokia de Tecnologia - INdT
>> Manaus - Brazil
^ permalink raw reply
* Re: [PATCH] wiimote: add Wii Balance Board detection
From: Florian Echtler @ 2012-09-13 18:47 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth, johan.hedberg
In-Reply-To: <1347485573-23623-1-git-send-email-dh.herrmann@googlemail.com>
Confirmed to work, with patch applied against 4.101 Ubuntu package.
Florian
On 12.09.2012 23:32, David Herrmann wrote:
> Add the name of the Wii Balance Board so it can be paired with BlueZ like
> any other Wii Remote. Reported by Florian Echtler.
> ---
> plugins/wiimote.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/plugins/wiimote.c b/plugins/wiimote.c
> index 337d408..3d16966 100644
> --- a/plugins/wiimote.c
> +++ b/plugins/wiimote.c
> @@ -76,6 +76,7 @@ static ssize_t wii_pincb(struct btd_adapter *adapter, struct btd_device *device,
> name[sizeof(name) - 1] = 0;
>
> if (g_str_equal(name, "Nintendo RVL-CNT-01") ||
> + g_str_equal(name, "Nintendo RVL-WBC-01") ||
> (vendor == 0x057e && product == 0x0306)) {
> DBG("Forcing fixed pin on detected wiimote %s", addr);
> memcpy(pinbuf, &sba, 6);
>
--
SENT FROM MY DEC VT50 TERMINAL
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: John Tobias @ 2012-09-13 18:44 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CAJdJm_PwrHdWnp6xXoYzd8GLigO3YSHdS-6feVj+c-9u3sjk5A@mail.gmail.com>
Hi Anderson,
On Thu, Sep 13, 2012 at 11:36 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi John,
>
> On Thu, Sep 13, 2012 at 2:18 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hi Anderson,
>>
>> Here's what I did:
>>
>> I set the EnableGatt=true and executed my bluetoothd. The debug
>> messages of bluetoothd confirmed that it was responding to the request
>> of my iPhone.
>
> Which messages did you see?
The ran the bluetoothd with debug message:
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 19 bytes
from management socket
bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_connected() hci0
device 6E:FA:41:C4:DA:AD connected eir_len 0
bluetoothd[14762]: src/event.c:btd_event_conn_complete() Entry:
btd_event_conn_complete
bluetoothd[14762]: src/adapter.c:adapter_get_device() 6E:FA:41:C4:DA:AD
bluetoothd[14762]: src/adapter.c:adapter_create_device() 6E:FA:41:C4:DA:AD
bluetoothd[14762]: src/device.c:device_create() Creating device
/org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
bluetoothd[14762]: src/device.c:btd_device_ref() 0xb8600018: ref=1
bluetoothd[14762]: src/device.c:device_set_temporary() temporary 1
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[14762]: plugins/mgmtops.c:mgmt_event() Received 13 bytes
from management socket
bluetoothd[14762]: plugins/mgmtops.c:mgmt_device_disconnected() hci0
device 6E:FA:41:C4:DA:AD disconnected
bluetoothd[14762]: src/event.c:btd_event_disconn_complete()
bluetoothd[14762]: src/adapter.c:adapter_remove_connection()
bluetoothd[14762]: src/adapter.c:adapter_remove_connection() Removing
temporary device /org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
bluetoothd[14762]: src/device.c:device_remove() Removing device
/org/bluez/14762/hci0/dev_6E_FA_41_C4_DA_AD
bluetoothd[14762]: src/device.c:btd_device_unref() 0xb8600018: ref=0
bluetoothd[14762]: src/device.c:device_free() 0xb8600018
I will look at the code you mention and will start from there.
Regards,
john
>
>>
>> I used gatttool to connect to the device and read the characteristic..
>
> gatttool is only for testing. It will open a bluetooth socket and talk
> directly with the kernel (without bluetoothd help). In fact, it runs
> just fine without any bluetoothd running (you need to do a "hciconfig
> hciX up" though).
>
> If you want your app to properly integrate with bluetoothd, you need
> to create connections using BlueZ's D-Bus APIs.
>
> Take a look at some example code:
>
> test/test-device (if you need to do the pairing from your application)
> test/test-attrib (if you want to talk to some profile not supported by
> BlueZ yet)
> test/test-thermometer (for GATT Health Thermometer)
> test/test-proximity (for GATT Proximity)
> ...
>
> if the profile you want to use is one of the official ones, we
> encourage you implement them as a BlueZ plugin, and provide some D-Bus
> API that your app (or other apps) can use. That way we avoid
> duplicating profile implementations. See for example the thermometer
> (HTP) and proximity (PXP) implementations in BlueZ.
>
> Some others are in process of being implemented upstream: Battery,
> Heart Rate, and Server profiles (Time, Alert Notification, Phone Alert
> Status).
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: Anderson Lizardo @ 2012-09-13 18:36 UTC (permalink / raw)
To: John Tobias; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CACUGKYPSTh0CcN6fKc9NcbYmvZK3j8AwfNnMqkBkoTt-UFccSg@mail.gmail.com>
Hi John,
On Thu, Sep 13, 2012 at 2:18 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Anderson,
>
> Here's what I did:
>
> I set the EnableGatt=true and executed my bluetoothd. The debug
> messages of bluetoothd confirmed that it was responding to the request
> of my iPhone.
Which messages did you see?
>
> I used gatttool to connect to the device and read the characteristic..
gatttool is only for testing. It will open a bluetooth socket and talk
directly with the kernel (without bluetoothd help). In fact, it runs
just fine without any bluetoothd running (you need to do a "hciconfig
hciX up" though).
If you want your app to properly integrate with bluetoothd, you need
to create connections using BlueZ's D-Bus APIs.
Take a look at some example code:
test/test-device (if you need to do the pairing from your application)
test/test-attrib (if you want to talk to some profile not supported by
BlueZ yet)
test/test-thermometer (for GATT Health Thermometer)
test/test-proximity (for GATT Proximity)
...
if the profile you want to use is one of the official ones, we
encourage you implement them as a BlueZ plugin, and provide some D-Bus
API that your app (or other apps) can use. That way we avoid
duplicating profile implementations. See for example the thermometer
(HTP) and proximity (PXP) implementations in BlueZ.
Some others are in process of being implemented upstream: Battery,
Heart Rate, and Server profiles (Time, Alert Notification, Phone Alert
Status).
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: John Tobias @ 2012-09-13 18:18 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CAJdJm_MYn=eG93WTPmHWu98t3Ufqrc9pXDpdBbCvbT-JdYeOaw@mail.gmail.com>
Hi Anderson,
Here's what I did:
I set the EnableGatt=true and executed my bluetoothd. The debug
messages of bluetoothd confirmed that it was responding to the request
of my iPhone.
I used gatttool to connect to the device and read the characteristic..
Is this scenario should work or not?.
Regards,
john
On Thu, Sep 13, 2012 at 11:07 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi John,
>
> On Thu, Sep 13, 2012 at 1:50 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hi Anderson,
>>
>> Here are the logs after reading the characteristic from my iPad apps
>> that do the advertising.
>
> I can just confirm what Vinicius said, the disconnection after 30s
> happens because the IPad sent a "Read By Type req" that gatttool does
> not answer because it does not run a GATT server.
>
> Are you planning to implement any client (or server) profile for these
> apps? If so, you should look at how to implement them as BlueZ
> plugins.
>
> You could also try to implement a simple GATT/GAP server on gatttool,
> so you could use it for testing without any disconnections.
>
>
> PS: interestingly, it seems IPad apps are able to send connectable
> advertising over LE channel from a dual mode controller... which is
> against Core spec 4.0... odd.
>
> Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: Anderson Lizardo @ 2012-09-13 18:07 UTC (permalink / raw)
To: John Tobias; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CACUGKYMv_X4DgU+C0V=PA_PfYRQYnKO1LM4SoDbfcB2O-XkJvQ@mail.gmail.com>
Hi John,
On Thu, Sep 13, 2012 at 1:50 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Anderson,
>
> Here are the logs after reading the characteristic from my iPad apps
> that do the advertising.
I can just confirm what Vinicius said, the disconnection after 30s
happens because the IPad sent a "Read By Type req" that gatttool does
not answer because it does not run a GATT server.
Are you planning to implement any client (or server) profile for these
apps? If so, you should look at how to implement them as BlueZ
plugins.
You could also try to implement a simple GATT/GAP server on gatttool,
so you could use it for testing without any disconnections.
PS: interestingly, it seems IPad apps are able to send connectable
advertising over LE channel from a dual mode controller... which is
against Core spec 4.0... odd.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: John Tobias @ 2012-09-13 17:50 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CAJdJm_OfccWTVuphRQfjfouY3m8_HgSeGwE-XSyHetzy+tjFFw@mail.gmail.com>
Hi Anderson,
Here are the logs after reading the characteristic from my iPad apps
that do the advertising.
HCI sniffer - Bluetooth packet analyzer ver 2.2
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
type 0x01 (active)
interval 10.000ms window 10.000ms
own address: 0x00 (Public) policy: All
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Parameters (0x08|0x000b) ncmd 1
status 0x00
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
value 0x01 (scanning enabled)
filter duplicates 0x01 (enabled)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -60
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -60
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -62
> HCI Event: LE Meta Event (0x3e) plen 43
LE Advertising Report
ADV_IND - Connectable undirected advertising (0)
bdaddr 60:36:25:4A:6B:75 (Random)
Flags: 0x1a
Unknown type 0x07 with 16 bytes data
Complete local name: 'Appl0001'
RSSI: -69
> HCI Event: LE Meta Event (0x3e) plen 12
LE Advertising Report
SCAN_RSP - Scan Response (4)
bdaddr 60:36:25:4A:6B:75 (Random)
RSSI: -69
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
value 0x00 (scanning disabled)
filter duplicates 0x01 (enabled)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Scan Enable (0x08|0x000c) ncmd 1
status 0x00
< HCI Command: LE Create Connection (0x08|0x000d) plen 25
bdaddr 60:36:25:4A:6B:75 type 1
> HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete
status 0x00 handle 76, role master
bdaddr 60:36:25:4A:6B:75 (Random)
> ACL data: handle 76 flags 0x02 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2a00
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0001, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 7
handle 0x0002, value 0x02 0x03 0x00 0x00 0x2a
handle 0x0004, value 0x02 0x05 0x00 0x01 0x2a
handle 0x0007, value 0x20 0x08 0x00 0x05 0x2a
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0008, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x000b, value 0x02 0x0c 0x00 0x31 0x3d 0x35 0x06 0x1e
0x60 0x70 0xa3 0x8d 0x4e 0x58 0x9c 0x2d 0x6a 0x3c 0x16
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x000c, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x000d, value 0x8a 0x0e 0x00 0x32 0x3d 0x35 0x06 0x1e
0x60 0x70 0xa3 0x8d 0x4e 0x58 0x9c 0x2d 0x6a 0x3c 0x16
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x000e, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0010, value 0x88 0x11 0x00 0x33 0x3d 0x35 0x06 0x1e
0x60 0x70 0xa3 0x8d 0x4e 0x58 0x9c 0x2d 0x6a 0x3c 0x16
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0011, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0013, value 0x9a 0x14 0x00 0x52 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0014, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0017, value 0x9a 0x18 0x00 0x36 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0018, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x001b, value 0x9a 0x1c 0x00 0x37 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x001c, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x001f, value 0x8a 0x20 0x00 0x38 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0020, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0022, value 0x98 0x23 0x00 0x40 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0023, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0026, value 0x9a 0x27 0x00 0x41 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0027, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x002a, value 0x98 0x2b 0x00 0x42 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x002b, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x002e, value 0x88 0x2f 0x00 0x60 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x002f, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0031, value 0x88 0x32 0x00 0x61 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0032, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0034, value 0x12 0x35 0x00 0x62 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0035, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 27
ATT: Read By Type resp (0x09)
length: 21
handle 0x0037, value 0x8a 0x38 0x00 0x39 0x72 0x3a 0x71 0xae
0x82 0x0c 0xae 0xe0 0x49 0x1d 0x18 0xc2 0xb4 0xd8 0x37
< ACL data: handle 76 flags 0x00 dlen 11
ATT: Read By Type req (0x08)
start 0x0038, end 0xffff
type-uuid 0x2803
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 76 packets 1
> ACL data: handle 76 flags 0x02 dlen 9
ATT: Error (0x01)
Error: Attribute not found (10)
Read By Type req (0x08) on handle 0x0039
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 76 reason 0x13
Reason: Remote User Terminated Connection
Regards,
John
On Thu, Sep 13, 2012 at 3:53 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Hi John,
>
> On Wed, Sep 12, 2012 at 10:52 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hello again,
>>
>> I enabled the GATT in my bluetoothd and found out that there was an
>> unimplemented attribute (below) and might be the reason why the iPhone
>> connection got disconnected after 30 secs.
>>
>> 2012-09-12 15:36:55.419980 > ACL data: handle 76 flags 0x02 dlen 9
>> ATT: Error (0x01)
>> Error: Attribute not found (10)
>> Read By Type req (0x08) on handle 0x0039
>>
>> I would like to know if anyone here has a patch?.
>
> Just this snippet does not say much. "Attribute not found" errors are
> common during service/characteristic discovery because they indicate
> that the discovery has finished.
>
> Could you post the whole hcidump since the connection establishment up
> to the disconnection? That should help detecting the problem.
>
> Best Regards,
> --
> Anderson Lizardo
> Instituto Nokia de Tecnologia - INdT
> Manaus - Brazil
^ 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