Re: [w3c/gamepad] Enhance Gamepad interface description for Touch (PR #168)

@nondebug commented on this pull request.



> +          Receiving inputs</a> section of the main 
+          <a href="https://w3c.github.io/gamepad/">Gamepad specification</a>.
+        </p>
+        <p>
+          In addtion to the steps defined in the main 
+          <a href="https://w3c.github.io/gamepad/">Gamepad specification</a>.
+          When the user agent modifies the list of |active touch points| for a 
+          touch surface by adding touch points, removing touch points, 
+          or updating the values of existing touch points,
+          <dfn data-lt="updating touchEvents">update touchEvents</dfn>
+          by running the following steps:
+        </p>
+        <ol>
+          <li>Let |surfaceId:unsigned long| be 0.
+          </li>
+          <li>Let |touchSurfaces:list| be an [=ordered set=] of touch surfaces

In this algorithm we describe `touchSurfaces`, `touchInputs`, `touchData` but there's no instructions on how to construct those objects.

We want to emphasize the assumptions we're making about the inputs but we also don't want to specify more than we have to. I think we can modify the algorithm to be more specific about the assumptions we're making while being less specific about how the data is presented. For example, if we specify that a gamepad's touch surfaces need to have some consistent ordering then we can iterate over them without creating lists:

* Let |surfaceId| be 0.
* Repeat these steps for each [=touch surface=] on |gamepad| in [=touch surface enumeration order=]:
  * Let |surfaceDimensions| be `null`.
  * If the [=touch surface=] exposes maximum dimensions in device units:
    * Set |surfaceDimensions| to a [=new=] {{Array}} with length 2.
    * Set |surfaceDimensions|[0] to the maximum X dimension of the current [=touch surface=] in device units.
    * Set |surfaceDimensions|[1] to the maximum Y dimension of the current [=touch surface=] in device units.
  * Repeat these steps for each [=active touch point=] on the current [=touch surface=]:
    * Let |x:float| be the X coordinate for the current [=active touch point=] in device units.
    * Let |y:float| be the Y coordinate for the current [=active touch point=] in device units.
    * Let |position| be a [=new=] {{Array}} with length 2.
    * If |surfaceDimensions| is `null`:
      * Set |position|[0] to ???.
      * Set |position|[1] to ???.
    * Otherwise:
      * Set |position|[0] to a value calculated from |x| and |surfaceDimensions|[0] and normalized to [-1,1].
      * Set |position|[1] to a value calculated from |y| and |surfaceDimensions|[1] and normalized to [-1,1].
    * Let |touchEvent| be a [=new=] {{GamepadTouch}}:
      * Initialize |touchEvent|.{{GamepadTouch/surfaceId}} to |surfaceId|.
      * Initialize |touchEvent|.{{GamepadTouch/position}} to |position|.
      * Initialize |touchEvent|.{{GamepadTouch/surfaceDimensions}} to |surfaceDimensions|.
      * [=list/Append=] |touchEvent| to |gamepad|.{{Gamepad/[[touchEvents]]}}.
  * Increment |surfaceId|.

> +                <p>Let |normalizedY:float| be a value calculated from the current
+                  touch input y coordinate in relationship to the surfaceDimensionY
+                  and normalized to the range [-1.0, 1.0] where -1.0 is the topmost
+                  coordinate and 1.0 is the bottommost coordinate.
+                </p>
+                <p>
+                <p>Possible implementation:</p>
+                <ul>
+                  <li>`normalizedY = (2.0 * touchData.y / surfaceDimensionY) - 1`</li>
+                </ul>
+                </p>
+              </li>
+              <li>Let |touchEvent:GamepadTouch| be a {{GamepadTouch}}.
+              </li>
+              <li>Set |touchEvent|.{{GamepadTouch/touchId}} to be
+              `touchData.touchID`.

> it appears that the dfn is not exported

I'm not sure why the xref dfn doesn't work. It doesn't show up in https://respec.org/xref/ either. https://respec.org/docs/#xref suggests it needs a change to the touch-events spec to export it. I'm okay with leaving it as-is for now, we can clean this up later when the extension is merged into the main specification.

> normalizing the touchId is much easier at the ds4_controller than the device/gamepad (this may be a bad assumption on my part that when you refer to an "internal slot" it would translate to that object)

Normalizing touchId in Dualshock4Controller won't work because a device::Gamepad isn't 1-to-1 with a blink::Gamepad. Most of the time, "internal slot" should be read as "1-to-1 with blink::Gamepad". The only time we can attach internal slots to device::Gamepad is if all tabs should see the same value. This isn't true for touchId and nextTouchId since they may differ between tabs even for the same gamepad.

Suppose there's a tab accessing a DS4 through Gamepad API and it receives a touch point with ID 0. Then a second tab is opened and begins accessing DS4 through Gamepad API. When the next touch occurs, the first tab should get a touch point with ID 1 and the second tab should get touch ID 0. If we deliver touch ID 1 to both tabs then the second tab can deduce that another tab was accessing Gamepad API.

We can store raw touchIds in the device::Gamepad buffer and normalize them in blink::Gamepad::UpdateFromDeviceState. To normalize the ID, blink::Gamepad will need to maintain nextTouchId along with a mapping from raw->normalized touchIds for all active touch points. The rest of the touch data (surfaceId, position, surfaceDimensions) won't change between tabs so we can store it in the device::Gamepad buffer.

> Requiring the nextTouchId in device/gamepad might cause difficulty in implementing other touch controllers. The specification just needs to be clear that implementers support 32 bit value starting at 0 and incrementing with each new touch event not associated with an existing active touch point. How this is accomplished should be open.

Agreed, the spec should not care how active touch points are identified. We only need to be able to enumerate them and somehow associate current set of active touch points with the set of active touch points from the previous update.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/168#pullrequestreview-1065628316
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/pull/168/review/1065628316@github.com>