diff options
| author | ortuno <ortuno@chromium.org> | 2016-02-25 18:15:43 -0800 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2016-02-26 02:16:39 +0000 |
| commit | 4958ca4f37d5e942b201e3fa533df825b0912c7d (patch) | |
| tree | f30e6b51c43ecf4a190d7ffdb17b69c42252c78a /third_party/libva | |
| parent | 0e6705d626f1604c1324a8b6d0c0b988ff32dbea (diff) | |
| download | chromium_src-4958ca4f37d5e942b201e3fa533df825b0912c7d.zip chromium_src-4958ca4f37d5e942b201e3fa533df825b0912c7d.tar.gz chromium_src-4958ca4f37d5e942b201e3fa533df825b0912c7d.tar.bz2 | |
bluetooth: Check if Object Manager is supported before initializing clients on linux
Two big changes:
1. On Linux, we check if Object Manager is supported before we try to initialize
the DBus clients. This solves the log spamming issue. On Chrome OS we initialize
the clients regardless of Object Manager support (we've always done this);
we keep the current behavior because by the time BluezDBusManager is
initialized Bluez is not ready and it appears as if Bluetooth is not supported
2. BluetoothAdapterBluez::CreateAdapter now takes a callback which runs after
we know whether Object Manager is supported or not and BluetoothAdapter is
initialized. Because of this change we fix all tests and users that assumed
BluetoothAdapterFactory::CreateAdapter was synchronous.
Design doc: https://docs.google.com/a/chromium.org/document/d/1xmMV7RsnEM6bejH-fYejAdE7q4BkucutuVFP7WI7mgY/edit?usp=sharing
BUG=583637
Review URL: https://codereview.chromium.org/1679983002
Cr-Commit-Position: refs/heads/master@{#377772}
Diffstat (limited to 'third_party/libva')
0 files changed, 0 insertions, 0 deletions