New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 644327 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 629707



Sign in to add a comment

mash dbus: Bluetooth / bluez support

Project Member Reported by jamescook@chromium.org, Sep 6 2016

Issue description

Currently the Chrome browser process talks to bluez over D-Bus.

bluez needs access from chrome and ash (and eventually app_shell).

In ash, most access is via ash::SystemTrayDelegate back into chrome. Some UI (for pairing) directly accesses //device/bluetooth.

In chrome, bluez is used for extension APIs chrome.bluetooth and chrome.bluetoothPrivate.

Bluetooth devices (keyboards, mouses) can generate input events, which will need to be routed to the mus window service.

Plan: Leave in chrome. Add mojo interface similar to bluetooth / bluetoothPrivate extension APIs for use by ash.

Feel free to file subtasks blocking this bug.

 
Labels: Proj-Mustash
Components: Internals>MUS

Comment 3 by st...@chromium.org, Mar 3 2017

Cc: r...@chromium.org

Comment 4 by st...@chromium.org, Mar 3 2017

Cc: -st...@chromium.org
Components: -Internals>MUS Internals>Services>WindowService
Components: -MUS
Components: -Internals>Services>WindowService Internals>Services>Ash
Labels: -Proj-Mustash-Mash
Labels: -Proj-Mustash-Mus-WS
Deprecating Proj-Mustash-Mus-WS label in favor of Components.
Cc: rcui@chromium.org
Cc: ortuno@chromium.org
Status: WontFix (was: Untriaged)
This should be a WontFix given that ortuno@ is now working on a Bluetooth Mojo service.

rkc, will ortuno's work include hosting that Bluetooth service in the ash process under mash, and changing chrome's Bluetooth access to use the mojo api?

I am not sure whether we'd host the service under Ash's process or Chrome's initially - but he will definitely be changing Ash's access to use the mojo API.

link to bug tracking the mojo api implementation: https://bugs.chromium.org/p/chromium/issues/detail?id=830893
If the service lives in the ash process there's no strong need to have code in ash use mojo. Code in //chrome would need to use mojo to talk to the service. You might ping stevenjb@, he's doing something similar for display configuration, which needs to be controlled by ash, webui in chrome settings and an extension API.

We aren't converting all the clients of the Bluetooth code over to use the service for a while - and the heavy-use clients live in Chrome. Hence it would be a lot more work if we hosted the service in ash than in Chrome.

Sign in to add a comment