From: "Daniel T. Cobra" <dcobra@videam.com.br>
To: venu <vjosyula@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Long delay to (re)connect a bluetooth mouse
Date: Wed, 23 Dec 2009 13:19:59 -0200 [thread overview]
Message-ID: <4B32351F.2010907@videam.com.br> (raw)
In-Reply-To: <53ea87da0912222033y530c83dci41bb6d9b99ece6c@mail.gmail.com>
Hi Vanu:
Thanks for your suggestion. However, isn't there a better way? I don't
know the HID specification, but I imagine it should probably foresee the
possibility of not repeating the remote name request when you need fast
reconnection. Isn't there an operating mode, configuration option,
whatever, that would do this without the need to modify bluez' code? I'd
like to make sure there is really no better alternative, before going
down this path. What do you think?
Regards,
Daniel
venu wrote:
> Hi Daniel,
>
> Actually you are right, it can directly do read remote features
> without doing a remote name request, as the connection already exists.
>
> Why dont you run a small experiment. Find the place in the code which
> sends HCI Command to do a remote name request and comment that piece
> of code if the HID Connection exists and then try reconnecting i.e.
> 1. Make the above changes to the code.
> 2. Pair your hid as well as establish HID Connection.
> 3. While doing get the HCI DUMP again, this time you should not see
> any HCI Command for remote name request.
>
> I sure , you should see improvement in the reconnection timing, as a
> side note if you have any hci tracer for windows you can capture the
> HCI Traces as you have caputred above and compare them too, that will
> give you clues what exactly is happening.
>
> Cheers,
> Venu
next prev parent reply other threads:[~2009-12-23 15:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-15 19:43 Long delay to (re)connect a bluetooth mouse dcobra
2009-12-17 15:17 ` Daniel T. Cobra
2009-12-18 17:43 ` Daniel T. Cobra
2009-12-18 22:04 ` Marcel Holtmann
2009-12-18 22:49 ` dcobra
2009-12-18 22:58 ` Marcel Holtmann
2009-12-19 1:21 ` dcobra
2009-12-22 12:02 ` Daniel T. Cobra
2009-12-22 12:09 ` Daniel T. Cobra
[not found] ` <53ea87da0912222033y530c83dci41bb6d9b99ece6c@mail.gmail.com>
2009-12-23 11:01 ` Daniel T. Cobra
2009-12-23 15:19 ` Daniel T. Cobra [this message]
[not found] ` <4B32336C.8080806@videam.com.br>
[not found] ` <53ea87da0912230727q617dce1axe5053cd32d03bbf5@mail.gmail.com>
2009-12-23 15:38 ` Daniel T. Cobra
2009-12-23 15:48 ` Stefan Seyfried
2009-12-23 16:00 ` venu
2009-12-23 17:53 ` Daniel T. Cobra
2009-12-29 15:01 ` Stefan Seyfried
2010-01-04 18:48 ` Daniel T. Cobra
2010-01-05 10:51 ` Stefan Seyfried
2010-02-03 11:44 ` Daniel T. Cobra
2010-02-03 13:58 ` Stefan Seyfried
2010-02-03 14:12 ` Marcel Holtmann
2010-02-03 14:34 ` Daniel T. Cobra
2010-02-03 14:37 ` Marcel Holtmann
2010-02-03 17:13 ` Daniel T. Cobra
2010-02-03 18:04 ` Iain Hibbert
2010-02-04 16:19 ` Daniel T. Cobra
2010-02-04 18:13 ` Iain Hibbert
2010-02-05 11:24 ` Daniel T. Cobra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B32351F.2010907@videam.com.br \
--to=dcobra@videam.com.br \
--cc=linux-bluetooth@vger.kernel.org \
--cc=vjosyula@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.