[Chromecast] Add input support.

ui/events/ozone/evdev/event_thread_evdev.cc

Index: ui/events/ozone/evdev/event_thread_evdev.cc
diff --git a/ui/events/ozone/evdev/event_thread_evdev.cc b/ui/events/ozone/evdev/event_thread_evdev.cc
index abda8d1e7802a64d56e33f18dd4a367d1eb24804..c9634284f4b48fc31d483002f1aac0c5f27bc20f 100644
--- a/ui/events/ozone/evdev/event_thread_evdev.cc
+++ b/ui/events/ozone/evdev/event_thread_evdev.cc
@@ -43,7 +43,8 @@ class EvdevThread : public base::Thread {
         new InputDeviceFactoryEvdevProxy(base::ThreadTaskRunnerHandle::Get(),
                                          input_device_factory_->GetWeakPtr()));
 
-    cursor_->InitializeOnEvdev();
+    if (cursor_)

[derekjchow1, 2017/01/13 18:12:28]

Can Cast provide its own CursorDelegateEvdev? If so, we could provide a no-op
InitializeOnEvdev implementation and remove the need for this if-statement.

[Joshua LeVasseur, 2017/01/13 23:38:13]

Glancing through the evdev code, it seems to be designed to handle a null
cursor_ (it totally used to handle a null cursor_ when I started prototyping
this code).  We don't support a mouse, so a nullptr seems appropriate, rather
than a no-op CursorDelegateEvdev --- but I'm guessing about intentions of the
evdev layer.

[spang, 2017/01/16 18:54:54]

Yes, it did support null, it just breaks from time to time because it has no
integration test coverage (CrOS tests use the cursor, obviously, so the non-null
case gets tested). Would be good to fix that.

A stub CursorDelegateEvdev does not have quite the same effect as a null one - a
stub that always reports a position of (0,0) would cause a CSS hover effect
there, for example.

+      cursor_->InitializeOnEvdev();
 
     init_runner_->PostTask(FROM_HERE,
                            base::Bind(init_callback_, base::Passed(&proxy)));