Closed Bug 899014 Opened 12 years ago Closed 12 years ago

[Bluetooth][HID] HID dom bluetooth implementation

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

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.
Blocks: 880759
The patch implements HID under dom/bluetooth.
Attachment #784160 - Flags: review?(echou)
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.
Attachment #784160 - Flags: review?(echou) → review-
Changes: - handle runnable in Connect() - add comments for empty functions - revise nits
Attachment #784160 - Attachment is obsolete: true
Attachment #786204 - Flags: review?(echou)
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+
(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.
(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!
Attachment #786204 - Attachment is obsolete: true
Update patch to solve conflict on the latest m-c.
Attachment #788849 - Attachment is obsolete: true
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.

Attachment

General

Created:
Updated:
Size: