Wi-Fi Direct proposal for Chromium OS

[Rafael Antognolli]

Hi all,

I would like to propose adding support for a Wi-Fi Direct API for Chrome Web Store apps. The end goal is to have an API similar to the Android's Wi-Fi P2P one, as a Javascript extension and/or a NaCl extension.

If I understood correctly, the work necessary for doing so would be to:

 - Build wpa_supplicant with the required p2p support.

 - Add p2p support to shill, and expose a dbus API for that.

 - Add the required Chrome renderer/plugin classes that ultimately implement the API, and communicate through dbus to shill.

I'm not sure if I should start proposing the API already to Pepper or as a Javascript chromium extension, but since there's some work to be done on shill first, I thought I could start working on it even before getting that API set.

My questions are:

 1) Is this a desirable feature?

 2) Can I start working on it immediately, or should I get an approval on an API proposal document first? (and which group should I send it to?)

 2) Does it make sense to start looking at Mojo for the implementation, or is that too early?

Thank you for any help,

Rafael

[Jorge Lucangeli Obes]

On Thu, Sep 11, 2014 at 7:53 AM, Rafael Antognolli <antog...@gmail.com> wrote:

Hi all,

I would like to propose adding support for a Wi-Fi Direct API for Chrome Web Store apps. The end goal is to have an API similar to the Android's Wi-Fi P2P one, as a Javascript extension and/or a NaCl extension.

If I understood correctly, the work necessary for doing so would be to:

 - Build wpa_supplicant with the required p2p support.

 - Add p2p support to shill, and expose a dbus API for that.

 - Add the required Chrome renderer/plugin classes that ultimately implement the API, and communicate through dbus to shill.

I'm not sure if I should start proposing the API already to Pepper or as a Javascript chromium extension, but since there's some work to be done on shill first, I thought I could start working on it even before getting that API set.

I think it would be a better idea to define the API and get buy-in from the Apps & Extensions team before doing work in shill and wpa_supplicant. That way if the API ends up changing, you don't have to work on shill and wpa_supplicant twice.

Cheers,

Jorge

 

My questions are:

 1) Is this a desirable feature?

 2) Can I start working on it immediately, or should I get an approval on an API proposal document first? (and which group should I send it to?)

 2) Does it make sense to start looking at Mojo for the implementation, or is that too early?

Thank you for any help,

Rafael

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Scott James Remnant]

What kind of WiFi Direct devices are you aiming to support?

Starting with the use cases, and target devices, seems like the right place to start here - not the lowest level.

On Thu, Sep 11, 2014 at 7:53 AM, Rafael Antognolli <antog...@gmail.com> wrote:

--

[Rafael Antognolli]

About devices: support connection between chromebooks, as well as
connectivity to peripherals (printers, mice, keyboards, remote
control, headsets, speakers, displays).

Additional use case: support tethering between devices (chromebooks,
phones, tablets).

Does that sound reasonable?

--
Rafael Antognolli

[Scott James Remnant]

All of those kinds of devices are handled at the system level, and would not need Chrome APIs...

Can you give an example of the top 5 devices you can purchase off Amazon today that you would expect to be used?

[Rafael Antognolli]

On Thu, Sep 11, 2014 at 4:18 PM, Scott James Remnant
<key...@chromium.org> wrote:
> All of those kinds of devices are handled at the system level, and would not
> need Chrome APIs...

What do you mean? That such "functionality" would be implemented on a
system menu, just like ChromeOS' ethernet and wireless connection?

> Can you give an example of the top 5 devices you can purchase off Amazon
> today that you would expect to be used?

