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..61c2701a46ef3e19138a6767b9f1e2a56089b8d4 100644
--- a/remoting/proto/event.proto
+++ b/remoting/proto/event.proto
@@ -79,3 +79,39 @@ message ClipboardEvent {
   // The data being sent.
   optional bytes data = 2;
 }
+
+message TouchEvent {
+
+  message Point {

[Wez, 2015/01/21 03:08:37]

If you define this as TouchPoint or TouchEventPoint at the top level then it is
possible to forward-declare it, to avoid having to #include the definition in
e.g. headers that don't need to know any of its internal details.

[Rintaro Kuroiwa, 2015/01/28 01:12:29]

Done.

+    enum TouchPointEventType {
+      // The types map to event types in PP_InputEvent_Type.
+      TOUCH_POINT_START     = 1;
+      TOUCH_POINT_MOVE      = 2;
+      TOUCH_POINT_END       = 3;
+      // Cancel event is different from END. For example on Android,
+      // CANCEL should be treated as up (END) but might not perform some
+      // actions.

[Wez, 2015/01/21 03:08:37]

This is confusingly worded; I think what you mean is that CANCEL lets you
indicate that all the touch points are gone, without executing whatever action
might be triggered by the gesture the user made?

Do CANCEL events need X, Y, radius fields?

[Rintaro Kuroiwa, 2015/01/28 01:12:29]

If I understood you correctly, you mean CANCEL cancels all the touch points that
are currently "down".
No, that is not what cancel is. CANCEL is a type of END (or UP for some
platforms) but it is up to the application to distinguish between CANCEL and
END.
Android MotionEvent.ACTION_CANCEL has this documented
http://developer.android.com/reference/android/view/MotionEvent.html#ACTION_C...
I've also seen CANCEL events from PPAPI when I released two finger off the
digitizer almost at the same time. The one that went off was END and latter was
CANCEL.

+      TOUCH_POINT_CANCEL    = 4;
+    };
+
+    optional TouchPointEventType event_type = 1;

[Wez, 2015/01/21 03:08:37]

Doesn't this belong in the TouchEvent, rather than in the TouchEvent::Point?

[Rintaro Kuroiwa, 2015/01/28 01:12:29]

Yes.
Initially I thought I would need an event that can report some touch points went
up, some moved, and some down at the same time. But after some research, I've
never seen an interface where an event contains a combination of them. It's
always UP MOVE or DOWN.

+
+    // The ID for the point.
+    optional uint32 id = 2;
+
+    // The position of the point.
+    // If the client is scaling the view (shrink or zoom), these will be scaled
+    // as well.

[Wez, 2015/01/21 03:08:37]

This comment is not relevant to the protocol; at the protocol level, these are
always host-relative, which is what your next comment says.

[Rintaro Kuroiwa, 2015/01/28 01:12:29]

Done.

+    // These values on-the-wire are host coordinates.
+    optional float x = 3;
+    optional float y = 4;
+
+    // x and y values that define the ellipse of the touch region.
+    // This determines the size of the touch region.

[Wez, 2015/01/21 03:08:37]

Suggest combining these to something like:

The size of the touch point, used to aid hit-testing.

[Rintaro Kuroiwa, 2015/01/28 01:12:29]

Done.

+    // Unlike x,y coordinates, these will not be scaled.

[Wez, 2015/01/21 03:08:37]

Why not?

[Rintaro Kuroiwa, 2015/01/28 01:12:29]

I actually don't have a good reason for or against size scaling. Do you think
the user would expect (and would be a better user experience with) size scaling?

[Rintaro Kuroiwa, 2015/01/29 07:37:46]

After giving it some more thought, scaling the size is the only reasonable
solution. I'll work on this tomorrow :)

+    optional float radius_x = 5;
+    optional float radius_y = 6;
+  }
+
+  repeated Point touch_points = 1;
+}