Long delay to (re)connect a bluetooth mouse

Long delay to (re)connect a bluetooth mouse

[dcobra]

I have a bluetooth mouse that I have tried to use with a notebook running
Kubuntu Jaunty, Kubuntu Karmic, and sidux 2009-03. With all three distros it
always takes about 5 to 6 seconds for the mouse to connect (or reconnect,
coming out of sleep mode). However, if I boot the notebook under Windows XP,
the same mouse always (re)connects in under one second. Having to wait for 5-6
seconds every time I bring the mouse out of sleep mode under Linux is quite
annoying!

I have opened an Ubuntu bug and posted to the Ubuntu and sidux forums about
this, but got exactly zero replies (the Ubuntu bug was opened back in May and
nobody has even touched it!) So now I come to see if I have better luck here on
this mailing list.

Specifically, I'd like to ask: is there some bluez configuration option I can
try to speed up the mouse (re)connection, or is this 5-6 second delay the norm
under Linux?

The notebook is an Asus A8Js with a built-in bluetooth module, and the mouse is
a Targus AMB02US. In my latest attempt, under sidux, I followed the directions
found in http://www.sidux.com/index.php?module=Wikula&tag=hwBluetooth to set it
up. Please let me know if there is any additional information I should provide
about my system to help diagnose this problem.

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Not a single reply two days later! It seems nobody is interested in this 
subject here or in the Ubuntu and sidux forums. Do so few people 
actually use bluetooth mice? Folks, I'm starting to feel ignored!

I've been a Linux user for more than 15 years. I know nothing about the 
bluetooth protocol and I'm not a developer, but over the years I have 
made small contributions to the Open Sound System code, a couple of Gnu 
applications and other open-source software. Never before have I 
experienced such difficulty in finding someone with whom to discuss a 
Linux-related issue as now with this problem of the bluetooth mouse 
reconnection delay!

I'm sorry if this kind of discussion is not appropriate for this mailing 
list. If so, will somebody please be kind enough to suggest a forum 
where I could ask if there are any bluez configuration options I could 
try out to speed up the mouse reconnection when it comes out of sleep 
mode. As I mentioned in my first post, this same mouse reconnects very 
fast when I boot my notebook under Windows XP, and I want to try to 
achieve the same kind of performance under Linux.

Somebody please talk to me! :-)

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Unbelievable! Here too my posts get zero replies!

I fell like Bruce Willis in "The Sixth Sense". Maybe I died and just 
haven't realized it yet! Where is that kid that talks to the dead? Maybe 
he knows something about bluetooth mouse reconnection delays.

But, seriously, I guess I'll just have to give up using my bluetooth 
mouse under Linux. Waiting 5 to 6 seconds for the mouse to reconnect 
every time it goes to sleep is too much of a nuisance!

If anybody can read me, good luck with your work developing bluez and 
happy Holidays to all.

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Marcel Holtmann]

Hi Daniel,

> Unbelievable! Here too my posts get zero replies!
> 
> I fell like Bruce Willis in "The Sixth Sense". Maybe I died and just 
> haven't realized it yet! Where is that kid that talks to the dead? Maybe 
> he knows something about bluetooth mouse reconnection delays.
> 
> But, seriously, I guess I'll just have to give up using my bluetooth 
> mouse under Linux. Waiting 5 to 6 seconds for the mouse to reconnect 
> every time it goes to sleep is too much of a nuisance!
> 
> If anybody can read me, good luck with your work developing bluez and 
> happy Holidays to all.

you do know that an open source community doesn't work like this. If
someone would be able to make anything out of your posting or has
experienced the same, they would have spoken. Since you didn't even
include any logs or hcidump details, you didn't even gave any person
without the hardware to respond.

Regards

Marcel

Re: Long delay to (re)connect a bluetooth mouse

[dcobra]

Hi Marcel:

Thanks so much for replying! It seems a little humor helped to get someone's
attention, even though I'm not sure you fully appreciated it :-)

> you do know that an open source community doesn't work like this.

As I mentioned in my second post, I have interacted and made small contributions
of code to the open source community several times in the past, and my
experience this time around was atypical because I was having a hard time just
getting someone to reply!

> If someone would be able to make anything out of your posting or has
> experienced the same, they would have spoken.

Was it unreasonable to expect that someone would say: "Nobody is experiencing
this kind of delay, maybe it's something in your setup"? Or even, "this is not
the right forum for non-developers to ask for help, why don't you try such and
such place?"

> Since you didn't even
> include any logs or hcidump details, you didn't even gave any person
> without the hardware to respond.

As I also made clear, I am not a developer, and I didn't know what kind of
information would be useful. I didn't want to post a long message with
information that might be irrelevant. I did ask in my first post what kind of
information I should provide to help diagnose the problem.

Sometimes one's attitude doesn't come accross as intended in e-mails. My tirade
about The Sixth Sense was meant to express amusement, and not resentment, at
the situation. I was sincere in my wishes to the bluez community of developers.
Without you folks there would be no bluetooth for Linux at all, and appreciate
your work.

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Marcel Holtmann]

Hi Daniel,

> Thanks so much for replying! It seems a little humor helped to get someone's
> attention, even though I'm not sure you fully appreciated it :-)
> 
> > you do know that an open source community doesn't work like this.
> 
> As I mentioned in my second post, I have interacted and made small contributions
> of code to the open source community several times in the past, and my
> experience this time around was atypical because I was having a hard time just
> getting someone to reply!
> 
> > If someone would be able to make anything out of your posting or has
> > experienced the same, they would have spoken.
> 
> Was it unreasonable to expect that someone would say: "Nobody is experiencing
> this kind of delay, maybe it's something in your setup"? Or even, "this is not
> the right forum for non-developers to ask for help, why don't you try such and
> such place?"

even if I use Bluetooth on a daily basis, I don't use any mouse or
keyboard devices anymore. So I have no idea on how many people are
actually using these. I used to travel with a lot of HID devices to just
be able to test and verify things, but I don't do that anymore. So I
wouldn't be of much help until I am back at home and have my device
library at my disposal (and bought new batteries).