http://www.amazon.com/Samsung-SmartCam-Wireless-Monitoring-Setting/dp/B00H8TAM8Q/ref=sr_1_2?s=electronics&ie=UTF8&qid=1410463917&sr=1-2&keywords=wi-fi+direct
http://www.amazon.com/Wirelss-Direct-Dongle-Miracast-Sharing/dp/B00GD8GQBA/ref=sr_1_3?ie=UTF8&qid=1410463476&sr=8-3&keywords=wifi+direct
http://www.amazon.com/Epson-WorkForce-Smartphone-Compatible-C11CD16201/dp/B00JXLGEUC/ref=sr_1_7?ie=UTF8&qid=1410463476&sr=8-7&keywords=wifi+direct
http://www.amazon.com/Sony-BDPS3200-Blu-ray-Player-Wi-Fi/dp/B00HPMCO4Q/ref=sr_1_15?s=electronics&ie=UTF8&qid=1410463917&sr=1-15&keywords=wi-fi+direct
http://www.amazon.com/LG-GOOGLE-D821-FACTORY-UNLOCKED/dp/B00GG63522/ref=sr_1_1?s=wireless&ie=UTF8&qid=undefined&sr=1-1&keywords=nexus

--
Rafael Antognolli

[Scott James Remnant]

On Thu, Sep 11, 2014 at 12:38 PM, Rafael Antognolli <antog...@gmail.com> wrote:

On Thu, Sep 11, 2014 at 4:18 PM, Scott James Remnant
<key...@chromium.org> wrote:
> All of those kinds of devices are handled at the system level, and would not
> need Chrome APIs...

What do you mean? That such "functionality" would be implemented on a
system menu, just like ChromeOS' ethernet and wireless connection?

No, such functionality is implemented in the Operating System - not Chrome. When you pair a Bluetooth keyboard, it's not a web store app, extension, JavaScript API, etc. handling the keyboard - it's the OS itself (the linux kernel, in fact)

 

> Can you give an example of the top 5 devices you can purchase off Amazon
> today that you would expect to be used?

http://www.amazon.com/Samsung-SmartCam-Wireless-Monitoring-Setting/dp/B00H8TAM8Q/ref=sr_1_2?s=electronics&ie=UTF8&qid=1410463917&sr=1-2&keywords=wi-fi+direct
http://www.amazon.com/Wirelss-Direct-Dongle-Miracast-Sharing/dp/B00GD8GQBA/ref=sr_1_3?ie=UTF8&qid=1410463476&sr=8-3&keywords=wifi+direct
http://www.amazon.com/Epson-WorkForce-Smartphone-Compatible-C11CD16201/dp/B00JXLGEUC/ref=sr_1_7?ie=UTF8&qid=1410463476&sr=8-7&keywords=wifi+direct
http://www.amazon.com/Sony-BDPS3200-Blu-ray-Player-Wi-Fi/dp/B00HPMCO4Q/ref=sr_1_15?s=electronics&ie=UTF8&qid=1410463917&sr=1-15&keywords=wi-fi+direct
http://www.amazon.com/LG-GOOGLE-D821-FACTORY-UNLOCKED/dp/B00GG63522/ref=sr_1_1?s=wireless&ie=UTF8&qid=undefined&sr=1-1&keywords=nexus

You listed the following device types - printers, mice, keyboards, remote control, headsets, speakers, displays

There's only one printer in that list, and that's already supported by Chrome OS via Cloud Print. None of the other types of devices are listed there?

This is what I mean by starting with the use case first, and working downwards from there.

[Rafael Antognolli]

On Thu, Sep 11, 2014 at 4:48 PM, Scott James Remnant

<key...@chromium.org> wrote:
> On Thu, Sep 11, 2014 at 12:38 PM, Rafael Antognolli <antog...@gmail.com>
> wrote:
>>
>> On Thu, Sep 11, 2014 at 4:18 PM, Scott James Remnant
>> <key...@chromium.org> wrote:
>> > All of those kinds of devices are handled at the system level, and would
>> > not
>> > need Chrome APIs...
>>
>> What do you mean? That such "functionality" would be implemented on a
>> system menu, just like ChromeOS' ethernet and wireless connection?
>>
>
> No, such functionality is implemented in the Operating System - not Chrome.
> When you pair a Bluetooth keyboard, it's not a web store app, extension,
> JavaScript API, etc. handling the keyboard - it's the OS itself (the linux
> kernel, in fact)

I know, but the functionality must be presented to the user, so he can
choose which device he is going to connect to. For the Bluetooth
example, there's a menu for managing devices.

Additionally, if this was totally handled by the OS, I don't see why
Android would expose such API to its apps.

