Re: [gamepad] preventing default/capturing controller

Sorry, meant to respond to this earlier but wanted to make sure the
relevant details were already public.

Valve's upcoming Steam
a good use case for an API like this. The controller's touchpads
can be used to emulate mouse and keyboard input, making it possible to
navigate the browser with it. This could be a really nice way to use a
browser in a living room setting or similar. The controller can also be
switched to a gamepad emulation mode, however, where the touchpads emulate
standard joysticks. These modes can be switched via software by sending the
appropriate USB reports (Or using the right Steamworks API, but that'
probably a non-starter for inclusion in a browser). The timing of that
switch, however, would be difficult to predict. Having an explicit "gamepad
lock" like Patrick described would help this scenario quite a bit.


On Tue, Mar 18, 2014 at 3:39 AM, Matt Gaunt <> wrote:

> Adding a best approach to the spec is a good idea.
> Originally I thought that having a gamepadconnected callback (or some use
> of the Gamepad API) would be enough of an indicator to prevent the UA from
> manipulating the key presses / cursor movement.
> The main scenarios I'm struggling to see as a good fit for this:
> - The developer has a settings screen and would rather use the UA's
> manipulated keys within an event listener, rather than handle gamepad state
> in an animation frame. A separate API would probably be cleaner for
> developers to follow and presumably easier to implement in the UA side.
> - [Much more niche] There are native components around the edge of the UA
> which could be interacted with, Firefox on the Ouya is a great example.
> Should this be something which is catered for? Ideally the game would want
> to be in fullscreen mode and the user would have to leave fullscreen to
> interact with the native elements, this way the UA has a clear point to
> break out of the gamepad mode.
> I'll try and get hold of Scott Graham and see if he has any thoughts /
> comments.

Received on Wednesday, 26 March 2014 18:32:12 UTC