Regards

Marcel

Re: Long delay to (re)connect a bluetooth mouse

[dcobra]

Hi Marcel:

> even if I use Bluetooth on a daily basis, I don't use any mouse or
> keyboard devices anymore. So I have no idea on how many people are
> actually using these.

I'm getting the impression they are not very popular! To me it seemed like a
clear advantage to use a mouse with my notebook's built-in bluetooth module
without needing a dongle.

> I used to travel with a lot of HID devices to just
> be able to test and verify things, but I don't do that anymore. So I
> wouldn't be of much help until I am back at home and have my device
> library at my disposal (and bought new batteries).

O.k., if you find the time to look into this, I installed hcidump (didn't know
about it until you mentioned it), and here's the output with the "-t" flag (any
others I should use?) during a mouse reconnection:


HCI sniffer - Bluetooth packet analyzer ver 1.42                       
device: hci0 snap_len: 1028 filter: 0xffffffff                         
1261183973.054875 > HCI Event: Connect Request (0x04) plen 10          
1261183973.054911 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
1261183973.062868 > HCI Event: Command Status (0x0f) plen 4                    
1261183973.255871 > HCI Event: Role Change (0x12) plen 8                       
1261183973.349870 > HCI Event: Connect Complete (0x03) plen 11                 
1261183973.349892 < HCI Command: Read Remote Supported Features (0x01|0x001b)
plen 2                                                                         
  
1261183973.351861 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7  

1261183973.351870 > ACL data: handle 42 flags 0x02 dlen 12                     

    L2CAP(s): Connect req: psm 17 scid 0x0060                                  

1261183973.351932 < ACL data: handle 42 flags 0x02 dlen 16                     

    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 1 status 0           

      Connection pending - No futher information available                     

1261183973.351937 < ACL data: handle 42 flags 0x02 dlen 10                     

    L2CAP(s): Info req: type 2                                                 

1261183973.358863 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183973.361860 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183973.363865 > HCI Event: Command Status (0x0f) plen 4                    

1261183973.363881 < HCI Command: Remote Name Request (0x01|0x0019) plen 10     

1261183973.373864 > HCI Event: Read Remote Supported Features (0x0b) plen 11   

1261183973.375857 > HCI Event: Command Status (0x0f) plen 4                    

1261183973.443867 > HCI Event: Remote Name Req Complete (0x07) plen 255        

1261183977.351019 < ACL data: handle 42 flags 0x02 dlen 16                     

    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 0 status 0           

      Connection successful                                                    

1261183977.361870 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.383875 > ACL data: handle 42 flags 0x02 dlen 16                     

    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4                        

      MTU 133                                                                  

1261183977.383896 < ACL data: handle 42 flags 0x02 dlen 18                     

    L2CAP(s): Config rsp: scid 0x0060 flags 0x00 result 0 clen 4               

      MTU 133                                                                  

1261183977.383901 < ACL data: handle 42 flags 0x02 dlen 12                     

    L2CAP(s): Config req: dcid 0x0060 flags 0x00 clen 0                        

1261183977.391870 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.393868 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.403870 > ACL data: handle 42 flags 0x02 dlen 17                     

1261183977.405872 > ACL data: handle 42 flags 0x01 dlen 1                      

    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4               

      MTU 133                                                                  

1261183977.407872 > ACL data: handle 42 flags 0x02 dlen 12                     

    L2CAP(s): Connect req: psm 19 scid 0x0061                                  

1261183977.407895 < ACL data: handle 42 flags 0x02 dlen 16                     

    L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0061 result 1 status 2           

      Connection pending - Authorization pending                               

1261183977.408042 < ACL data: handle 42 flags 0x02 dlen 16                     

    L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0061 result 0 status 0           

      Connection successful                                                    

1261183977.413868 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.415868 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.437867 > ACL data: handle 42 flags 0x02 dlen 16                     

    L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4                        

      MTU 133                                                                  

1261183977.437892 < ACL data: handle 42 flags 0x02 dlen 18                     

    L2CAP(s): Config rsp: scid 0x0061 flags 0x00 result 0 clen 4               

      MTU 133                                                                  

1261183977.437898 < ACL data: handle 42 flags 0x02 dlen 12                     

    L2CAP(s): Config req: dcid 0x0061 flags 0x00 clen 0                        

1261183977.443870 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.445866 > HCI Event: Number of Completed Packets (0x13) plen 5       

1261183977.459875 > ACL data: handle 42 flags 0x02 dlen 18                     

    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4               

      MTU 133                                                                  

1261183977.461865 > ACL data: handle 42 flags 0x02 dlen 14                     

    L2CAP(d): cid 0x0041 len 10 [psm 19]                                       

      HIDP: Data: Input report                                                 

1261183977.464114 < ACL data: handle 42 flags 0x02 dlen 11                     

    L2CAP(d): cid 0x0061 len 7 [psm 19]                                        

      HIDP: Data: Output report                                                

1261183977.464180 < ACL data: handle 42 flags 0x02 dlen 7                      

    L2CAP(d): cid 0x0061 len 3 [psm 19]                                        

      HIDP: Data: Output report                                                

1261183977.464223 < ACL data: handle 42 flags 0x02 dlen 7                      

    L2CAP(d): cid 0x0061 len 3 [psm 19]                                        

      HIDP: Data: Output report                                                

1261183977.464294 < ACL data: handle 42 flags 0x02 dlen 14                     

    L2CAP(d): cid 0x0061 len 10 [psm 19]                                       

      HIDP: Data: Output report                                                

1261183977.464335 < ACL data: handle 42 flags 0x02 dlen 8                      

    L2CAP(d): cid 0x0061 len 4 [psm 19]
      HIDP: Data: Output report
1261183977.464375 < ACL data: handle 42 flags 0x02 dlen 11
    L2CAP(d): cid 0x0061 len 7 [psm 19]
      HIDP: Data: Output report
