Add touch events to the protocol, the stub layer, and to the client plugin.

remoting/proto/event.proto

Index: remoting/proto/event.proto
diff --git a/remoting/proto/event.proto b/remoting/proto/event.proto
index dd150942b771df1fab75e72512bac3d28ded5a6b..00c40012cc87523f7d805fc4baf55dc54e41e7a3 100644
--- a/remoting/proto/event.proto
+++ b/remoting/proto/event.proto
@@ -79,3 +79,35 @@ message ClipboardEvent {
   // The data being sent.
   optional bytes data = 2;
 }
+
+message TouchEventPoint {
+
+  // The ID for the touch point.
+  optional uint32 id = 1;
+
+  // The position of the touch point.
+  // These values on-the-wire are host coordinates.
+  optional float x = 2;
+  optional float y = 3;
+
+  // The size of the touch point, used to aid hit-testing.
+  // Unlike x,y coordinates, these will not be scaled.

[Sergey Ulanov, 2015/01/29 18:00:46]

You also need rotation angle. It's not useful to separate x and y coordinates
without it.

[Rintaro Kuroiwa, 2015/01/30 17:57:02]

Done.

+  optional float radius_x = 4;

[Sergey Ulanov, 2015/01/29 18:00:46]

Do we also need a field for pressure/force?

[Rintaro Kuroiwa, 2015/01/30 17:57:02]

wez mentioned that rotation angle and pressure are advanced fields that we could
add them later if we're not clear on how we handle them. Angle makes sense to be
here now because we use radius_{x,y}.
For pressure, most APIs say that the pressure is "usually" within some range.
Until we decide how we use it or what to do when it's not in the range, we could
make them a constant on the host side. WDYT?

[Sergey Ulanov, 2015/02/02 19:32:05]

We do get pressure values on Android, Web and Pepper and they all use the same
range [0, 1].
I think it's still better to add it here even if it's not supported on some host
platforms. It's better to send all data that the client gets for each event and
let the host decide how to inject them depending on feature the target OS
supports (e.g. ignore the pressure if the OS doesn't support it). E.g. initially
we were sending only delta values for the wheel events and that was causing
problems on platforms that need ticks (particularly X11).

[Rintaro Kuroiwa, 2015/02/02 22:22:56]

Done.

+  optional float radius_y = 5;
+}
+
+message TouchEvent {
+
+  enum TouchEventType {
+    TOUCH_POINT_START = 1;

[Sergey Ulanov, 2015/01/29 18:00:46]

I'm not sure I understand what these types mean. E.g. if user was touch the
screen with one finger and then puts down the second finger, is it START or
MOVE? When is END is sent? 

[Rintaro Kuroiwa, 2015/01/30 17:57:02]

When a user starts touching a screen with a new finger, that is a START. If the
finger that was already on the screen moved then it would be a MOVE event.
END happens when a user lifts one or more fingers off the screen. Similar for
CANCEL but the meaning is slightly different as noted in the comment.
Should I add a comment in the proto?

[Sergey Ulanov, 2015/02/02 19:32:05]

I see.
What's confusing to me is that there are multiple touch_points, and only one
event_type.
If host gets END with multiple touch points then it means that two fingers were
lifted at the same time, right? What if one was lifted while another one moved?
Will the client send two separate events in that case? If so why can't it send
two separate events for two released fingers (i.e. touch_points doesn't need to
be repeated)? 
Yes please.

[Rintaro Kuroiwa, 2015/02/02 22:22:56]

Repeating myself what we discussed offline.

Correct, in terms of this protocol if the event type is END and if there were 2
touch_points, then that means 2 fingers went off the screen at the same time.
For most (all the ones that I looked at) touch event APIs:
- If one finger was lifted and the other has moved, those will be different
events.
- Typically multiple points are reported in a MOVE event (I checked this in
PPAPI and according to Android MotionEvent documentation, there could be
multiple move points in an event).
- But usually START, END, and CANCEL events only report 1 point.

It is true that we can send multiple MOVE events instead of making touch_points
field repeated.

For the APIs that we know I think it makes sense to have event_type here rather
than in TouchEventPoint.
If we find it more efficient to batch START, END, MOVE, and CANCEL in an event,
we could add a field in TouchEventPoint later that would deprecate this field.

+    TOUCH_POINT_MOVE = 2;
+    TOUCH_POINT_END = 3;
+    // Cancel event is different from END. For example, Android MotionEvent's
+    // ACTION_CANCEL should be treated as UP (END) but might not perform the
+    // same action as UP.
+    TOUCH_POINT_CANCEL = 4;
+  };
+
+  optional TouchEventType event_type = 1;
+  repeated TouchEventPoint touch_points = 2;

[Sergey Ulanov, 2015/01/29 18:00:46]

Should this include all current touches or only those that have changed?

[Rintaro Kuroiwa, 2015/01/30 17:57:02]

Only those points that changed.
This seems to be the popular type of API for most touch handling APIs, where
it's easier to access the points that has changed since the last event. Since
the host can keep track of all the points (if it needs all of them for
injection), only the changes are on the wire.

Adding comment.

+}