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
<[email protected] <mailto:[email protected]>> 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