1261183977.464416 < ACL data: handle 42 flags 0x02 dlen 7
    L2CAP(d): cid 0x0061 len 3 [psm 19]
      HIDP: Data: Output report
1261183977.464455 < ACL data: handle 42 flags 0x02 dlen 14
    L2CAP(d): cid 0x0061 len 10 [psm 19]
      HIDP: Data: Output report
1261183977.466860 > HCI Event: QoS Setup Complete (0x0d) plen 21
1261183977.471858 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.473858 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.476859 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.478862 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.480857 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183977.484866 > HCI Event: Mode Change (0x14) plen 6
1261183977.487865 > ACL data: handle 42 flags 0x02 dlen 11
    L2CAP(d): cid 0x0041 len 7 [psm 19]
      HIDP: Data: Input report
1261183977.697866 > ACL data: handle 42 flags 0x02 dlen 11
    L2CAP(d): cid 0x0041 len 7 [psm 19]
      HIDP: Data: Input report


This is all Greek to me. The whole process took 4.6 seconds (a little less than
the 5-6 seconds I had estimated without actually clocking it, but still
significantly longer than under Windows XP, where the mouse connects in under
one second every time). Most of the delay takes place between the "Remote Name
Req Complete" and reception of the next ACL data. Does that tell you
something?

As far as logs go, during reconnection the only lines that were logged into
/var/log/messages were (any other log files I should check?):


Dec 18 22:52:57 photon kernel: input: Targus Bluetooth Media Mouse for Notebook
as
/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/bluetooth/hci0/hci0:42/input14
Dec 18 22:52:57 photon kernel: generic-bluetooth 0005:0461:4B01.0004:
input,hidraw0: BLUETOOTH HID v1.08 Mouse [Targus Bluetooth Media Mouse for
Notebook] on 00:18:F3:8C:F7:73

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Hi everybody:

Following Marcel's hint, I used hcidump while the Bluetooth mouse was 
reconnecting and got the results below (here I pasted the dump just up 
to the point where the connection is established).

Could somebody take a quick look and say why there is a 4 second delay 
between the last two lines? Is bluez receiving the mouse name during 
that time? If that's what's causing the delay, is there a configuration 
option to disable requesting the name of a device whose name is already 
known because it was previously connected and is now just coming out of 
sleep mode?

I downloaded and looked into bluez source code, but it would take me 
weeks to begin to understand it. If anyone can give me a hint, I'd 
really appreciate it.

Regards,

Daniel


HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1261183973.054875 > HCI Event: Connect Request (0x04) plen 10
1261183973.054911 < HCI Command: Accept Connection Request (0x01|0x0009) 
plen 7
1261183973.062868 > HCI Event: Command Status (0x0f) plen 
4                   
1261183973.255871 > HCI Event: Role Change (0x12) plen 
8                      
1261183973.349870 > HCI Event: Connect Complete (0x03) plen 
11               
1261183973.349892 < HCI Command: Read Remote Supported Features 
(0x01|0x001b) plen 
2                                                                       
1261183973.351861 > HCI Event: Page Scan Repetition Mode Change (0x20) 
plen 7
1261183973.351870 > ACL data: handle 42 flags 0x02 dlen 
12                   
    L2CAP(s): Connect req: psm 17 scid 
0x0060                               
1261183973.351932 < ACL data: handle 42 flags 0x02 dlen 
16                    
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 1 status 
0         
      Connection pending - No futher information 
available                   
1261183973.351937 < ACL data: handle 42 flags 0x02 dlen 
10                   
    L2CAP(s): Info req: type 
2                                               
1261183973.358863 > HCI Event: Number of Completed Packets (0x13) plen 
5      
1261183973.361860 > HCI Event: Number of Completed Packets (0x13) plen 
5      
1261183973.363865 > HCI Event: Command Status (0x0f) plen 
4                   
1261183973.363881 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1261183973.373864 > HCI Event: Read Remote Supported Features (0x0b) plen 11
1261183973.375857 > HCI Event: Command Status (0x0f) plen 
4                  
1261183973.443867 > HCI Event: Remote Name Req Complete (0x07) plen 
255     
1261183977.351019 < ACL data: handle 42 flags 0x02 dlen 
16                  
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 0 status 
0        
      Connection successful
[...]

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Sorry, Thunderbird is not handling the line breaks correctly. Here goes 
the hcidump again, hopefully correctly formatted this time.


HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1261183973.054875 > HCI Event: Connect Request (0x04) plen 10
1261183973.054911 < HCI Command: Accept Connection Request (0x01|0x0009) 
plen 7
1261183973.062868 > HCI Event: Command Status (0x0f) plen 4
1261183973.255871 > HCI Event: Role Change (0x12) plen 8
1261183973.349870 > HCI Event: Connect Complete (0x03) plen 11
1261183973.349892 < HCI Command: Read Remote Supported Features 
(0x01|0x001b) plen 2
1261183973.351861 > HCI Event: Page Scan Repetition Mode Change (0x20) 
plen 7
1261183973.351870 > ACL data: handle 42 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x0060
1261183973.351932 < ACL data: handle 42 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 1 status 0
      Connection pending - No futher information available
1261183973.351937 < ACL data: handle 42 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
1261183973.358863 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183973.361860 > HCI Event: Number of Completed Packets (0x13) plen 5
1261183973.363865 > HCI Event: Command Status (0x0f) plen 4
1261183973.363881 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
1261183973.373864 > HCI Event: Read Remote Supported Features (0x0b) 
plen 11
1261183973.375857 > HCI Event: Command Status (0x0f) plen 4
1261183973.443867 > HCI Event: Remote Name Req Complete (0x07) plen 255
1261183977.351019 < ACL data: handle 42 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0060 result 0 status 0
      Connection successful
[...]

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Hi Venu:

Thanks for replying.

Indeed, the reconnection is always successful, and, once it reconnects, 
the mouse works well, without any lag or other issues. The whole problem 
is the 4 second delay that happens during reconnection (see the last two 
timestamps in the hicdump), making the overall process take about 5 
seconds, which is a lot to wait every time you need to awake the mouse 
from sleep mode.

Since the delay takes place right after the remote name request, I 
wonder if that may have something to do with it, and if a solution might 
be to not request again the name of a device that was previously 
connected, and is merely coming out of sleep mode. (This is just a 
guess, as I am not familiar with the Bluetooth protocol.) If you can 
suggest how I may provide more information that would help ascertain the 
cause of the delay (other hcidump flags, perhaps?), please let me know.

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

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

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

O.k., Venu:

I'll reverse the order of your suggestions and try getting the HCI trace 
for Windows first. As you say, comparing it to the bluez trace will 
probably throw more light into the reason for the difference in 
performance and will help make clear whether changing the code is the 
way to go. I'll post the results later.

Regards,

Daniel

P.S.: Folks, if this discussion is not appropriate for this mailing 
list, please let me know and I will continue talking to Venu privately.

Citando venu:
> Hi
>
> I work on the bluetooth protocol, but I have not worked on Bluez stack 
> at all. I have worked/working on existing protocol stack for 
> semiconductor company. When I look at the HCI Commands log, I donot 
> see any HCI Command Remote Name request, for getting the remote 
> features, I see that hci command for reading remote name request being 
> sent directly to the host. Ours is a PC Solution which has USB Transport.
>
> Even to follow, your suggestion you would need to modify the HID 
> Profile stack to effect that. 
>
> But if you can get HCI Logs for windows for your case and compare it , 
> it would throw light what/where the problem could be.
>
> Cheers,
> Venu

Re: Long delay to (re)connect a bluetooth mouse

[Stefan Seyfried]

On Fri, 18 Dec 2009 14:58:31 -0800
Marcel Holtmann <marcel@holtmann.org> wrote:

> even if I use Bluetooth on a daily basis, I don't use any mouse or
> keyboard devices anymore. So I have no idea on how many people are
> actually using these.

I'm still using it occasionally at home (when not sitting on the sofa
with my notebook ;) and for the last few years they worked fine
(actually since we worked out the reconnect problem of the
Logitech mx1000, which looked similar, but probably was not).

My collection of two bluetooth mice still work fine and reconnect
quickly IIRC, but I will check this evening.

David, "every time I bring the mouse out of sleep mode", does this mean
the mouse went to sleep, you click the button (or move the mouse) and
it takes 5 seconds to reconnect? If so, could you try if it makes a
difference if you switch off the mouse instead? (wait until it falls
asleep, then switch off and on and check if it reconnects faster. Might
not be easy if this is a mouse that wakes up on movement, then you
probably need to lay it upside down until it sleeps).

> wouldn't be of much help until I am back at home and have my device
> library at my disposal (and bought new batteries).

I can recommend eneloop rechargeables for BT HID devices ;)
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Re: Long delay to (re)connect a bluetooth mouse

[venu]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

Hi Stefan,

Here is what happens with mouse,

1. When you use the mouse, they are in active mode, and after that they go
to sniff mode.
2. Now if continue not using mouse eventually it will disconnect (when it
disconnects depends on the sniff Interval, and sniff timeout).
3. When the mouse transitions to Sniff Mode from Active mode one would see
Mode change event along with Sniff Parameters which i told you about.
4. Now only after disconnect will you observe that the hid reconnects.

Please read section 8.7 in baseband specification of Bluetooth specs which
will throw more light into question which you are posing i.e. if you have
access to it.

Or else I can share it with you.

Cheers,
Venu

On Wed, Dec 23, 2009 at 9:18 PM, Stefan Seyfried <
stefan.seyfried@googlemail.com> wrote:

> On Fri, 18 Dec 2009 14:58:31 -0800
> Marcel Holtmann <marcel@holtmann.org> wrote:
>
> > even if I use Bluetooth on a daily basis, I don't use any mouse or
> > keyboard devices anymore. So I have no idea on how many people are
> > actually using these.
>
> I'm still using it occasionally at home (when not sitting on the sofa
> with my notebook ;) and for the last few years they worked fine
> (actually since we worked out the reconnect problem of the
> Logitech mx1000, which looked similar, but probably was not).
>
> My collection of two bluetooth mice still work fine and reconnect
> quickly IIRC, but I will check this evening.
>
> David, "every time I bring the mouse out of sleep mode", does this mean
> the mouse went to sleep, you click the button (or move the mouse) and
> it takes 5 seconds to reconnect? If so, could you try if it makes a
> difference if you switch off the mouse instead? (wait until it falls
> asleep, then switch off and on and check if it reconnects faster. Might
> not be easy if this is a mouse that wakes up on movement, then you
> probably need to lay it upside down until it sleeps).
>
> > wouldn't be of much help until I am back at home and have my device
> > library at my disposal (and bought new batteries).
>
> I can recommend eneloop rechargeables for BT HID devices ;)
> --
> Stefan Seyfried
>
> "Any ideas, John?"
> "Well, surrounding them's out."
> --
> 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
>



-- 
- J. Venumadhav

[-- Attachment #2: Type: text/html, Size: 3322 bytes --]

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Hi Stefan:

> David, "every time I bring the mouse out of sleep mode", does this mean
> the mouse went to sleep, you click the button (or move the mouse) and
> it takes 5 seconds to reconnect? If so, could you try if it makes a
> difference if you switch off the mouse instead? (wait until it falls
> asleep, then switch off and on and check if it reconnects faster. Might
> not be easy if this is a mouse that wakes up on movement, then you
> probably need to lay it upside down until it sleeps).
>   

If I don't use the mouse for some time (I haven't clocked it, but it is 
probably some 5 to 10 minutes), it goes into what I assume is sleep 
mode, i.e., the cursor stops responding to mouse movements. It only 
reconnects if I press a button, but it takes about 5 seconds for the 
cursor to start tracking the mouse movements again. Switching the mouse 
off, then on while it is connected has the same effect as bringing it 
out of sleep mode: it takes 5 seconds to start working again. I haven't 
tried switching it off, then on while it is asleep, to see if it makes 
any difference (I don't have it here with me now, but I'll do this test 
tonight).

