Closed
Bug 899014
Opened 12 years ago
Closed 12 years ago
[Bluetooth][HID] HID dom bluetooth implementation
Categories
(Firefox OS Graveyard :: Bluetooth, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: ben.tian, Assigned: ben.tian)
References
Details
Attachments
(1 file, 3 obsolete files)
This bug implements HID manager under dom/bluetooth and is part of bug 880759.
Assignee | ||
Comment 1•12 years ago
|
||
The patch implements HID under dom/bluetooth.
Attachment #784160 -
Flags: review?(echou)
Comment 2•12 years ago
|
||
Comment on attachment 784160 [details] [diff] [review]
Patch 1: v1: HID dom bluetooth implementation
Review of attachment 784160 [details] [diff] [review]:
-----------------------------------------------------------------
Hi Ben,
Besides these comments, you should also complete HID related implmentation in GetConnectedDevicePropertiesInternal().
Please ask me to review again when the patch is ready. Thanks.
::: dom/bluetooth/BluetoothHidManager.cpp
@@ +15,5 @@
> +#include "mozilla/dom/bluetooth/BluetoothTypes.h"
> +#include "mozilla/Services.h"
> +#include "mozilla/StaticPtr.h"
> +#include "nsIObserverService.h"
> +
super-nit: extra line
@@ +110,5 @@
> +{
> + MOZ_ASSERT(NS_IsMainThread());
> + MOZ_ASSERT(!aDeviceAddress.IsEmpty());
> +
> + if (sInShutdown) {
nit: you may want to use NS_ENSURE_FALSE(sInShutdown, false). Here and below.
@@ +159,5 @@
> + const BluetoothValue& value = arr[0].value();
> +
> + if (name.EqualsLiteral("Connected")) {
> + MOZ_ASSERT(value.type() == BluetoothValue::Tbool);
> + mConnected = value.get_bool();
I suggest that we can do "MOZ_ASSERT(mConnected != value.get_bool())" before assigning the new value to mConnected.
@@ +195,5 @@
> +void
> +BluetoothHidManager::OnGetServiceChannel(const nsAString& aDeviceAddress,
> + const nsAString& aServiceUuid,
> + int aChannel)
> +{
Whether we will implement this function or not, please add comment here to explain why this function is empty.
@@ +200,5 @@
> +}
> +
> +void
> +BluetoothHidManager::OnUpdateSdpRecords(const nsAString& aDeviceAddress)
> +{
Whether we will implement this function or not, please add comment here to explain why this function is empty.
::: dom/bluetooth/BluetoothHidManager.h
@@ +3,5 @@
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this file,
> + * You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +#ifndef mozilla_dom_bluetooth_BluetoothHidmanager_h__
Usually write in lower cases.
@@ +12,5 @@
> +
> +BEGIN_BLUETOOTH_NAMESPACE
> +
> +class BluetoothHidManagerObserver;
> +class BluetoothValue;
Seems not used.
@@ +30,5 @@
> + virtual void OnUpdateSdpRecords(const nsAString& aDeviceAddress) MOZ_OVERRIDE;
> + virtual void GetAddress(nsAString& aDeviceAddress) MOZ_OVERRIDE;
> + virtual bool IsConnected() MOZ_OVERRIDE;
> +
> + bool Connect(const nsAString& aDeviceAddress);
Connect() should also take runnable as a parameter. See the other comment.
::: dom/bluetooth/BluetoothService.h
@@ +297,5 @@
> + virtual nsresult
> + SendInputMessage(const nsAString& aDeviceAddresses,
> + const nsAString& aMessage) = 0;
> +
> +
super-nit: extra line
::: dom/bluetooth/linux/BluetoothDBusService.cpp
@@ +20,5 @@
> #include "BluetoothDBusService.h"
> #include "BluetoothA2dpManager.h"
> #include "BluetoothHfpManager.h"
> #include "BluetoothOppManager.h"
> +#include "BluetoothHidManager.h"
nit: alphabetic order, please.
@@ +2552,5 @@
> BluetoothOppManager* opp = BluetoothOppManager::Get();
> opp->Connect(aDeviceAddress, aRunnable);
> + } else if (aProfileId == BluetoothServiceClass::HID) {
> + BluetoothHidManager* hid = BluetoothHidManager::Get();
> + hid->Connect(aDeviceAddress);
We can't leave aRunnable without dealing with it.
Updated•12 years ago
|
Attachment #784160 -
Flags: review?(echou) → review-
Assignee | ||
Comment 3•12 years ago
|
||
Changes:
- handle runnable in Connect()
- add comments for empty functions
- revise nits
Attachment #784160 -
Attachment is obsolete: true
Attachment #786204 -
Flags: review?(echou)
Comment 4•12 years ago
|
||
Comment on attachment 786204 [details] [diff] [review]
Patch 1: v2: HID dom bluetooth implementation
Review of attachment 786204 [details] [diff] [review]:
-----------------------------------------------------------------
r=me with nits addressed.
::: dom/bluetooth/linux/BluetoothDBusService.cpp
@@ +1930,5 @@
> + DBusCallback callback;
> + if (aMessage.EqualsLiteral("Connect")) {
> + callback = GetVoidCallback;
> + } else if (aMessage.EqualsLiteral("Disconnect")) {
> + callback = InputDisconnectCallback;
This won't work since aRunnable is still not handled in the callback funciton InputDisconnectCallback().
Based on current implementation, I think GetVoidCallback could be the callback for Disconnect case as well.
@@ +1932,5 @@
> + callback = GetVoidCallback;
> + } else if (aMessage.EqualsLiteral("Disconnect")) {
> + callback = InputDisconnectCallback;
> + } else {
> + BT_WARNING("Unknown input message");
aRunnable still needs to be handled. (DispatchBluetoothReply)
Attachment #786204 -
Flags: review?(echou) → review+
Assignee | ||
Comment 5•12 years ago
|
||
(In reply to Eric Chou [:ericchou] [:echou] from comment #4)
> Comment on attachment 786204 [details] [diff] [review]
> Patch 1: v2: HID dom bluetooth implementation
> ::: dom/bluetooth/linux/BluetoothDBusService.cpp
> @@ +1930,5 @@
> > + DBusCallback callback;
> > + if (aMessage.EqualsLiteral("Connect")) {
> > + callback = GetVoidCallback;
> > + } else if (aMessage.EqualsLiteral("Disconnect")) {
> > + callback = InputDisconnectCallback;
>
> This won't work since aRunnable is still not handled in the callback
> funciton InputDisconnectCallback().
>
> Based on current implementation, I think GetVoidCallback could be the
> callback for Disconnect case as well.
For Disconnect case, SendInputMessage receives aRunnable=nullptr so InputDisconnectCallback doesn't need to handle the runnable. BluetoothDBusService doesn't pass the runnable into Disconnect() for all profile managers.
> @@ +1932,5 @@
> > + callback = GetVoidCallback;
> > + } else if (aMessage.EqualsLiteral("Disconnect")) {
> > + callback = InputDisconnectCallback;
> > + } else {
> > + BT_WARNING("Unknown input message");
>
> aRunnable still needs to be handled. (DispatchBluetoothReply)
I'll re-write here with moz assertion to avoid the 'else' case, since the parameters are internally assigned in BluetoothHidManager.
Comment 6•12 years ago
|
||
(In reply to Ben Tian [:btian] from comment #5)
> (In reply to Eric Chou [:ericchou] [:echou] from comment #4)
> > Comment on attachment 786204 [details] [diff] [review]
> > Patch 1: v2: HID dom bluetooth implementation
>
> > ::: dom/bluetooth/linux/BluetoothDBusService.cpp
> > @@ +1930,5 @@
> > > + DBusCallback callback;
> > > + if (aMessage.EqualsLiteral("Connect")) {
> > > + callback = GetVoidCallback;
> > > + } else if (aMessage.EqualsLiteral("Disconnect")) {
> > > + callback = InputDisconnectCallback;
> >
> > This won't work since aRunnable is still not handled in the callback
> > funciton InputDisconnectCallback().
> >
> > Based on current implementation, I think GetVoidCallback could be the
> > callback for Disconnect case as well.
> For Disconnect case, SendInputMessage receives aRunnable=nullptr so
> InputDisconnectCallback doesn't need to handle the runnable.
> BluetoothDBusService doesn't pass the runnable into Disconnect() for all
> profile managers.
>
Ah, I missed that. Thanks for clarifying that!
Assignee | ||
Comment 7•12 years ago
|
||
Attachment #786204 -
Attachment is obsolete: true
Assignee | ||
Comment 8•12 years ago
|
||
try server (build all): https://tbpl.mozilla.org/?tree=Try&rev=52e8da94ae3a
try server (unit tests): https://tbpl.mozilla.org/?tree=Try&rev=2e0bb6608f81
Assignee | ||
Comment 9•12 years ago
|
||
Update patch to solve conflict on the latest m-c.
Attachment #788849 -
Attachment is obsolete: true
Assignee | ||
Comment 10•12 years ago
|
||
try server link (build all):
https://tbpl.mozilla.org/?tree=Try&rev=c574ae8c9edf
try server link (unit test):
https://tbpl.mozilla.org/?tree=Try&rev=6bbceb70abc3
Comment 11•12 years ago
|
||
Comment 12•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•