1040437 - [B2G] [Bluetooth] Support SPP (Serial Port Profile)

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Makoto Kato [:m_kato]]

Some developers asks us whether B2G supports SPP...

Comment 1

[Ben Tian (inactive)]

B2G supports SPP but doesn't expose API for applications to access bluetooth sockets. However we will expose GATT client API in FxOS 2.2 to enable BLE-based profile development. What profile besides [1] do developers want to implement on classic bluetooth?

[1] https://wiki.mozilla.org/B2G/Bluetooth#Supported_Bluetooth_Profiles

Comment 2

[Makoto Kato [:m_kato]]

(In reply to Ben Tian [:btian] from comment #1)
> B2G supports SPP but doesn't expose API for applications to access bluetooth
> sockets. However we will expose GATT client API in FxOS 2.2 to enable
> BLE-based profile development. What profile besides [1] do developers want
> to implement on classic bluetooth?
> 
> [1] https://wiki.mozilla.org/B2G/Bluetooth#Supported_Bluetooth_Profiles

Ccing Eric.  Daisuke-san and :birtles discuss with Eric about this issue.

He investigates whether B2G can control RN42 board (http://www.microchip.com/wwwproducts/Devices.aspx?product=RN42).  This board supports SPP profile, but no way to control by B2G.

Also, I think, even if SPP support by Gecko, we need additional API such as web serial API, too.

Comment 3

[Luis Iván Cuende :luis]

Attachment: Just some small changes to make Gecko support the profile when it's introduced

Comment 4

[Luis Iván Cuende :luis]

I've been working for some time on this bug, and I'm specifically doing the following:

- Providing a sendSerialPort function on BluetoothAdapter to send data using Serial Port to another device

- Exposing a onserialdata callback to get data sent by others devices

Right now I just uploaded a small patch that provides some basic changes to
support the profile in the future. So it's not the profile, just some
flags and stuff to provide support for it.
Once it's reviewed I can make another patch with the file structure and
the skeleton functions. That way, when it works I could upload the
changes over existing files and not a huge changeset difficult to review.

I'm currently missing with some socket stuff but I think I may be able to have it working soon.

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I guess we need to expose RFCOMM channel or UUID parameter to JS, do you agree?

Comment 6

[Luis Iván Cuende :luis]

I understand the channel is secondary since the devices do a SDP search and agree on a common channel. What should be exposed in the future is the baud rate parameter, but right now I don't think it's important at all.

And what do you mean by UUID? The device address?

Comment 7

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

ni me, in case I forgot to answer your question.

Comment 8

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(In reply to Luis Iván Cuende from comment #6)
> I understand the channel is secondary since the devices do a SDP search and
> agree on a common channel. What should be exposed in the future is the baud
> rate parameter, but right now I don't think it's important at all.
> 
> And what do you mean by UUID? The device address?
The API shall have some interface to register UUID. For example, if you want to register your own RFCOMM server (say, the service name is RemoteBTRobotServer), and that will be something like:
Name: RemoteBTrobotServer
UUID: 00001101-0000-1000-8000-00805f9b34fb
RFCOMM Channel: 7

And your RFCOMM client interface shall have UUID or RFCOMM channel no as parameter to connect with.
Something like:
var bt_addr = B8F6B11A421C;
var channel = 7;
connect(bt_addr, channel);
Or you don't know the exact channel number of the remote but you only know that service uuid. BT stack will do sdp query using UUID for you automatically for that channel no.

var uuid = '00001101-0000-1000-8000-00805f9b34fb'
connect(bt_addr, uuid);

Comment 9

[Luis Iván Cuende :luis]

(In reply to Shawn Huang [:shawnjohnjr] from comment #8)
> And your RFCOMM client interface shall have UUID or RFCOMM channel no as
> parameter to connect with.

First of all, I wasn't keeping in mind the service UUID so that really helps development as it may be one of the causes of the profile failing to connect.

I have created another function in BluetoothSocket called ConnectSerialSocket, and it is actually a clone of ConnectSocket but using the Serial Port UUID.
I think the API should remain unchanged, so developers only need to call sendSerialPort(someData) and the UUID and channel stuff are done in the lower level. Right now my intent is to support only one connection, so I don't need to care too much about channels.

As always, thanks a lot for your insights!

Comment 10

[Thomas Zimmermann [:tzimmermann] [:tdz]]

(In reply to Luis Iván Cuende from comment #9)
> (In reply to Shawn Huang [:shawnjohnjr] from comment #8)
> > And your RFCOMM client interface shall have UUID or RFCOMM channel no as
> > parameter to connect with.
> 
> First of all, I wasn't keeping in mind the service UUID so that really helps
> development as it may be one of the causes of the profile failing to connect.
> 
> I have created another function in BluetoothSocket called
> ConnectSerialSocket, and it is actually a clone of ConnectSocket but using
> the Serial Port UUID.
> I think the API should remain unchanged, so developers only need to call
> sendSerialPort(someData) and the UUID and channel stuff are done in the
> lower level.

Nope. Please add the UUID as argument to |ConnectSocket| when you submit the patch for review.

Comment 11

[Thomas Zimmermann [:tzimmermann] [:tdz]]

Comment on attachment 8482241 [details] [diff] [review]
Just some small changes to make Gecko support the profile when it's introduced

Review of attachment 8482241 [details] [diff] [review]:
-----------------------------------------------------------------

Just some drive-by commenting ;)

::: dom/webidl/BluetoothAdapter.webidl
@@ +134,5 @@
> +  // Serial Port methods
> +  [NewObject, Throws]
> +  DOMRequest sendSerialPort(DOMString deviceAddress, DOMString data);
> +  [NewObject, Throws]
> +  DOMRequest sendSerialPort(DOMString deviceAddress, Blob data);

It feels wrong to have these methods here. Shouldn't there rather be a separate object for each serial connection? And BluetoothAdapter would have a method which returns instances.

Could the Bluetooth Serial API be made similar to the Serial WebAPI? [1]

[1] https://whatwg.github.io/serial/

Comment 12

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Comment on attachment 8482241 [details] [diff] [review]
Just some small changes to make Gecko support the profile when it's introduced

Review of attachment 8482241 [details] [diff] [review]:
-----------------------------------------------------------------

I have a few question on this patch.

::: dom/webidl/BluetoothAdapter.webidl
@@ +70,5 @@
>             attribute EventHandler   onrequestmediaplaystatus;
>  
> +  // Fired when serial port data is received
> +           attribute EventHandler   onserialportdata;
> +

Perhaps this can moved to BluetoothSerial?

@@ +131,2 @@
>    [NewObject, Throws]
>    DOMRequest confirmReceivingFile(DOMString deviceAddress, boolean confirmation);

Shouldn't we have a factory method to return the instance of something like BluetoothSerial object.
That factory method accepts three parameter (Bluetooth remote address, channel number, UUID) and return BluetoothSerial object? So SPP client side can easily handle read/write data.

We can also add server side factory method in BluetoothAdapter.

Comment 13

[Luis Iván Cuende :luis]

Replying to both of you,

That would work very well if the profile was to support multiple connections, but right now it is meant to support one connection at a time, thou I get we could make that so it's ready to support multiple connections without modifying the API.

So yeah, I agree.
But right now I'm focused on making a successful connection between two devices (B2G crashes and Bluetooth bugs are kind of slowing me). So I'll pick a version in which the Bluedroid v1 stack works without crashes, and I'll work over it until I have something that works well.

Comment 14

[Andrea Marchesini [:baku]]

Comment on attachment 8482241 [details] [diff] [review]
Just some small changes to make Gecko support the profile when it's introduced

Review of attachment 8482241 [details] [diff] [review]:
-----------------------------------------------------------------

It seems this patch is not finished. Correct?

::: content/base/src/nsGkAtomList.h
@@ +657,4 @@
>  GK_ATOM(ol, "ol")
>  GK_ATOM(omitXmlDeclaration, "omit-xml-declaration")
>  GK_ATOM(ona2dpstatuschanged, "ona2dpstatuschanged")
> +GK_ATOM(onserialportdata, "onserialportdata")

alphabetic order in GK_ATOMs.

::: dom/bluetooth/BluetoothAdapter.cpp
@@ +369,4 @@
>      NS_ENSURE_SUCCESS_VOID(rv);
>  
>      DispatchTrustedEvent(event);
> +  } else if (aData.name().EqualsLiteral(SERIALPORT_DATA_ID)) {

mmm... why this empty if() ?

@@ +861,5 @@
>  
>  already_AddRefed<DOMRequest>
> +BluetoothAdapter::SendSerialPort(const nsAString& aDeviceAddress,
> +                                 const nsAString& aData, ErrorResult& aRv)
> +{

You should throw an error if you return null.

@@ +868,5 @@
> +
> +already_AddRefed<DOMRequest>
> +BluetoothAdapter::SendSerialPort(const nsAString& aDeviceAddress,
> +                                 nsIDOMBlob* aData, ErrorResult& aRv)
> +{

You should throw an error if you return null.

Comment 15

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Comment on attachment 8482241 [details] [diff] [review]
Just some small changes to make Gecko support the profile when it's introduced

Andrea, can you look at this?

Comment 16

[Andrea Marchesini [:baku]]

Comment on attachment 8482241 [details] [diff] [review]
Just some small changes to make Gecko support the profile when it's introduced

Review of attachment 8482241 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, I already reviewed this code. I'm happy to review a second version of this patch.

Comment 17

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi Luis,
We still need to pass web api review, even you finished Gecko. So I think WebAPI review shall be proceed first.

Comment 18

[Brad Midgley]

Is this code in a form that I could try in os v3?

I've been doing robotics and I had to run an awful hack to make it work. With adb shell as root I ran a one-line webserver that passed codes to an rfcomm connection. Very gross.

I'd like to make this work cleanly so fxos can control eg lego mindstorm.