JoystickAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Add a redirect to GamepadAPI page)
 
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{bug|604039}} covers prototyping a way for web content to receive input from Joystick/gamepad controllers connected to a computer.
#REDIRECT [[GamepadAPI]]
 
= Initial Implementation =
The patches currently on the bug implement a simple set of DOM events:
* MozJoyButtonDown
* MozJoyButtonUp
** These events currently have the properties:
** unsigned long joystickID: an arbitrary integer ID that's unique per connected device
** unsigned long button: button number being pressed/released
* MozJoyAxisMove
** This event currently has the properties:
** unsigned long joystickID: an arbitrary integer ID that's unique per connected device
** unsigned long axis: axis number being moved
** float value: position of the axis in the range -1.0...1.0
 
= Design considerations =
* Should feel web-native.
** DOM Events were chosen for the first prototype implementation because of the similarity to keyboard/mouse input.
** Whatever API is chosen, it should use standard web idioms.
* Should not expose the user to unnecessary fingerprinting.
** Web pages should not be able to query for the number and type of attached devices without explicit user input.
** Ideally we wouldn't have to use a permission infobar like with some other APIs, the user explicitly interacting with their device while viewing a webpage ought to be enough "permission" to send device data to that page.
** The prototype implementation falls down a bit here, it sends events to all pages that ask for them, should really be just the foreground page.
* Needs to be performant for web games that want to run at 60FPS
** This will need experimentation and testing
** There are assertions that DOM events won't scale to this level, it's possible that the API will need to be changed if that is true
* To be useful, will need some way to map buttons/axes to meaningful values.
** Even the same gamepad looks different on different OSes!
** Across multiple devices this is insanity
** Should try to expose enough info to let content handle this, Kevin Gadd has an "Input Device API" that is higher-level and might be a good fit here.
 
= Discussion  =
 
*Pages will want instantaneous state of device, we might as well expose it (may alleviate polling concerns as well)
**Expose a joyState property on each event, content can hold on to that object and it will update live as input happens
*Not sure about mapping various devices to a sane set of controls
**Going to try exposing a device ID for testing, collect some data and see what it looks like
**Probably a fingerprinting concern, may not want to ship this
**How much do we push to content vs. try to handle in the browser?
**We'll get new try builds and put up a web page to gather data from users with various devices
*Need timestamps per event (using milliseconds like requestAnimationFrame)
*sicking is going to schedule a security review to get some more people thinking about it
*Proposal for a polling based API [https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US] soliciting feedback.

Latest revision as of 18:07, 15 November 2011

Redirect to: