I have a Microsoft Arc mouse, Surface edition. This uses Bluetooth
Low Energy. Under dual boot Windows 8.1 I can connect this mouse, and
it will reconnect just fine if I turn the mouse off/on or Bluetooth
off/on.
In Fedora rawhide I have Bluez 5.18-2. I can pair this mouse just
fine, and it will continue to work until I turn the mouse off/on or
turn the computer off/on. Then it won't reconnect automatically. If
I go into bluetoothctl I can connect it again and it will then work.
I looked at bluetoothd and it seems to be doing the LE scan with:
bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
I look also at hcidump and I see:
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6
bdaddr 39:6D:E2:EC:17:37
> HCI Event: Command Complete (0x0e) plen 4
LE Set Random Address (0x08|0x0005) ncmd 1
status 0x00
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
type 0x01 (active)
interval 11.250ms window 11.250ms
own address: 0x01 (Random) 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 2
status 0x00
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
value 0x00 (scanning disabled)
filter duplicates 0x00 (disabled)
It doesn't seem to be finding anything? Is there something else I should try?
Thanks,
Ryan
Hi Ryan,
On Wed, Jun 25, 2014 at 5:27 AM, Ryan Press <[email protected]> wrote:
> I have a Microsoft Arc mouse, Surface edition. This uses Bluetooth
> Low Energy. Under dual boot Windows 8.1 I can connect this mouse, and
> it will reconnect just fine if I turn the mouse off/on or Bluetooth
> off/on.
>
> In Fedora rawhide I have Bluez 5.18-2. I can pair this mouse just
> fine, and it will continue to work until I turn the mouse off/on or
> turn the computer off/on. Then it won't reconnect automatically. If
> I go into bluetoothctl I can connect it again and it will then work.
>
> I looked at bluetoothd and it seems to be doing the LE scan with:
> bluetoothd[2356]: src/adapter.c:trigger_passive_scanning()
> bluetoothd[2356]: src/adapter.c:passive_scanning_complete() status 0x00
> bluetoothd[2356]: src/adapter.c:discovering_callback() hci0 type 6 discovering 1
>
> I look also at hcidump and I see:
> < HCI Command: LE Set Random Address (0x08|0x0005) plen 6
> bdaddr 39:6D:E2:EC:17:37
>> HCI Event: Command Complete (0x0e) plen 4
> LE Set Random Address (0x08|0x0005) ncmd 1
> status 0x00
> < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7
> type 0x01 (active)
> interval 11.250ms window 11.250ms
> own address: 0x01 (Random) 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 2
> status 0x00
> < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2
> value 0x00 (scanning disabled)
> filter duplicates 0x00 (disabled)
>
>
> It doesn't seem to be finding anything? Is there something else I should try?
Does it continue to scan or it scan a single time and stops, and have
you paired or just connect?
--
Luiz Augusto von Dentz
Hey Marcel,
On Tue, Jul 1, 2014 at 9:01 AM, Marcel Holtmann <[email protected]> wrote:
>>> the same applies to the HP mouse btw.
>>>
>>
>> Which HP Mouse are you referring to?
>>
>> An HP Mouse I have uses general connectable advertising when it wants
>> to reconnect.
>
> might want to check HCI Remote Version Information (via hcitool cmd) for that device. So what we found out today is that the Nordic based HID devices only do direct advertising. However my CSR based one does direct advertising first and if it times out, it falls back to undirected advertising.
>
I confirm this at my end.
Our CSR-based devices are the ones falling back to undirected, while
the Nordic ones are not.
In the Z8000 case at least there's a cute blue Connect button that
resets it back to undirected advertising.
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
On Thu, Jul 3, 2014 at 9:40 AM, <[email protected]> wrote:
> Sounds great. I really wanted the passive scan option as well.
> Would bluetooth-next work under 3.13?
>
Chrome OS is running bluetooth-next on as old a kernel as 3.8 -- we
have an unshipped backport all the way to 3.4 -- so yes, it's
definitely possible.
Scott
--
Scott James Remnant | Chrome OS Systems | [email protected] | Google
Hi David,
please don't top post on this mailing list.
> Sounds great. I really wanted the passive scan option as well.
> Would bluetooth-next work under 3.13?
you can try the backports tree. It should be possible to run it with 3.13 kernel.
> Ehrm, where can I read up a bit on the plans/news for bluetooth-next and more info on the ideas of user vs kernel space?
I think doc/mgmt-api.txt is pretty much updated on what new stuff is coming.
Regards
Marcel
Hi Marcel,
Sounds great. I really wanted the passive scan option as well.
Would bluetooth-next work under 3.13?
Ehrm, where can I read up a bit on the plans/news for bluetooth-next and more info on the ideas of user vs kernel space?
best David
On 03 Jul 2014, at 17:41, Marcel Holtmann <[email protected]> wrote:
> Hi David,
>
>> Somewhat hijacking this thread as we've been working on similar issues.
>> In the Nordic Semi HID code they by default set 5sec for the "FIRST_CONN_PARAMS_UPDATE_DELAY". As a temporary fix we just se this to 50msec to force a quicker re-connect.
>>
>> We're doing our pairing using mgmt, could there be something we do wrong on our end causing the CCCDs not being stored in our nrf51822, and/or on the linux side?
>
> try the latest bluetooth-next and bluetoothd. With the passive scanning and remembering of the connection parameters this should also be instant now. The advantage is that we start out with the correct parameters in the first place and thus the HID devices does not have to change them.
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi David,
> Somewhat hijacking this thread as we've been working on similar issues.
> In the Nordic Semi HID code they by default set 5sec for the "FIRST_CONN_PARAMS_UPDATE_DELAY". As a temporary fix we just se this to 50msec to force a quicker re-connect.
>
> We're doing our pairing using mgmt, could there be something we do wrong on our end causing the CCCDs not being stored in our nrf51822, and/or on the linux side?
try the latest bluetooth-next and bluetoothd. With the passive scanning and remembering of the connection parameters this should also be instant now. The advantage is that we start out with the correct parameters in the first place and thus the HID devices does not have to change them.
Regards
Marcel
Hi Ryan,
>>>>> I have one other question with it. When it first reconnects the mouse
>>>>> pointer is really jerky, like it's updating really slow. Then after a
>>>>> few seconds it is normal; in fact it is very responsive compared to my
>>>>> old Bluetooth mouse. With Windows 8.1 it reconnects lightning fast
>>>>> when I turn it on, and it is not jerky at first.
>>>>>
>>>> this is a kernel issue with not remembering the previous connection parameters. What you see is that we start connecting with the default values and then the slave (the mouse) will correct us and tell us what connection parameters it needs. We accept them and actually change the LE link to use these parameters. However we end up forgetting them. So every time you connect this procedure keeps repeating itself.
>>>>
>>>> I fixed this as well, but for that you will need a bluetooth-next kernel where I enabled the management API for passive scanning and a modified bluetoothd that will then allow you a smooth experience. If the slave updates the connection parameters we remember them for devices using auto-connection. So once the connection is triggered via passive scanning the values will be remembered.
>>>>
>>>> At the moment, I have one minor issue with the re-connection within bluetoothd and once that is fixed this should be pretty instant.
>>>
>>>
>>> Okay, great, glad to hear that you're already on it. I'm really
>>> looking forward to the seamless Bluetooth experience on Linux! When
>>> everything is ready and in the master branch let me know and I will
>>> try them out.
>>
>> the current bluetooth-next tree and bluez.git should now make this work smoothly. The first connection after starting bluetoothd will still use the wrong connection parameters, but all future ones will be snappy.
>
> I have installed bluetooth-next and bluez git. I had to merge with
> rc3 because rc1 wouldn't boot on my machine for some other reason. At
> first I had rfkill soft blocked when resuming from standby but then I
> pulled again and it fixed it. I saw Johan made a commit about blocked
> devices maybe that was it.
>
> So it works really well! Connections are instant and the mouse
> reconnects every time. The only time that connection is slow is the
> first time after a reboot, like you mention above; that's not really a
> problem.
even the first time after boot should be fast now. Fast in a sense that we use the correct Connection Parameters since we remember them. The one thing it still has to do is service discovery which does take a bit indeed.
On a side note, it seems that Microsoft released a -002 version of the mouse (check the product key under your battery) that will actually fall back to using ADV_IND instead of only doing ADV_DIRECT_IND.
Regards
Marcel
Hi Marcel,
On Tue, Jul 1, 2014 at 2:49 AM, Marcel Holtmann <[email protected]> wrote=
:
> Hi Ryan,
>
>>>> I have one other question with it. When it first reconnects the mouse
>>>> pointer is really jerky, like it's updating really slow. Then after a
>>>> few seconds it is normal; in fact it is very responsive compared to my
>>>> old Bluetooth mouse. With Windows 8.1 it reconnects lightning fast
>>>> when I turn it on, and it is not jerky at first.
>>>>
>>> this is a kernel issue with not remembering the previous connection par=
ameters. What you see is that we start connecting with the default values a=
nd then the slave (the mouse) will correct us and tell us what connection p=
arameters it needs. We accept them and actually change the LE link to use t=
hese parameters. However we end up forgetting them. So every time you conne=
ct this procedure keeps repeating itself.
>>>
>>> I fixed this as well, but for that you will need a bluetooth-next kerne=
l where I enabled the management API for passive scanning and a modified bl=
uetoothd that will then allow you a smooth experience. If the slave updates=
the connection parameters we remember them for devices using auto-connecti=
on. So once the connection is triggered via passive scanning the values wil=
l be remembered.
>>>
>>> At the moment, I have one minor issue with the re-connection within blu=
etoothd and once that is fixed this should be pretty instant.
>>
>>
>> Okay, great, glad to hear that you're already on it. I'm really
>> looking forward to the seamless Bluetooth experience on Linux! When
>> everything is ready and in the master branch let me know and I will
>> try them out.
>
> the current bluetooth-next tree and bluez.git should now make this work s=
moothly. The first connection after starting bluetoothd will still use the =
wrong connection parameters, but all future ones will be snappy.
>
> Regards
>
> Marcel
I have installed bluetooth-next and bluez git. I had to merge with
rc3 because rc1 wouldn't boot on my machine for some other reason. At
first I had rfkill soft blocked when resuming from standby but then I
pulled again and it fixed it. I saw Johan made a commit about blocked
devices maybe that was it.
So it works really well! Connections are instant and the mouse
reconnects every time. The only time that connection is slow is the
first time after a reboot, like you mention above; that's not really a
problem.
Thanks,
Ryan