Venu's suggestion of comparing the HCI dumps of reconnection under 
Windows and Linux will probably shed more light onto this problem. By 
the way, I had no luck googling for an hcidump equivalent for Windows. 
Can anybody suggest one?

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Stefan Seyfried]

Hi Daniel,

On Wed, 23 Dec 2009 15:53:09 -0200
"Daniel T. Cobra" <dcobra@videam.com.br> wrote:

> If I don't use the mouse for some time (I haven't clocked it, but it is 
> probably some 5 to 10 minutes), it goes into what I assume is sleep 
> mode, i.e., the cursor stops responding to mouse movements. It only 
> reconnects if I press a button,

Ok, that's clear.

> but it takes about 5 seconds for the 
> cursor to start tracking the mouse movements again. Switching the mouse 
> off, then on while it is connected has the same effect as bringing it 
> out of sleep mode: it takes 5 seconds to start working again. I haven't 
> tried switching it off, then on while it is asleep, to see if it makes 
> any difference (I don't have it here with me now, but I'll do this test 
> tonight).

No, it probably won't make a difference. Additionally, the bug I
remembered (where it would have made a difference) was different: the
mouse did not reconnect at all, unless it was completely disconnected
by either replugging the dongle or switching the mouse off and on. And
that bug is fixed since years anyway ;)

For the record: I tried the same (waiting until the mouse falls asleep
then pressing a button to reconnect) on an Acer Bluetooth Mouse and it
immediately reconnected and worked, in definitely under one second.
So it seems it is something a little bit specific to your device (I'm
not saying the mouse is doing something wrong, it might just be
behaving differently from what is expected by bluez, and this might
need to be fixed in bluez).

> Venu's suggestion of comparing the HCI dumps of reconnection under 
> Windows and Linux will probably shed more light onto this problem.

Yes, probably. If this does not help, we could try to compare the dumps
of your mouse and mine.

> By 
> the way, I had no luck googling for an hcidump equivalent for Windows. 
> Can anybody suggest one?

I have no idea, sorry.

Good luck ;)

	seife
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Hi Stefan:

I'm back from the holidays.

Since I was not able to find a free hcidump equivalent for Windows, I 
think we could at least compare the dumps for your mouse and mine, as 
you suggested. Could you please post yours (with timestamps)?

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Stefan Seyfried]

On Mon, 04 Jan 2010 16:48:54 -0200
"Daniel T. Cobra" <dcobra@videam.com.br> wrote:

> Hi Stefan:
> 
> I'm back from the holidays.
> 
> Since I was not able to find a free hcidump equivalent for Windows, I 
> think we could at least compare the dumps for your mouse and mine, as 
> you suggested. Could you please post yours (with timestamps)?

Sure. Here it is. I have put the mouse away at 11:21:27.262588 and
clicked on it at ~ 11:36:50.

HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
2010-01-05 11:21:24.021089 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 ed 05 00                                 ......
2010-01-05 11:21:24.140076 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 e6 06 00                                 ......
2010-01-05 11:21:24.141054 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 f0 03 00                                 ......
2010-01-05 11:21:24.143056 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x00 interval 0
    Mode: Active
2010-01-05 11:21:24.174052 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x02 interval 20
    Mode: Sniff
2010-01-05 11:21:27.125620 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 47 f9 00                                 ...G..
2010-01-05 11:21:27.127603 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 00 ff 00                                 ......
2010-01-05 11:21:27.225596 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 01 00 00                                 ......
2010-01-05 11:21:27.250605 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 ff 00 00                                 ......
2010-01-05 11:21:27.262588 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 0]
      0000: a1 02 00 01 00 00                                 ......
2010-01-05 11:21:37.289076 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x00 interval 0
    Mode: Active
2010-01-05 11:21:37.320067 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x02 interval 96
    Mode: Sniff
2010-01-05 11:31:37.161200 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
2010-01-05 11:31:37.161265 < ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
2010-01-05 11:31:37.162087 < ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.221188 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.221261 < ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.340173 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0041
2010-01-05 11:31:37.521139 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x00 interval 0
    Mode: Active
2010-01-05 11:31:37.538121 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 11 packets 3
2010-01-05 11:31:37.651115 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 11 reason 0x16
    Reason: Connection Terminated by Local Host
2010-01-05 11:36:50.103021 > HCI Event: Connect Request (0x04) plen 10
    bdaddr 00:0F:F6:60:44:0B class 0x002580 type ACL
2010-01-05 11:36:50.103084 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:0F:F6:60:44:0B role 0x00
    Role: Master
2010-01-05 11:36:50.107013 > HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
2010-01-05 11:36:50.278988 > HCI Event: Role Change (0x12) plen 8
    status 0x35 bdaddr 00:0F:F6:60:44:0B role 0x01
    Error: Role Switch Failed
2010-01-05 11:36:50.342981 > HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 11 bdaddr 00:0F:F6:60:44:0B type ACL encrypt 0x00
2010-01-05 11:36:50.343061 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
    handle 11
2010-01-05 11:36:50.346967 > HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-05 11:36:50.348966 > HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 11
    Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
2010-01-05 11:36:50.362865 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
    bdaddr 00:0F:F6:60:44:0B mode 2 clkoffset 0x0000
2010-01-05 11:36:50.364963 > HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-01-05 11:36:50.671937 > HCI Event: Role Change (0x12) plen 8
    status 0x35 bdaddr 00:0F:F6:60:44:0B role 0x01
    Error: Role Switch Failed
2010-01-05 11:36:50.773903 > HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:0F:F6:60:44:0B name 'Acer Bluetooth Wireless Mouse'
2010-01-05 11:36:51.503812 > HCI Event: Role Change (0x12) plen 8
    status 0x00 bdaddr 00:0F:F6:60:44:0B role 0x00
    Role: Master
2010-01-05 11:36:51.517810 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x0042
2010-01-05 11:36:51.517868 < ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 1 status 0
      Connection pending - No futher information available
