bluetooth: Chooser should scan for BLE devices only |
|||
Issue descriptionGoogle Chrome 54.0.2840.6 (Official Build) dev (64-bit) Platform 8743.4.0 (Official Build) dev-channel link What steps will reproduce the problem? (1) Go to https://googlechrome.github.io/samples/web-bluetooth/device-info.html (2) Scan for a BLE device that is not nearby (3) Bluetooth chooser shows it is scanning for 10sec What is the expected output? It should scan for 10 sec. What do you see instead? It is scanning only the first 5 seconds for BLE device and scanning for a Classic device the next 5 seconds as you can see in btmon logs. I know Web Bluetooth is supposed to work on BR/EDR devices as well if they support GATT but we don't for the moment. So it would be nice to simply start a BLE scan only. Bluetooth monitor ver 5.39 = Note: Linux version 3.8.11 (x86_64) 0.920239 = Note: Bluetooth subsystem version 2.21 0.920242 = New Index: A4:17:31:78:A6:04 (BR/EDR,USB,hci0) [hci0] 0.920245 = Open Index: A4:17:31:78:A6:04 [hci0] 0.920246 = Index Info: A4:17:31:78:A6:04 (Atheros Communications, Inc.) [hci0] 0.920247 < HCI Command: LE Set Random Address (0x08|0x0005) plen 6 [hci0] 1.579591 Address: 35:62:93:EF:12:8C (Non-Resolvable) > HCI Event: Command Complete (0x0e) plen 4 [hci0] 1.580683 LE Set Random Address (0x08|0x0005) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 [hci0] 1.580757 Type: Active (0x01) Interval: 11.250 msec (0x0012) Window: 11.250 msec (0x0012) Own address type: Random (0x01) Filter policy: Accept all advertisement (0x00) > HCI Event: Command Complete (0x0e) plen 4 [hci0] 1.581684 LE Set Scan Parameters (0x08|0x000b) ncmd 1 Status: Success (0x00) < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 [hci0] 1.581752 Scanning: Enabled (0x01) Filter duplicates: Enabled (0x01) > HCI Event: Command Complete (0x0e) plen 4 [hci0] 1.582682 LE Set Scan Enable (0x08|0x000c) ncmd 1 Status: Success (0x00) @ Discovering: 0x01 (7) // LE Scan is over after 5s... < HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 [hci0] 6.702141 Scanning: Disabled (0x00) Filter duplicates: Disabled (0x00) > HCI Event: Command Complete (0x0e) plen 4 [hci0] 6.703670 LE Set Scan Enable (0x08|0x000c) ncmd 1 Status: Success (0x00) < HCI Command: Inquiry (0x01|0x0001) plen 5 [hci0] 6.703836 Access code: 0x9e8b33 (General Inquiry) Length: 5.12s (0x04) Num responses: 0 > HCI Event: Vendor (0xff) plen 2 [hci0] 6.704653 80 00 .. > HCI Event: Command Status (0x0f) plen 4 [hci0] 6.705669 Inquiry (0x01|0x0001) ncmd 1 Status: Success (0x00) < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0 [hci0] 11.200093 > HCI Event: Vendor (0xff) plen 2 [hci0] 11.201614 80 01 .. > HCI Event: Command Complete (0x0e) plen 4 [hci0] 11.202612 Inquiry Cancel (0x01|0x0002) ncmd 1 Status: Success (0x00) @ Discovering: 0x00 (7) // But only now (5s later again) full scan is over...
,
Sep 8 2016
jyasskin, juncai, ortuno, scheib had a chat and agree we can scan LE only. We should do this just as an implementation detail in the mojo service implementation. We should document the reasons why in the chromium web bluetooth design docs (hmm, we do have a chromium.org design doc but perhaps better is in the blink/modules/bluetooth/README.md) why includes some of: - scanning performance impact - classic devices supporting GATT seem rare if at all and we don't expect to see them at all -- would need more impl to make them work - we don't want to make spec support a web page having control over LE, Classic, both.
,
Sep 9 2016
Just to be clear, does that also includes our implementations on Mac and Linux as well? Android does it already properly.
,
Sep 13 2016
re #1. I don't think there is much we can do here when doing a Dual Scan. We are not controlling the type of the scan directly it's bluez who's deciding to alternate between scans. re 3#. Yes, we will stop scanning and showing classic devices in the chooser. As a first step we will no longer do a Dual scan; we will only do a LE scan. Android works because we don't support classic devices there.
,
Sep 13 2016
To summarize what I've understood, there are two parts: 1. Doing a LE scan only: It is just a one line change in bluetooth_device_chooser_controller https://chromium.googlesource.com/chromium/src/+/e1c9629255c384301458c854d65e5a077ceb7a43/content/browser/bluetooth/bluetooth_device_chooser_controller.cc#152 2. Adding only LE devices to the chooser This involves adding the ability to distinguish between classic and LE devices. According to Bluez folks, we can simply look for Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) in the Bluetooth Device UUIDs list to know whether GATT is supported or not.
,
Sep 15 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/447f53595b1c768936bc38f37c77d8c497a519f3 commit 447f53595b1c768936bc38f37c77d8c497a519f3 Author: ortuno <ortuno@chromium.org> Date: Thu Sep 15 06:21:39 2016 bluetooth: Perform an LE scan only There isn't much support from platforms and devices for GATT over BR/EDR so to avoid confusing users and wasting power, perform a LE scan only. BUG= 643625 Review-Url: https://codereview.chromium.org/2339033003 Cr-Commit-Position: refs/heads/master@{#418792} [modify] https://crrev.com/447f53595b1c768936bc38f37c77d8c497a519f3/content/browser/bluetooth/bluetooth_device_chooser_controller.cc [modify] https://crrev.com/447f53595b1c768936bc38f37c77d8c497a519f3/third_party/WebKit/Source/modules/bluetooth/README.md
,
Sep 19 2016
This is fixed now that we initiate a LE-only scan. We still need to filter out classic devices for the chooser Issue 648120 |
|||
►
Sign in to add a comment |
|||
Comment 1 by fbeaufort@chromium.org
, Sep 2 2016