Add event listening function to openvr device

device/vr/openvr/openvr_device.h

Index: device/vr/openvr/openvr_device.h
diff --git a/device/vr/openvr/openvr_device.h b/device/vr/openvr/openvr_device.h
index 136f5667fd226c7e650e489d3e7491d0fbee37cc..7be1d815290cf42e62d6a63add1c6236a5f7b706 100644
--- a/device/vr/openvr/openvr_device.h
+++ b/device/vr/openvr/openvr_device.h
@@ -18,6 +18,8 @@ namespace device {
 
 class OpenVRDevice : public VRDevice {
  public:
+  enum VREvent { CONNECTED = 0, DISCONNECTED = 1, CHANGED = 2 };

[nhu, 2017/04/24 01:47:06]

No need to define general vr events in OpenVRDevice implementation, define them
or re-use exiting ones in VRDevice.

+
   OpenVRDevice();
   ~OpenVRDevice() override;
 
@@ -39,16 +41,26 @@ class OpenVRDevice : public VRDevice {
                          int16_t source_height) override;
   void GetVRVSyncProvider(mojom::VRVSyncProviderRequest request) override;
 
+  void OnPollingEvent(OpenVRDevice::VREvent event);

[nhu, 2017/04/24 01:47:06]

VRDevice already defines OnXXX functions for event handling (See
https://cs.chromium.org/chromium/src/device/vr/vr_device.h?type=cs&l=53). 

Can we use them instead of introducing this new "OnPollingEvent"?

[shaobo.yan, 2017/04/24 02:27:27]

Due to the current class relationship, I think OpenVRRenderLoop cannot access
OpenVRDevice non-static function directly(Am I right?). So if I re-use these
functions I need to either transfer an OpenVRDeivce instance(which I think will
break the access control) or register a set of callbacks. Pls correct me if I'm
wrong :) 

+
  private:
   class OpenVRRenderLoop : public base::SimpleThread,
                            device::mojom::VRVSyncProvider {
    public:
     OpenVRRenderLoop(vr::IVRSystem* vr);
 
+    void RegistPollingEventCallback(
+        const base::Callback<void(OpenVRDevice::VREvent)>& onPollingVREvent);

[nhu, 2017/04/24 01:47:06]

Can we use a VRDevice reference to OpenVRDevice instance? Then OpenVRRenderLoop
is able to call OnXXX event handlers of VRDevice to notify.

[shaobo.yan, 2017/04/24 02:27:27]

Yes, I think this is the base question need to discsussion. All of the patch
design is based on avoiding OpenVRRenderLoop instance and OpenVRDevice holding
each other. If they hold each other the life-cycle management is a little bit
complex(maybe :) ).
And If OpenVRRenderLoop need VRDevice to do more jobs I think it indeed could
hold VRDevice reference. but if only need event handling I prefer a callback :)

+
+    void UnregistPollingEventCallback();
+
     void Bind(mojom::VRVSyncProviderRequest request);
 
     mojom::VRPosePtr getPose();
 
+    // OpenVR need invoke pollNextEvent to query system event.
+    void PollEvent();

[nhu, 2017/04/24 01:47:06]

naming: PollEvent -> PollEvents?

[shaobo.yan, 2017/04/24 02:27:28]

That's a better name !

+
    private:
     void Run() override;
 
@@ -56,6 +68,7 @@ class OpenVRDevice : public VRDevice {
                       callback) override;
 
     scoped_refptr<base::SingleThreadTaskRunner> main_thread_task_runner_;
+    base::Callback<void(OpenVRDevice::VREvent)> on_polling_event_;
     vr::IVRSystem* vr_system_;
     mojo::Binding<device::mojom::VRVSyncProvider> binding_;
   };
@@ -68,6 +81,8 @@ class OpenVRDevice : public VRDevice {
 
   mojom::VRSubmitFrameClientPtr submit_client_;
 
+  base::WeakPtrFactory<OpenVRDevice> weak_ptr_factory_;
+
   DISALLOW_COPY_AND_ASSIGN(OpenVRDevice);
 };