Re: [gamepad] preventing default/capturing controller

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?

P

> On Fri, Mar 14, 2014 at 1:35 AM, Patrick H. Lauke
> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>
>     No takers on the idea of having some form of control - like a
>     gamepad capture lock, or some way of preventDefault-ing gamepad
>     controls before they're turned into mouse/cursor controls by the UA?
>
>
>     On 26/02/2014 10:16, Patrick H. Lauke wrote:
>
>         "Currently, the only way for a gamepad to be used as input would
>         be to
>         emulate mouse or keyboard events"
>
>         I'm wondering if it's in scope for this spec to also address the
>         situation where a UA *does* already do this natively (for
>         instance, IE
>         on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad
>         firing cursor event.
>
>         A few precedents that may be worth looking at:
>
>         - Pointer Lock API http://www.w3.org/TR/__pointerlock/
>         <http://www.w3.org/TR/pointerlock/>
>
>         - Opera's spatial navigation on TV browsers, which can be
>         preventDefault-ed if the website/app wants to handle d-pad input
>         (mapped
>         to cursor keys already, mind) on a remote control
>         http://dev.opera.com/articles/__view/functional-key-handling-__in-opera-device-sdk-based-tv-__browsers/#prevent-default
>         <http://dev.opera.com/articles/view/functional-key-handling-in-opera-device-sdk-based-tv-browsers/#prevent-default>
>
>
>         - Boxee's (discontinued) API to explicitly switch browser into
>         different
>         modes (cursor, keyboard, player)
>         http://developer.boxee.tv/__JavaScript_API#Browser_Modes
>         <http://developer.boxee.tv/JavaScript_API#Browser_Modes>
>
>         There's an argument that this should be left completely up to
>         the UA,
>         and that users should switch the UA into different modes.
>         However, at
>         the very least it would be nice then to have a way for a site/app to
>         *signal* that it can handle direct gamepad input.
>
>         Thoughts?
>
>         P
>
>
>
>     --
>     Patrick H. Lauke
>
>     www.splintered.co.uk <http://www.splintered.co.uk> |
>     https://github.com/__patrickhlauke <https://github.com/patrickhlauke>
>     http://flickr.com/photos/__redux/ <http://flickr.com/photos/redux/>
>     | http://redux.deviantart.com
>     twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>


-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Friday, 14 March 2014 15:36:24 UTC