>>
>> > Can you give an example of the top 5 devices you can purchase off Amazon
>> > today that you would expect to be used?
>>
>>
>> http://www.amazon.com/Samsung-SmartCam-Wireless-Monitoring-Setting/dp/B00H8TAM8Q/ref=sr_1_2?s=electronics&ie=UTF8&qid=1410463917&sr=1-2&keywords=wi-fi+direct
>>
>> http://www.amazon.com/Wirelss-Direct-Dongle-Miracast-Sharing/dp/B00GD8GQBA/ref=sr_1_3?ie=UTF8&qid=1410463476&sr=8-3&keywords=wifi+direct
>>
>> http://www.amazon.com/Epson-WorkForce-Smartphone-Compatible-C11CD16201/dp/B00JXLGEUC/ref=sr_1_7?ie=UTF8&qid=1410463476&sr=8-7&keywords=wifi+direct
>>
>> http://www.amazon.com/Sony-BDPS3200-Blu-ray-Player-Wi-Fi/dp/B00HPMCO4Q/ref=sr_1_15?s=electronics&ie=UTF8&qid=1410463917&sr=1-15&keywords=wi-fi+direct
>>
>> http://www.amazon.com/LG-GOOGLE-D821-FACTORY-UNLOCKED/dp/B00GG63522/ref=sr_1_1?s=wireless&ie=UTF8&qid=undefined&sr=1-1&keywords=nexus
>>
>
> You listed the following device types - printers, mice, keyboards, remote
> control, headsets, speakers, displays
>
> There's only one printer in that list, and that's already supported by
> Chrome OS via Cloud Print. None of the other types of devices are listed
> there?

OK, but you need the printer to be connected to the internet in order
to use Cloud Print, correct? With Wi-Fi direct, that wouldn't be
necessary.

Additionally, the "Wirelss Wifi Direct Dongle" fits under the
"display" type, by using Miracast streaming. Other examples of
display:
http://www.amazon.com/Miracast-Dongle-Android-Samsung-Smartphone/dp/B00EHJOLWS
http://www.amazon.com/Sony-BRAVIA-KDL55HX750-55-Inch-Internet/dp/B006U1VH64#productDetails

For a mice type:
http://www.amazon.com/HP-WiFi-Mouse/dp/B00556O4YC/ref=cm_cr_pr_product_top

Speaker (discontinued):
http://www.amazon.com/Pioneer-XW-SMA4-K-featuring-Discontinued-Manufacturer/dp/B00903HKXI

I'm sorry, I can't find so many devices available for it yet. Although
the technology is not that new, it doesn't seem that there are many
devices out there yet. Anyway, at least for now, I'm more interested
on video streaming.

--
Rafael Antognolli

[Scott James Remnant]

(snipping lots of context to keep the mail short)

On Thu, Sep 11, 2014 at 2:00 PM, Rafael Antognolli <antog...@gmail.com> wrote:

 

I know, but the functionality must be presented to the user, so he can
choose which device he is going to connect to. For the Bluetooth
example, there's a menu for managing devices.

Sure, but that's just UI/UX - that comes after the use case

 

Additionally, if this was totally handled by the OS, I don't see why
Android would expose such API to its apps.

Android and Chrome OS are designed very differently as Operating Systems, with different design goals and implementations.

 

> There's only one printer in that list, and that's already supported by
> Chrome OS via Cloud Print. None of the other types of devices are listed
> there?

OK, but you need the printer to be connected to the internet in order
to use Cloud Print, correct? With Wi-Fi direct, that wouldn't be
necessary.

Chrome OS itself has no native printing support - so you'd still have to go via the cloud to use Cloud Print anyway.

"Support WiFi Direct Printers" is certainly an interesting use case, but it comes after "Support USB Printers" probably ;-)

 

Additionally, the "Wirelss Wifi Direct Dongle" fits under the
"display" type, by using Miracast streaming. Other examples of
display:
http://www.amazon.com/Miracast-Dongle-Android-Samsung-Smartphone/dp/B00EHJOLWS
http://www.amazon.com/Sony-BRAVIA-KDL55HX750-55-Inch-Internet/dp/B006U1VH64#productDetails

