ozone: evdev: Add gamepad support

ui/events/ozone/gamepad/gamepad_observer.h

Index: ui/events/ozone/gamepad/gamepad_observer.h
diff --git a/ui/events/ozone/gamepad/gamepad_observer.h b/ui/events/ozone/gamepad/gamepad_observer.h
new file mode 100644
index 0000000000000000000000000000000000000000..312f0d162f1f9cb6565611614f0aa6b2d127fa2f
--- /dev/null
+++ b/ui/events/ozone/gamepad/gamepad_observer.h
@@ -0,0 +1,27 @@
+// Copyright 2017 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 UI_EVENTS_OZONE_GAMEPAD_GAMEPAD_OBSERVER_H_
+#define UI_EVENTS_OZONE_GAMEPAD_GAMEPAD_OBSERVER_H_
+
+#include "base/logging.h"
+#include "base/time/time.h"
+#include "ui/events/ozone/gamepad/gamepad_event.h"
+
+namespace ui {
+
+class GamepadObserver {
+ public:
+  // Callback function when connected gamepad devices is updated.
+  virtual void OnGamepadDevicesUpdated() {}
+
+  // Callback function on gamepad.
+  virtual void OnGamepadEvent(const GamepadEvent& event) {}

[spang, 2017/04/21 05:38:46]

We might want to consider if we can just

#include device/gamepad/public/cpp/gamepad.h

(after adding a suitable dependency) and do

OnGamepadFrame(const Gamepad& gamepad);

this would avoid adding new event types and we'd need fewer conversions.

[jkwang, 2017/04/25 21:16:41]

The Gamepad class works great if the gamepad provider expose gamepad state
rather than send "gamepad event". As far as my client side (arc++ gamepad), I
care about gamepad event more than state. (I also believe most gamepad client
deal with gamepad event). Using OnGamepadFrame(const Gamepad& gamepad) here will
result in aggregating the events here and than differentiate gamepad state in
the client. It seems a waste to me. 

+
+  virtual ~GamepadObserver() {}
+};
+
+}  // namespace ui
+
+#endif  // UI_EVENTS_OZONE_GAMEPAD_GAMEPAD_OBSERVER_H_