2010-01-05 11:36:51.517876 < ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
2010-01-05 11:36:51.525808 > ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x0004
        Bi-directional QoS
2010-01-05 11:36:51.525853 < ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
      Connection successful
2010-01-05 11:36:51.530806 > ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 185 
2010-01-05 11:36:51.530854 < ACL data: handle 11 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0042 flags 0x00 result 0 clen 4
      MTU 185 
2010-01-05 11:36:51.530861 < ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Config req: dcid 0x0042 flags 0x00 clen 0
2010-01-05 11:36:51.534794 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 11 packets 4
2010-01-05 11:36:51.537805 > ACL data: handle 11 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
      MTU 185 
2010-01-05 11:36:51.538802 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 19 scid 0x0043
2010-01-05 11:36:51.538852 < ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0043 result 1 status 2
      Connection pending - Authorization pending
2010-01-05 11:36:51.539104 < ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0043 result 0 status 0
      Connection successful
2010-01-05 11:36:51.546803 > ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
      MTU 185 
2010-01-05 11:36:51.546849 < ACL data: handle 11 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0043 flags 0x00 result 0 clen 4
      MTU 185 
2010-01-05 11:36:51.546856 < ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Config req: dcid 0x0043 flags 0x00 clen 0
2010-01-05 11:36:51.557793 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 11 packets 4
2010-01-05 11:36:51.562794 > ACL data: handle 11 flags 0x02 dlen 18
    L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
      MTU 185 
2010-01-05 11:36:51.566781 > HCI Event: QoS Setup Complete (0x0d) plen 21
    status 0x00 handle 11 flags 0
    Service type: 1
    Token rate: 850
    Peak bandwith: 0
    Latency: 20000
    Delay variation: -1
2010-01-05 11:36:51.568787 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 19]
      HIDP: Data: Input report
      0000: 02 01 00 00 00                                    .....
2010-01-05 11:36:51.574819 > ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0041 len 6 [psm 19]
      HIDP: Data: Input report
      0000: 02 00 00 00 00                                    .....
2010-01-05 11:36:51.575497 < ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(d): cid 0x0043 len 6 [psm 19]
      HIDP: Data: Output report
      0000: 02 00 00 00 00                                    .....
2010-01-05 11:36:51.575514 < ACL data: handle 11 flags 0x02 dlen 7
    L2CAP(d): cid 0x0043 len 3 [psm 19]
      HIDP: Data: Output report
      0000: 03 00                                             ..
2010-01-05 11:36:51.581799 > ACL data: handle 11 flags 0x02 dlen 5
    L2CAP(d): cid 0x0041 len 1 [psm 19]
      HIDP: Handshake: Unsupported request
2010-01-05 11:36:51.583790 > ACL data: handle 11 flags 0x02 dlen 5
    L2CAP(d): cid 0x0041 len 1 [psm 19]
      HIDP: Handshake: Unsupported request
2010-01-05 11:36:51.594788 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x02 interval 20
    Mode: Sniff
2010-01-05 11:36:51.788764 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 11 packets 3

-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

For me, this is going to be a shot in the dark, not being familiar with 
the Bluetooth protocol, but could one of you developers please say if 
any of what follows makes sense?

Comparing the hci dumps from my mouse's reconnection and Stefan's, I am 
suspicious of the first line below:

[...]                        
2010-01-08 00:15:03.136170 < ACL data: handle 42 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-08 00:15:03.144103 < HCI Command: Remote Name Request 
(0x01|0x0019) plen 10
    bdaddr 00:16:38:E2:A5:57 mode 2 clkoffset 0x0000
2010-01-08 00:15:03.146089 > HCI Event: Number of Completed Packets 
(0x13) plen 5           
    handle 42 packets 2
2010-01-08 00:15:03.149092 > HCI Event: Read Remote Supported Features 
(0x0b) plen 11       
    status 0x00 handle 42
    Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
2010-01-08 00:15:03.155089 > HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
2010-01-08 00:15:03.227093 > HCI Event: Remote Name Req Complete (0x07) 
plen 255
    status 0x00 bdaddr 00:16:38:E2:A5:57 name 'Targus Bluetooth Media 
Mouse for Notebook'
2010-01-08 00:15:07.135253 < ACL data: handle 42 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
      Connection successful
[...]

In Stefan's hci dump we have:

[...]
2010-01-05 11:36:51.517876 < ACL data: handle 11 flags 0x02 dlen 10
    L2CAP(s): Info req: type 2
2010-01-05 11:36:51.525808 > ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Info rsp: type 2 result 0
      Extended feature mask 0x0004
        Bi-directional QoS
2010-01-05 11:36:51.525853 < ACL data: handle 11 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
      Connection successful
[...]

What is happening here? Is bluez making a request to read the device's 
extended features and Stefan's mouse replies while mine doesn't (and the 
4 sec delay I experience is bluez waiting for the reply until it times out)?

If it helps, here's the output of "hcitool info" for my mouse:

Requesting information ...
        BD Address:  00:16:38:A2:C5:56
        Device Name: Targus Bluetooth Media Mouse for Notebook
        LMP Version: 1.1 (0x1) LMP Subversion: 0x100
        Manufacturer: Broadcom Corporation (15)
        Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
                <encryption> <slot offset> <timing accuracy> <role switch>
                <sniff mode> <RSSI> <power control> <enhanced iscan>
                <interlaced pscan> <AFH cap. slave> <AFH cap. master>

So, am I going in the right direction or am I totally off the mark? I'd 
really appreciate some comment from you guys who know how this works.

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Stefan Seyfried]

On Wed, 03 Feb 2010 09:44:36 -0200
"Daniel T. Cobra" <dcobra@videam.com.br> wrote:

> For me, this is going to be a shot in the dark, not being familiar with 
> the Bluetooth protocol, but could one of you developers please say if 
> any of what follows makes sense?

[Disclaimer: I'm neither a bluez develper, nor am I familiar with the
 protocols etc ;)]

