Determine how Multi-touch surfaces should be handled.

[toji]

As of #26 the gamepad API now supports single touch touchpads and similar capacitive controls. That addition to the spec does not (explicitly*) cover multitouch surfaces, however. It also doesn't cover more complex touch concepts like gestures. It seems like if we want to take advantage of increasingly complex touch surfaces a more robust API is needed, along the lines of PointerEvents (or even using PointerEvents directly).

That being said, the number of gamepad-like objects that have multitouch surfaces is pretty low. The only ones I know of off the top of my head are the PS4 controller (who's touchpad is limited to 2 touch points) and the WiiU Pad which... just, no.

*It's possible that you could represent a multitouch control with multiple pairs of axes and multiple buttons to represent each touch point, but that feels like it's stretching the API a bit thin.

[mrmcpowned]

It could be possible to have multi-touch surfaces separated into their own property similar to axes and buttons, e.g. surfaces, although this seems like it would be necessary to know the maximum number of touch points allowed for each device.

As for gestures, these seem trickier. If we look at how user use gestures on mobile devices, the input can begin as one type of gesture and end as another, such as when a 2-finger rotation turns into a pinch, so this would need to be handled somehow. Another question seems to be the matter of correctly identifying gestures, as well as what gestures should be supported.

[cvan]

See my comment in PR #26. Pointer Events seem to be the best approach that comes to mind, IMO.

[cvan]

@toji did you remove Gamepad support for touched in your latest builds?

[knyg]

I'd like to resume discussing how we can provide multi touch support for gamepads.

At TPAC 2017, we expressed our interest in providing multi touch support to developers. With an increasing number of gamepad devices that support a touch surface(s), a use case exists to add multi touch support to the spec in a standardized format. Currently, implementation of touch functionality is ad hoc, making it difficult to support multiple touch devices in a uniform manner. Additionally, the spec lacks a way to identify unique touch events. This results in the ability to miss one or more touch up + touch down events if the application does not poll at the correct rate.

We've drafted a proposal that addresses the above concerns: multi-touch proposal

Please let us know if you have any questions, comments, or feedback.

[nondebug]

@knyg:

For touchId, with such a small range it's likely that the ID will exceed 255 and (presumably) wrap back to zero. Can we increase the range so wrapping is less common?

The proposal doesn't describe how touch events are associated with a touch ID. Do you expect this would be done by the user agent, or would this be provided by the device API? Could we support a device that only provides touch coordinates and no tracking?

[knyg]

@nondebug

Yes, there are no concerns with increasing the range of touchId. I'll change it to an unsigned long. I'll also make it clearer that the user agent should increase the touch id from 0 to the max value before rollover occurs.

The proposal doesn't describe how touch events are associated with a touch ID.

The intent was for the user agent to assign the touch ID associated with each touch event based on information from the device API. This would be needed since different devices may output a different range of touch ids. Additionally, we've seen devices report touch up differently. Some explicitly indicate the event has occurred, while others cease updates for a touch ID.

I'll add that clarification to the proposal as well.

Could we support a device that only provides touch coordinates and no tracking?

I think what you're asking here is whether we can support a device that doesn't indicate a touch down/up has occurred in any of the aforementioned ways. We could support that type of device by having the user agent assign a touch id of 0 to all touch events.

[knyg]

@nondebug

Thanks for the suggestions. I updated the proposal in the following commit - touch updates