"Support Miracast" is an interesting use case, that exercises the API approach - I imagine its implementation would look not unlike the Chromecast extension.

 

For a mice type:
http://www.amazon.com/HP-WiFi-Mouse/dp/B00556O4YC/ref=cm_cr_pr_product_top

Unless this mouse has changed since I last examined it, it's not actually WiFi Direct - it uses a separate Wi-Fi based technology driven from an HP-supplied Windows driver. 

 

Speaker (discontinued):
http://www.amazon.com/Pioneer-XW-SMA4-K-featuring-Discontinued-Manufacturer/dp/B00903HKXI

I'm sorry, I can't find so many devices available for it yet. Although
the technology is not that new, it doesn't seem that there are many
devices out there yet. Anyway, at least for now, I'm more interested
on video streaming.

Right - this is pretty much what happened when we investigated WiFi Direct - we just couldn't find any real devices out there for sale, Bluetooth Low Energy became far more widely adopted much faster, so that's where we focussed our efforts.

 

Video Streaming is a good place to start, is that always Miracast? If that's the case, that's where I'd start. Make your use case "support Miracast" instead of something more hand-wavy and work downwards from the needs of the extension and how that would be implemented - and that will make it clear what APIs you need, and what OS support.

[Rafael Antognolli]

On Thu, Sep 11, 2014 at 8:13 PM, Scott James Remnant
<key...@chromium.org> wrote:
> (snipping lots of context to keep the mail short)
>
> On Thu, Sep 11, 2014 at 2:00 PM, Rafael Antognolli <antog...@gmail.com>
> wrote:
>
>>
>> I know, but the functionality must be presented to the user, so he can
>> choose which device he is going to connect to. For the Bluetooth
>> example, there's a menu for managing devices.
>>
>
> Sure, but that's just UI/UX - that comes after the use case
>
>>
>> Additionally, if this was totally handled by the OS, I don't see why
>> Android would expose such API to its apps.
>>
>
> Android and Chrome OS are designed very differently as Operating Systems,
> with different design goals and implementations.

OK.

>> > There's only one printer in that list, and that's already supported by
>> > Chrome OS via Cloud Print. None of the other types of devices are listed
>> > there?
>>
>> OK, but you need the printer to be connected to the internet in order
>> to use Cloud Print, correct? With Wi-Fi direct, that wouldn't be
>> necessary.
>>
>
> Chrome OS itself has no native printing support - so you'd still have to go
> via the cloud to use Cloud Print anyway.
>
> "Support WiFi Direct Printers" is certainly an interesting use case, but it
> comes after "Support USB Printers" probably ;-)

OK, then I'll put that as a separate use case/proposal later, if
that's the case.

All right, I'll have to confirm that, then come back to you. Thanks
for the help anyway.

--
Rafael Antognolli

[Rafael Antognolli]

(snipping more context)

On Thu, Sep 11, 2014 at 8:13 PM, Scott James Remnant
<key...@chromium.org> wrote:
> Right - this is pretty much what happened when we investigated WiFi Direct -
> we just couldn't find any real devices out there for sale, Bluetooth Low
> Energy became far more widely adopted much faster, so that's where we
> focussed our efforts.
>
>
> Video Streaming is a good place to start, is that always Miracast? If that's
> the case, that's where I'd start. Make your use case "support Miracast"
> instead of something more hand-wavy and work downwards from the needs of the
> extension and how that would be implemented - and that will make it clear
> what APIs you need, and what OS support.

OK, then let me describe the use cases we have so far:

- Connect a chromebook to a display device, for video streaming with miracast.
- Connect two or more chromebooks, on a high density network, using
applications based on WebRTC. The Wi-Fi Direct network would offload
the network backbone.
- Connect two or more chromebooks, using an application that allows
file sharing/transfer. Same idea of offloading the network backbone.

The mentioned high density network would be a corporate network, or a
classroom network.

I agree that it's possible to have a specialized API for miracast
streaming, but having it generic enough to establish a local
connection between some machines/devices would allow the two other use
cases, as well as non-planned ones so far.