Yee, I think this makes sense. Maybe we can make bluez just cache the
data instead of re-requesting it at wakeup (I'm not sure if it should
do that actually, because the spec says so, or if the mouse just has a
broken implementation and we just should do it for convenience). After
all I don't expect the extended features to change all the time while
the mouse is asleep ;)
> 
> Comparing the hci dumps from my mouse's reconnection and Stefan's, I am 
> suspicious of the first line below:
> 
> [...]                        
> 2010-01-08 00:15:03.136170 < ACL data: handle 42 flags 0x02 dlen 10
>     L2CAP(s): Info req: type 2
> 2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
>     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> 2010-01-08 00:15:03.144103 < HCI Command: Remote Name Request 
> (0x01|0x0019) plen 10
>     bdaddr 00:16:38:E2:A5:57 mode 2 clkoffset 0x0000
> 2010-01-08 00:15:03.146089 > HCI Event: Number of Completed Packets 
> (0x13) plen 5           
>     handle 42 packets 2
> 2010-01-08 00:15:03.149092 > HCI Event: Read Remote Supported Features 
> (0x0b) plen 11       
>     status 0x00 handle 42
>     Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
> 2010-01-08 00:15:03.155089 > HCI Event: Command Status (0x0f) plen 4
>     Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> 2010-01-08 00:15:03.227093 > HCI Event: Remote Name Req Complete (0x07) 
> plen 255
>     status 0x00 bdaddr 00:16:38:E2:A5:57 name 'Targus Bluetooth Media 
> Mouse for Notebook'
> 2010-01-08 00:15:07.135253 < ACL data: handle 42 flags 0x02 dlen 16
>     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
>       Connection successful
> [...]
> 
> In Stefan's hci dump we have:
> 
> [...]
> 2010-01-05 11:36:51.517876 < ACL data: handle 11 flags 0x02 dlen 10
>     L2CAP(s): Info req: type 2
> 2010-01-05 11:36:51.525808 > ACL data: handle 11 flags 0x02 dlen 16
>     L2CAP(s): Info rsp: type 2 result 0
>       Extended feature mask 0x0004
>         Bi-directional QoS
> 2010-01-05 11:36:51.525853 < ACL data: handle 11 flags 0x02 dlen 16
>     L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0042 result 0 status 0
>       Connection successful
> [...]
> 
> What is happening here? Is bluez making a request to read the device's 
> extended features and Stefan's mouse replies while mine doesn't (and the 
> 4 sec delay I experience is bluez waiting for the reply until it times out)?
> 
> If it helps, here's the output of "hcitool info" for my mouse:
> 
> Requesting information ...
>         BD Address:  00:16:38:A2:C5:56
>         Device Name: Targus Bluetooth Media Mouse for Notebook
>         LMP Version: 1.1 (0x1) LMP Subversion: 0x100
>         Manufacturer: Broadcom Corporation (15)
>         Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00
>                 <encryption> <slot offset> <timing accuracy> <role switch>
>                 <sniff mode> <RSSI> <power control> <enhanced iscan>
>                 <interlaced pscan> <AFH cap. slave> <AFH cap. master>
> 
> So, am I going in the right direction or am I totally off the mark? I'd 
> really appreciate some comment from you guys who know how this works.

I don't know how it works, but your conclusion seems logical to me.
Which, of course, says nothing about its correctness ;)

Have fun,

	seife
-- 
Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Re: Long delay to (re)connect a bluetooth mouse

[Marcel Holtmann]

Hi Daniel,

> For me, this is going to be a shot in the dark, not being familiar with 
> the Bluetooth protocol, but could one of you developers please say if 
> any of what follows makes sense?
> 
> Comparing the hci dumps from my mouse's reconnection and Stefan's, I am 
> suspicious of the first line below:
> 
> [...]                        
> 2010-01-08 00:15:03.136170 < ACL data: handle 42 flags 0x02 dlen 10
>     L2CAP(s): Info req: type 2
> 2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
>     Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1

I totally missed this command. Yes, you are on the right track. We have
a timeout for devices not responding to information request.

#define L2CAP_INFO_TIMEOUT      (4000)  /*  4 seconds */

Problem here is that information request is actually needed to determine
the features of the remote L2CAP stack.

Regards

Marcel

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Thanks, Marcel:

Great! It is starting to make sense. Next, let me ask two questions:

1) You say the information request is needed, but do you mean it is 
needed at every reconnection with the device or, as Stefan suggested, 
would it make sense to request it only when the connection is first 
established and cache the result?

2) Is there a way to know that the device does not support extended 
features, to avoid sending a request that is going to time out without a 
reply? In net/bluetooth/hci_event.c I found this:

1171                if (conn->state == BT_CONFIG) {
1172                        if (!ev->status && lmp_ssp_capable(hdev) &&
1173                                                lmp_ssp_capable(conn)) {
1174                                struct 
hci_cp_read_remote_ext_features cp;
1175                                cp.handle = ev->handle;
1176                                cp.page = 0x01;
1177                                hci_send_cmd(hdev,
1178                                        HCI_OP_READ_REMOTE_EXT_FEATURES,
1179                                                        sizeof(cp), 
&cp);
1180                        } else {
1181                                conn->state = BT_CONNECTED;
1182                                hci_proto_connect_cfm(conn, ev->status);
1183                                hci_conn_put(conn);
1184                        }
1185                }

Is this the right place to look? It seems SSP capability is used as a 
test for whether to read the device's extended features. Is this really 
the best way, or could there be a more suitable indicator of whether the 
device supports extended features, thus avoiding the timeout?

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Marcel Holtmann]

Hi Daniel,

