Use mojo for cursor control in ozone drm

ui/ozone/platform/drm/cursor_proxy_mojo.cc

Index: ui/ozone/platform/drm/cursor_proxy_mojo.cc
diff --git a/ui/ozone/platform/drm/cursor_proxy_mojo.cc b/ui/ozone/platform/drm/cursor_proxy_mojo.cc
new file mode 100644
index 0000000000000000000000000000000000000000..cebed0d86627033e3c0d4ca1aa8e400c266dc869
--- /dev/null
+++ b/ui/ozone/platform/drm/cursor_proxy_mojo.cc
@@ -0,0 +1,34 @@
+// 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.
+
+#include "ui/ozone/platform/drm/cursor_proxy_mojo.h"
+
+#include "services/shell/public/cpp/connector.h"
+
+namespace ui {
+
+CursorProxyMojo::CursorProxyMojo(shell::Connector* connector)
+    : connector_(connector->Clone()) {
+  connector->ConnectToInterface("mojo:ui", &main_cursor_ptr_);
+}
+
+void CursorProxyMojo::InitializeOnEvdev() {
+  connector_->ConnectToInterface("mojo:ui", &evdev_cursor_ptr_);
+}
+
+CursorProxyMojo::~CursorProxyMojo() {}
+
+void CursorProxyMojo::CursorSet(gfx::AcceleratedWidget widget,
+                                const std::vector<SkBitmap>& bitmaps,
+                                const gfx::Point& location,
+                                int frame_delay_ms) {
+  main_cursor_ptr_->SetCursor(widget, bitmaps, location, frame_delay_ms);
+}
+
+void CursorProxyMojo::Move(gfx::AcceleratedWidget widget,
+                           const gfx::Point& location) {
+  evdev_cursor_ptr_->MoveCursor(widget, location);

[spang, 2016/07/19 14:59:37]

Why is it necessary to have two connections (since we already synchronize access
to it? Is this a mojo restriction?)

It seems really subtle to decide which connection to use based on which function
gets called in this class.. And I suspect it may be broken, because explicit
warps and injected mouse events (remoting) start on the UI thread and may send a
move event from that thread, land here, and call through evdev_cursor_ptr_, not
main_cursor_ptr_.

[rjkroege, 2016/07/21 01:10:41]

Yes. Connections are thread-to-thread.
Excellent point. I misread the code in drm_cursor.cc and have adjusted to use
thread-specific entry points in the DrmCursorProxy based on the the threading
conventions documented in CursorDelegateEvdev.

[spang, 2016/07/21 19:21:57]

Those docs aren't quite right :( For example tablets don't use dx/dy

+}
+
+}  // namespace ui