Add Mojo IPC based input-device service.

components/mus/public/interfaces/input_devices/input_devices.mojom

+// 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.
+
+module input_device.mojom;
+
+import "ui/gfx/geometry/mojo/geometry.mojom";
+
+// Corresponds to ui::InputDeviceType
+enum InputDeviceType {
+  INPUT_DEVICE_INTERNAL,
+  INPUT_DEVICE_EXTERNAL,
+  INPUT_DEVICE_UNKNOWN,
+};
+
+// Corresponds to ui::InputDevice.
+struct InputDevice {
+  int32 id;
+  InputDeviceType type;
+  string name;
+  string sys_path;
+  uint16 vendor_id;
+  uint16 product_id;
+};
+
+// Corresponds to ui::TouchscreenDevice.
+struct TouchscreenDevice {
+  // Base class.
+  InputDevice input_device;

[sadrul, 2016/06/07 03:39:26]

Hm, do we do subclassing like this in other places too?

I was thinking mojom.InputDevice would have an optional TouchscreenInfo{size,
touch_points} field, which would be null for non-touchscreen devices. (that's
how do this for mojom.Event, for example)

[kylechar, 2016/06/07 16:36:42]

Oh, so looking at mojom.Event it's definitely done differently. I'm not sure we
do it this way anywhere else yet. 

I'm also not sure we want to do this like mojom.Event though. With that approach
we'd get back a std::unique_ptr<ui::InputEvent> for both ui::InputEvent and
ui::TouchscreenEvent. We don't really want that here though, so we want to get
back the class we serialized. It would require an extra step to copy from
std::vector<std::unique_ptr<ui::InputEvent>> to a std::vector<ui::InputEvent> or
std::vector<ui::Touchscreenevent>.

+
+  gfx.mojom.Size size;
+  int32 touch_points;
+};

[sadrul, 2016/06/07 03:39:26]

The above should move into //ui/events/mojo/ (or //ui/events/devices/mojo/)

[kylechar, 2016/06/07 16:36:42]

Done.

+
+// Receives updates about changes to input-devices.
+interface InputDeviceObserverMojo {
+  OnKeyboardDeviceConfigurationChanged(array<InputDevice> devices);

[sadrul, 2016/06/07 03:39:26]

Can you document these? For example, when an observer connects, and the
InputDeviceServer has already scanned all the devices by that time, does the
observer receive OnKeyboardDeviceConfigurationChanged() etc. calls once
immediately after connecting?

[kylechar, 2016/06/07 16:36:42]

I added better documentation. Most of it is under InputDeviceServer, just to
avoid duplicating the documentation (and having it get out of sync when things
eventually change).

+  OnTouchscreenDeviceConfigurationChanged(array<TouchscreenDevice> devices);
+  OnMouseDeviceConfigurationChanged(array<InputDevice> devices);
+  OnTouchpadDeviceConfigurationChanged(array<InputDevice> devices);
+  OnDeviceListsComplete();

[sadrul, 2016/06/07 03:39:26]

I am also wondering if OnDevicesListsComplete() is necessary. Ideally, the
server would respond to the client only once the list is complete, and so the
client can decide whether it has a valid list of devices depending on whether it
received a response from the server or not.

[kylechar, 2016/06/07 16:36:42]

I believe it's the easiest/best way to do this. By the time all the Mojo setup
happens, DeviceDataManager has probably received the OnDeviceListsComplete call.
However, we can't guarantee that.

Regardless, we don't send IPCs for empty device lists so the client doesn't know
if it hasn't received the device list yet or if the list is actually empty until
it gets OnDevicesListsComplete(). We could send an IPC for each device type even
if it's empty but that would require more IPC calls. It would also require more
complicated logic in InputDeviceClient.

+};
+
+interface InputDeviceServer {
+  // Adds an InputDeviceObserverMojo in another process as an observer to get
+  // notified of changes to input-devices over Mojo IPC.
+  AddObserver(InputDeviceObserverMojo observer);
+};