Re: [gamepad] preventing default/capturing controller

On 3/14/2014 11:36 AM, Patrick H. Lauke wrote:
> On 14/03/2014 15:29, Vincent Scheib wrote:
>> Perhaps I'm missing some context. What issue are you raising that isn't
>> handled by the gamepad API [1]?
>>
>> [1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html
>
> The issue is perhaps hypothetical at the moment, but: the spec
> currently does not address (unless I've missed it) the scenario where
> a user agent is already set to react to a gamepad input device - see
> for instance IE on XBox One, where the analogue stick moves an
> on-screen mouse pointer and the d-pad maps to regular cursor keys.
>
> Now, IE doesn't currently support the gamepad API, but once it does -
> or similar devices, particularly in the TV/set-top box space come out
> that do - there will be some conflict between an application using the
> gamepad API to directly tap into those controls AND the browser/OS
> doing its own mapping (analogue stick as mouse, d-pad as cursors).
> You'd end up with, say, a movement of the analogue stick BOTH being
> processed through the API AND the on-screen mouse pointer moving.
>
> For this reason, I was wondering if it's worth pre-emptively
> addressing this situation by defining a way for a website/app to
> "lock" the controller, signalling to the browser/OS that it will
> handle gamepad input directly, and that default browser/OS mappings
> should be ignored.
>
> Hope that makes it a tad clearer?
>
This is a fair point. I've thought about this a little bit in the
context of implementing the API for Firefox for Android. Our Android
implementation already has some Gamepad-based navigation for use on the
Ouya console, so the same conflict will exist.

After ruminating, though, my thought was that an explicit API is
probably not necessary--if a web page accesses the Gamepad API at all
then the browser can relinquish using the controller as navigation to
allow the page to do its thing. The only thing necessary is for the
browser to have some way to "break out" of this mode so the user can
dismiss the page or navigate somewhere else.

Thoughts? This is certainly something that the spec should talk about,
since it will impact usage on consoles which is a pretty important use case.

-Ted

Received on Friday, 14 March 2014 15:52:26 UTC