1161874 - Add an entry point to trigger wifi display on B2G

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Wifi, defect)

Description

[Henry Chang [:hchang]]

We need an entry point for wifi display from web to mediaserver, which is responsible for maintaining a rtsp server. This bug will not decide what content
is going to show in the wifi display sink. It just provides an interface to start
a rtsp server in mediaserver via an simple binder call.

Comment 1

[Henry Chang [:hchang]]

Attachment: Bug1161874.patch

Comment 2

[Henry Chang [:hchang]]

Attachment: Bug1161874.patch

Comment 3

[Henry Chang [:hchang]]

Attachment: Bug1161874.patch

Comment 4

[Henry Chang [:hchang]]

Comment on attachment 8602485 [details] [diff] [review]
Bug1161874.patch

Hi Vincent,

Could you please help review this patch regarding the wifi part?
It's intended to provide an interface for gaia to start a wifi display
source service.

Hi mwu,

Could you please help review the change in AudioManager.cpp?
To support audio re-route while running wifi display,
we need to use AUDIO_DEVICE_OUT_REMOTE_SUBMIX to record
some of the channels to remote submix device. 

In WifiDisplayManager.cpp, the remote submix device will
be enabled/disabled when starting/ending a wifi display session.
The policy for what andio channels should be rerouted to 
remote submix device is controlled by "audio.r_submix.default.so",
which is not the realm of gecko.

REMOTE_SUBMIX is what mediaserver would implement wifi display
audio mirroring. The gonk code that uses remote submis device
is in [1]

Thanks!

[1] http://androidxref.com/4.4.4_r1/xref/frameworks/av/media/libstagefright/wifi-display/source/PlaybackSession.cpp#1062

Comment 5

[Michael Wu [:mwu]]

Comment on attachment 8602485 [details] [diff] [review]
Bug1161874.patch

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

r=me for AudioManager.cpp

Comment 6

[[:fabrice] Fabrice Desré]

Comment on attachment 8602485 [details] [diff] [review]
Bug1161874.patch

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

::: dom/wifi/WifiP2pWfdDevice.jsm
@@ +43,5 @@
> +    coupleSinkSupportAtSink: 'r',
> +    coupleSinkSupportAtSource: 'r',
> +    controlPort: 'r',
> +    maxThroughput: 'r'
> +  };

why do you need this __exposedProps__ ? this should not be used in new code anymore.

Comment 7

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8602485 [details] [diff] [review]
Bug1161874.patch

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

Glad to see this moving forward.
The implementation looks good for me overall.
Although the API is simple, but it's powerful, and triggers the RTSP server in the Android's media server and listen to remote peers to connect to the device. We need to have DOM peer and security review on the DOM API.

For the WifiDisplayManager.cpp, it uses binder IPC interface to communicate to Android's Wifi display implementation. We may abstract the interface here in the future in case we chose to interact with others Wifi display implementation(by our own maybe :D).

::: dom/webidl/MozWifiP2pManager.webidl
@@ +100,5 @@
>     */
>    DOMRequest setPairingConfirmation(boolean accepted, optional DOMString pin);
>  
> +  DOMRequest listenForRemoteDisplay();
> +

Please add the comments to explain function usage.

::: dom/wifi/DOMWifiP2pManager.js
@@ +313,5 @@
>  
> +  listenForRemoteDisplay: function() {
> +    let request = this.createRequest();
> +    this._sendMessageForRequest("WifiP2pManager:listenForRemoteDisplay", null, request);
> +    return request;

Can we support multiple clients to call listenForRemoteDisplay?
What could happen if we have system app and settings app calling this API simultaneously?

::: dom/wifi/WifiUtils.cpp
@@ +457,5 @@
>      aResult.mStatus = mImpl->do_wifi_stop_supplicant(0);
>    } else if (aOptions.mCmd.EqualsLiteral("connect_to_supplicant")) {
>      aResult.mStatus = mImpl->do_wifi_connect_to_supplicant(aInterface.get());
> +  } else if (aOptions.mCmd.EqualsLiteral("listen_for_remote_display")) {
> +    mozilla::listenForRemoteDisplay("0.0.0.0:7236");

The command implemented in WifiDisplayManager.cpp triggers the RTSP (Real time streaming protocol) Server running in the Android's media server process. I think we should limit the client by specify ip address for security concern.

Comment 8

[Henry Chang [:hchang]]

No longer working on this.

Comment 9

[BMO Automation]

Firefox OS is not being worked on