> Great! It is starting to make sense. Next, let me ask two questions:
> 
> 1) You say the information request is needed, but do you mean it is 
> needed at every reconnection with the device or, as Stefan suggested, 
> would it make sense to request it only when the connection is first 
> established and cache the result?
> 
> 2) Is there a way to know that the device does not support extended 
> features, to avoid sending a request that is going to time out without a 
> reply? In net/bluetooth/hci_event.c I found this:
> 
> 1171                if (conn->state == BT_CONFIG) {
> 1172                        if (!ev->status && lmp_ssp_capable(hdev) &&
> 1173                                                lmp_ssp_capable(conn)) {
> 1174                                struct 
> hci_cp_read_remote_ext_features cp;
> 1175                                cp.handle = ev->handle;
> 1176                                cp.page = 0x01;
> 1177                                hci_send_cmd(hdev,
> 1178                                        HCI_OP_READ_REMOTE_EXT_FEATURES,
> 1179                                                        sizeof(cp), 
> &cp);
> 1180                        } else {
> 1181                                conn->state = BT_CONNECTED;
> 1182                                hci_proto_connect_cfm(conn, ev->status);
> 1183                                hci_conn_put(conn);
> 1184                        }
> 1185                }
> 
> Is this the right place to look? It seems SSP capability is used as a 
> test for whether to read the device's extended features. Is this really 
> the best way, or could there be a more suitable indicator of whether the 
> device supports extended features, thus avoiding the timeout?

that is the wrong place. You need to look into net/bluetooth/l2cap.c.
The LMP features are mandatory at all costs. Otherwise hell breaks loose
if you don't do the right.

Regards

Marcel

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Hi Marcel:

> that is the wrong place. You need to look into net/bluetooth/l2cap.c.
> The LMP features are mandatory at all costs. Otherwise hell breaks loose
> if you don't do the right.

I looked into l2cap.c but I'd need to know the protocol better to make 
sense of what's going on in there.

Basically, do you think the failure to reply to the L2CAP information 
request is a non-compliance to the protocol on the part of this 
particular mouse model, or does it implement an older version of the 
protocol, or something like that? (The delay does not happen under MS 
Windows, if it means anything.)

 From the hci dump, it seems the mouse replies to the HCI Read Remote 
Supported Features:

2010-01-08 00:15:03.144090 > HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
2010-01-08 00:15:03.144103 < HCI Command: Remote Name Request 
(0x01|0x0019) plen 10
    bdaddr 00:16:38:E2:A5:57 mode 2 clkoffset 0x0000
2010-01-08 00:15:03.146089 > HCI Event: Number of Completed Packets 
(0x13) plen 5
    handle 42 packets 2
2010-01-08 00:15:03.149092 > HCI Event: Read Remote Supported Features 
(0x0b) plen 11
    status 0x00 handle 42
    Features: 0xbc 0x02 0x04 0x28 0x08 0x08 0x00 0x00

Is this unrelated to the L2CAP information request? Why would one work 
and not the other? Perhaps one is related to the device's features and 
the other to the connection's features?

In short, can anything be done to avoid this L2CAP timeout on the 
information request (something that, in addition to solving my problem, 
would result in a small improvement to bluez, in terms of device 
compatibility), or should I just forget about it and get a new BT mouse? 
What do you think?

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Iain Hibbert]

On Wed, 3 Feb 2010, Daniel T. Cobra wrote:

> Basically, do you think the failure to reply to the L2CAP information
> request is a non-compliance to the protocol on the part of this
> particular mouse model, or does it implement an older version of the
> protocol, or something like that? (The delay does not happen under MS
> Windows, if it means anything.)

I think the mouse is non-compliant, as the L2CAP Information request has
been present since at least 1.1 of the specification which says that a
valid response should be sent.

Sending such a request is optional however, and probably the people who
wrote that mouse stack never tested it against anything that sent one.
Even if it didn't understand it, it should reply with a "command not
understood" message..

> From the hci dump, it seems the mouse replies to the HCI Read Remote
> Supported Features:

that is unrelated

regards,
iain

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Iain:

> I think the mouse is non-compliant, as the L2CAP Information request has
> been present since at least 1.1 of the specification which says that a
> valid response should be sent.
>
> Sending such a request is optional however, and probably the people who
> wrote that mouse stack never tested it against anything that sent one.
> Even if it didn't understand it, it should reply with a "command not
> understood" message..
>   

O.k., from what you say, this is a quirk of this particular mouse model 
and it is not justifiable to change bluez in any way to fix it. If this 
had become clear earlier on, I wouldn't even have wasted you guys' time 
with this problem!

One last question, though: would this L2CAP timeout happen if I use the 
BT module in HIDP mode, if the module supports it? I tried to do a test 
by setting HID2HCI_ENABLED to 0 in /etc/default/bluetooth (I'm using 
Debian), but I get this message from /etc/init.d/bluetooth saying this 
is deprecated and I should use a udev rule for that, so I'd have to look 
further into it to find out how to do it.

Regards,

Daniel

Re: Long delay to (re)connect a bluetooth mouse

[Iain Hibbert]

On Thu, 4 Feb 2010, Daniel T. Cobra wrote:

> One last question, though: would this L2CAP timeout happen if I use the
> BT module in HIDP mode, if the module supports it? I tried to do a test
> by setting HID2HCI_ENABLED to 0 in /etc/default/bluetooth (I'm using
> Debian), but I get this message from /etc/init.d/bluetooth saying this
> is deprecated and I should use a udev rule for that, so I'd have to look
> further into it to find out how to do it.

>From what I understand of your request, no this L2CAP timeout would
probably not happen in that case. If you could switch the dongle into HID
mode then the Bluetooth protocol stack in use would be entirely inside the
dongle (and probably not send Info requests) and the Linux kernel would
only see a USB Mouse.

Unless you bought the dongle and mouse together as a pair though, it is
unlikely that the dongle can operate in HID mode..

regards,
iain

Re: Long delay to (re)connect a bluetooth mouse

[Daniel T. Cobra]

Iain:

> Unless you bought the dongle and mouse together as a pair though, it is
> unlikely that the dongle can operate in HID mode..
>   

Yes. I didn't know much about HIDP. Looking further into it, it became 
clear it doesn't apply in this case.

O.k., time to close this thread. Sorry to have bothered you guys with a 
problem that turned out to be a non-compliant device.

Many thanks to Marcel and all the others for trying to help and for all 
your work on bluez!

Goodbye,

Daniel