PPAPI: Make output protection API work with mus+ash

services/ui/public/interfaces/display/display_controller.mojom

Index: services/ui/public/interfaces/display/display_controller.mojom
diff --git a/services/ui/public/interfaces/display/display_controller.mojom b/services/ui/public/interfaces/display/display_controller.mojom
index 30fe11ca724bb5960b9123591963886aee4ec301..e0df624f3237c7b838dfa5b3fa9dcb4f1c0bf75f 100644
--- a/services/ui/public/interfaces/display/display_controller.mojom
+++ b/services/ui/public/interfaces/display/display_controller.mojom
@@ -52,4 +52,28 @@ interface DisplayController {
   // TODO(kylechar): This interface will need to be expanded to provide
   // additional functionality for the display settings page and other ash
   // keyboard accelerators.
+
+  // ========================= Content Protection ==============================

[rjkroege, 2017/02/09 00:44:43]

I don't think that this code belongs here. display_controller.mojom is a
privileged interface for clients such as ash to manage the display hardware.
Requesting content protection would seem to be a general service that
(apparently) should be available to lower-privilege clients such as the browser.
In particular: in the future, blink may wish to request display protection yes?

I think this needs to be a separate interface and the client (browser) ought to
be prepared for mus-ws to indicate that protection is not available or that the
client is not allowed to request it.

[Peng, 2017/02/09 14:27:15]

This interface can not only enable content protection, but also disable content
protection. So I don't think we want to every clients have the right to disable
the display content protection. So in pepper, this API is made a as private API,
and it is only accessible to plugins provided by Google. Consider this fact,
probably we want to make this mojo interface as a privileged interface too.

@kwcu, could you please give us more detail about this API? Should we make it a
general service or keep it as a private and privileged service? Thanks. 

[kcwu, 2017/02/09 18:55:39]

This interface should be only accessed from trusted code because it fully trust
parameters like |client_id| from the client.

It is possible converting it to general service since it is mojo now,
|client_id| can be kept on trusted callee side. However, so far there is no
known request to open it as general service.

+
+  // Registers a client for display protection and requests a client id. Returns
+  // 0 if requesting failed.
+  [Sync]

[rjkroege, 2017/02/09 00:44:43]

Can this be not sync?

[sky, 2017/02/09 20:59:07]

+1

[Peng, 2017/02/10 15:57:02]

I removed this method. And keep the client_id in service side.

+  RegisterContentProtectionClient() => (uint64 client_id);

[sky, 2017/02/09 20:59:07]

This seems like separate functions than the rest of the functions on this
interface. Is there a reason these functions need to be on DisplayController?

Why is the client_id necessary?

[Peng, 2017/02/10 15:57:02]

I removed the client_id, and moved those method to a new interface.

+
+  // Unregisters the client.
+  UnregisterContentProtectionClient(uint64 client_id);
+
+  // Queries link status and protection status.
+  QueryContentProtectionStatus(uint64 client_id,
+                               int64 display_id) => (bool success,
+                                                     uint32 link_mask,
+                                                     uint32 protection_mask);
+
+  // Requests the desired protection methods.
+  // |protection_mask| is the desired protection methods, which is a bitmask
+  // of the ContentProtectionMethod values.
+  // Returns true when the protection request has been made.
+  EnableContentProtection(uint64 client_id,
+                          int64 display_id,
+                          uint32 desired_method_mask) => (bool success);
 };