This may involve user experience such that it may need some kind of formal review before any actual implementation. 

As a possible scenario, if a user has already a bluetooth mouse connected, plugging an external bluetooth adapter will disable the current bluetooth mouse if the built-in one is disabled/ignored; to name just one of the possible behaviors. I am not sure if this is what a user would expect? 

This is true. cc'ing Albert for his thoughts.

Should we create a USE flag that enables preferring external adapter?  For typical Chrome devices we will want to prefer the internal ones but for certain use cases an external one may be preferred.

The problem is that we don't really know when this may not be acceptable for even boards we know have mildly defective firmwares. For example, if someone is using a panther as a desktop Chromebox, they may not want the mouse to stop working, but a hotrod would almost definitely want to switch to the external adapter.

I don't think we will want to debug issues or support random external BT dongles and therefore we will want to enable this only for specific cases (e.g. hotrod) where a more controlled deployment is guaranteed.

We could initially just start with going through a USE flag and only enable this for hotrod devices. If other devices need this, in different situations, we can figure out a way to plumb this preference down then.

+PMs

I don't think this should be a flag. We should be consistent in behavior here.

Just thinking out loud...

If I plug a new device in, I expect it to work.  If it can't coexist with something internal, I expect either the internal thing to get turned off or to be asked.

There are a few cases to consider:
1: I didn't have any bluetooth devices configured already.
2: I already did.

Case 1 is easy. Just disable the internal hardware and enable the added one.

Case 2 is harder.

I'm thinking we pop up a dialog/notification that says something like "Hey! If you want to use this we'll have to turn off the internal bluetooth adapter and re-pair all of your devices."

The user can click through to confirm adding and then we disable the internal and launch the pairing UI.

We'd keep the old config around for the internal adapter. If the user removes the external adapter we'd pop a notification and re-enable the internal adapter (and its config)

We should probably talk more face to face to flesh it out.

Yes, lets talk.  We have an AVL for components for a good reason.

 Issue 634909  has been merged into this issue.

+1 on Albert's approach for both Case 1 and Case 2 and for talking.

Just writing some notes for when we talk:
I'm assuming that for Case 2, if the user disconnects the external hardware, the devices will be paired back with the internal device once it's enabled (assuming those devices did not re-pair with the external one during this time).

If that's the case, there isn't really a need for an extra notification upon disconnecting the external adapter, is there? It should just work :) 

 

 

To clarify, yes, with case 2, the devices that were paired with the internal adapter, will remain paired till they are re-paired with another adapter.

"If" we decide to switch to the external adapter, switching back to the internal adapter can again, cause the same disruptions as moving away from the internal adapter did. For example, any devices paired with the external adapter will suddenly stop working.


I would like to point out, we should probably create a separate bug to work out the user experience for a typical Chromebook case. This is currently urgently needed by hotrods, which have an internal adapter that doesn't seem to work with GATT server.


For Hotrods, we should blanket switch to an external adapter without any notification if one is plugged in. For regular Chromebooks and other Chromeboxes, we should continue this discussion in another thread and come up with an acceptable user experience.

Are we going to pick some specific adapter(s) to support?  We have a collection of them here, but not all of them work.  In the past I have been told that since we don't officially support external Bluetooth adapters, we shouldn't worry about them.

The complexity of testing a wide array of adapters against our many hardware versions would not be trivial.

+1 for picking a *SINGLE* adapter that is known to work.

omrilio@ can we get folks together today or tomorrow to figure out next steps?

Per our chat today:
For M54 we will switch the external adapter ONLY for Kiosk mode to support hotrod and other devices.

In the future we can look at supporting this for the general use-case if we get user requests.

Does this make sense?

Only for hotrods - we don't want to plumb this up to Chrome to detect if we're in Kiosk mode. If we are on a Hotrod, and not a regular Chromebox, we will prefer the external adapter over internal.

Also moving to M-55 as per our discussion. If this is needed earlier, please holler.

Miao or Joseph, could you take this on?

Can we at least add an experimental flag to allow users to bypass this "Only Hotrods" restriction like we did for https://chromium.googlesource.com/chromium/src/+/master/chrome/common/extensions/api/bluetooth_low_energy.idl#439 

Would it be out of the question to allow using both adapters?

So, you click on the Status Bar thing in the bottom-right
Then you click on "Bluetooth enabled" which normally shows you a list of connected devices, available devices and the "manage devices..." button.

BUT

How about instead of that, you see all the available BT adapters. Then, when you click on an adapter, you're shown a list of devices attached to THAT adapter, as well as available devices.

If that's not possible, why not let us choose which adapter to use, like we can do with audio devices. 

@James: Can you give us a strong use case for needing both adapters at the same time?

@fbeaufort: For 54, we want to avoid going to Chrome to make the adapter decision, since it will involve implementing a non-trivial amount of plumbing. Instead the purpose of this bug is to solve the problem only for hotrods. We will deal with requirements for non-hotrod devices as they come along.

@rkc as you can read http://forum.espruino.com/conversations/297684/, it looks like some users would love that Chrome picks the default adapter when there are multiple adapters.  

It looks like it could be as "simple" as using SetAdapter(object_paths[i]); where i is the index of the default adapter.

See https://chromium.googlesource.com/chromium/src/+/15b1f5307b13a30002693aa1907819c447db4954/device/bluetooth/bluez/bluetooth_adapter_bluez.cc#259

After talking to BlueZ folks in #bluez-users, it seems they're not willing to expose this "default" adapter property as "bluetoothd has no use for such a concept - it's a higher-level concept & policy"

In that case, what do you think of something like this?
Use the first powered adapter when there are multiples.
This would give an option to users to power down one adapter and power up the one they want. This is not optimal for sure but at least they would be able to use from Chrome the adapter they want.

if (adapters.length > 0) {

  var defaultAdapter = adapters[0];
 
  if (adapters.length > 1) {
    for (adapter in adapters) {
      if (adapter.powered === true ) {
        defaultAdapter = adapter;
        break;
      }
    }
  }

  setAdapter(defaultAdapter);
}

@fbeaufort: As snanda@ mentioned before, supporting external adapters in the general case is not something we're willing to invest in at the moment. We don't want to be chasing down random issues that happened because of a broken external adapter.

BlueZ should always use the internal adapter - since that the adapter 'Chrome OS' provides to the user, hence knows about and our team will be willing to support. Unless there is an overpowering general purpose use case, I believe this is what the decision is.

This bug is *only* for hotrod devices. If we come up with a powerful use case for general devices, let's open a separate feature request centered around that use case.

As Rahul mentioned in #25, it is not our intention to support wide variety of adapters in the markets. This issue is limited to hotrod only for now. 

Here's a precision for Comment 24 from BlueZ folks:

'they're not willing to expose this "default" adapter property' is a bit misleading since that implies that there'd already exist something to consider exposing. If we were to expose this concept we'd first have to create it. Right now it doesn't exist in bluetoothd or D-Bus, but only as a bluetoothctl internal feature.

steel@, I get it ;) I've opened bug 679287 so that we can track users' enthusiast for this feature. Thank you.

For hotrods, we will not be implementing this feature.
We have the general purpose feature tracked in issue 679287.