Controller support for VrShell

content/public/browser/android/vr_input_manager.h

Index: content/public/browser/android/vr_input_manager.h
diff --git a/content/public/browser/android/vr_input_manager.h b/content/public/browser/android/vr_input_manager.h
new file mode 100644
index 0000000000000000000000000000000000000000..80ba16669504c88d2085569575ff86fc79c7be35
--- /dev/null
+++ b/content/public/browser/android/vr_input_manager.h
@@ -0,0 +1,42 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CONTENT_PUBLIC_BROWSER_ANDROID_VR_INPUT_MANAGER_H_
+#define CONTENT_PUBLIC_BROWSER_ANDROID_VR_INPUT_MANAGER_H_
+
+#include <jni.h>
+
+#include "base/android/scoped_java_ref.h"
+#include "base/callback.h"
+#include "base/strings/string16.h"
+#include "content/common/content_export.h"
+#include "content/public/browser/android/content_view_core.h"
+#include "content/public/browser/readback_types.h"
+
+namespace content {
+
+class CONTENT_EXPORT VrInputManager {

[boliu, 2016/09/22 16:33:35]

why do you need *new* entry points to send input events for vr? why can't
existing entry points be re-used?

[mthiesse, 2016/09/22 17:13:08]

As far as I know there are no existing public entry points for injecting input
events from chrome/browser/. Is this not this case? Which existing entry points
could we re-use?

[mthiesse, 2016/09/22 17:19:49]

Oh, I wasn't aware of RenderWidgetHost::ForwardGestureEvent. It appears to only
be used in unit tests at the moment? Is this the entry point we should use?

[boliu, 2016/09/22 17:22:25]

The normal flow goes through ContentViewCore.on*Event. There is a big refactor
to remove ContentViewCore though, but the idea is input should be delivered by
the "view" abstraction, so for android, the input stuff from ContentViewCore
will be moved to ViewAndroid

[mthiesse, 2016/09/22 17:28:12]

We can't talk directly to ContentViewCoreImpl from our native code that lives in
chrome/browser, and we would really prefer to avoid jni hopping into java to
generate a Motion event only to hop back into native code and turn that Motion
event we just generated into a gesture event.

[asimjour, 2016/09/22 17:34:57]

we can add the functionality to content_view_core_impl, but the interface is not
designed to be used from native.
So, we would have to send events from vr_shell native to Java and from
ContentViewCore to native again + add new interface to content_view_core_impl.
Or we can add the functionality that we need to content_view_core to avoid JNI
calls.
The first option adds latency, and complexity to ChromeTabbedActivity. The
second option is against the big refactoring that you mentioned.

+ public:
+  // Returns the existing ContentViewCore for |web_contents|, or nullptr.

[mthiesse, 2016/09/22 16:20:11]

update comment.

+  static VrInputManager* FromContentViewCore(

[mthiesse, 2016/09/22 16:20:12]

nit: no need for newline?

+      ContentViewCore* content_view_core);
+
+  virtual void SendScrollEvent(long time_ms,
+                               float x,
+                               float y,
+                               float dx,
+                               float dy,
+                               int type) = 0;
+
+  virtual void SendClickEvent(long time_ms, float x, float y) = 0;
+
+  virtual void SendMouseMoveEvent(long time_ms, float x, float y, int type) = 0;
+
+ protected:
+  ~VrInputManager() {}
+};
+
+};  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_ANDROID_VR_INPUT_MANAGER_H_