--
Rafael Antognolli

[Scott James Remnant]

Great, that should be a good starting point for you to put together a design doc from API down to the bottom of the implementation I guess?

[Chris Masone]

It sounds like all these needs are met by http://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-now-certifying-tunneled-direct-link-setup

This is something the platform should just do, and not something that should be exposed to the application layer. Someone would need to figure out which parts in our devices are capable of this and how to start submitting patches to enable it and test it appropriately.

[Scott James Remnant]

I wouldn't agree that TDLS is probably a better technology fit than WiFi Direct for the last two use cases.

The first use case at least has an argument for there being extant devices out there using WiFi Direct

[Scott James Remnant]

Ugh, I "WOULD" agree ;-)

[Chris Masone]

And we apparently already support TDLS as of 38 or so on a bunch of our devices where the network parts support it.

[Rafael Antognolli]

That's indeed very interesting! I just need to confirm that we have no
requirements such as the two last cases must be fulfilled even if no
AP is present.

Then, for the miracast case, would it be better to write an specific API for it?

--
Rafael Antognolli

[Chris Masone]

On Mon, Sep 15, 2014 at 3:47 PM, Rafael Antognolli <antog...@gmail.com> wrote:

That's indeed very interesting! I just need to confirm that we have no
requirements such as the two last cases must be fulfilled even if no
AP is present.

Then, for the miracast case, would it be better to write an specific API for it?

I think apps shouldn't care what screen sharing technology is used behind the scenes, so it wouldn't make sense to have a miracast-specific API. Your app should just initiate screen sharing via whatever mechanism already exists (hangouts and the ChromeCast extension can already do this) and then the system should figure out if it can/should avoid the AP for efficiency. Since we already support TDLS, I imagine one could build something on top of that right now. Then if Miracast support should ever come along it could basically be plugged in as a different implementation of screen sharing.

[Dominik]

(cc'ing Anton Vayvod, Mark A. Foltz)

Hi Scott,

On Friday, September 12, 2014 2:13:27 AM UTC+3, Scott wrote:

"Support Miracast" is an interesting use case, that exercises the API approach - I imagine its implementation would look not unlike the Chromecast extension.

 

In terms of use cases, I'd like to add that Miracast is one of the backend that we plan to use for the Presentation API web specification that we're working on together with your Google colleagues Mark A. Foltz and Anton Vayvod. Anton posted an intent to implement blink-dev: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/J0ToSdOQVP8

Presentation API is aimed at abstracting the display connection technology, making it easy for web pages to connect to displays independent of the transport.

So, in an attempt to summarize the thread and define a next step:

Would it sound okay if we develop a design document and implementation proposal, explaining what kind of API we would like to add to expose at least Miracast as a start?

Dominik

[Scott James Remnant]

On Mon, Sep 29, 2014 at 8:27 AM, Dominik <dominik....@intel.com> wrote:

So, in an attempt to summarize the thread and define a next step:

Would it sound okay if we develop a design document and implementation proposal, explaining what kind of API we would like to add to expose at least Miracast as a start?

Yup, make sure you take into account Chris's comments

Scott

[Chris Masone]

Yes, to reiterate...essentially, this API should by no means be exposed to the application layer, but it may make sense to have it exposed to the implementation of this Presentation API you're discussing.

I'd have a hard time evaluating an API that exposed Miracast support to the browser without also seeing how TDLS support is currently exposed and used, and how the proposed API fits in with that.

 

Scott

[Rafael Antognolli]

Hi Mark,

Thank you for pointing it out, that's where I'm planning to add the
P2P APIs too. I'm still doing some tests and figuring it all, but I
should come with some proposal and a proof of concept soon.

On Thu, Oct 2, 2014 at 6:58 PM, mark a. foltz <mfo...@google.com> wrote:
> Not sure of the context for this thread, but here's the current TDLS API in
> Chromium.
>
> https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/extensions/api/networking_private/networking_private_service_client.h&l=163
>
> We currently (optimistically) enable it for Cast streaming from CrOS devices
> to Chromecast.
>
> m.

--
Rafael Antognolli