Re: [clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks
On Thu, Apr 23, 2015 at 4:13 AM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and running into some tricky questions I'd like to discuss here. Basically, on Windows IE and other apps that write HTML to the clipboard use the CF_HTML format. This format is simply described as There's some related discussion in bug 137450[1], I wrote a patch for that quite a few years ago (that never landed). In the comments someone pointed out that Microsoft has documented CF_HTML[2] since then, which is nice. -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=137450#c33 2. https://msdn.microsoft.com/en-us/library/aa767917%28v=vs.85%29.aspx
Exposing structured clone as an API?
Has anyone ever proposed exposing the structured clone algorithm directly as an API? Katelyn Gadd was musing about fast deep copy in JS on Twitter, and I proposed a hack to use postMessage to do so[1], which works but it's a little roundabout. Since structured clone is a primitive that the web platform is built on it seems like a primitive that ought to be exposed. I know this exists in other languages (Python has copy.deepcopy[2]) and there's an npm deepcopy module[3] with lots of downloads so this is clearly something people use. -Ted 1. https://twitter.com/TedMielczarek/status/591315580277391360 2. https://docs.python.org/2/library/copy.html#copy.deepcopy 3. https://www.npmjs.com/package/deepcopy
Re: PSA: publishing new WD of Gamepad on April 14
On Thu, Apr 9, 2015 at 5:15 PM, Ashley Gullen ash...@scirra.com wrote: Why doesn't the Gamepad API fire events for button pushes or axis movements? For example when pressing a mouse button or moving the mouse the browser fires mousedown and mousemove. The Gamepad API however requires you to passively poll the state regularly (probably in rAF) and look for changes yourself. Why does it not fire events like gamepadbuttondown or gamepadaxischange? This would have a few advantages: Hi Ashley, We've talked about this at length, and Firefox even includes a prototype implementation of button and axismove events (about:config, search for dom.gamepad.non_standard_events.enabled), but I just don't have the time to spec them out usefully right now and I'd like to finish up spec'ing the already-interoperably-implemented set of stuff that's in the spec right now. Once we get that out the door we can work on useful additions like events. There's a wiki page[2] that already has a list of such useful additions. -Ted 2. https://www.w3.org/wiki/Webapps/GamepadFeatures
[Gamepad] Completing spec work
Hello, The Gamepad spec has been languishing for some time, and I take responsibility for that. However, on the bright side we have two implementations shipping (Firefox, Chrome), and another shipping in previews (IE) that, while not completely compatible, are usable in a compatible manner, which is a great thing. We've had some spec bugs filed as a result of implementors reading the spec, so those clearly need to be taken care of to finish the spec off. Some of them are small corner cases[1,2,3], while one is a fairly large oversight[4] that I've known about and haven't had time to spec (liveness of Gamepad objects). The latter had significant discussion on the mailing list[5] and I know what I need to do, it's just going to require a fair bit of editing to spec it properly. Additionally, I met with some interested parties a few weeks ago at the Mozilla office and we identified a fairly small spec addition[6] that would help content libraries deal with the biggest interop issue that they currently deal with in practice. I would like to spec this as well before calling the spec done. My goal is to sit down and do some spec editing in the next month or two, finish up the remaining issues, and move the spec forward to match the reality of implementations. -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=17309 2. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25203 3. https://www.w3.org/Bugs/Public/show_bug.cgi?id=26203 4. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434 5. http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0238.html 6. https://www.w3.org/Bugs/Public/show_bug.cgi?id=27444
Re: [gamepad] Seeking status and plans [Was: [TPAC2014] Creating focused agenda]
On 10/22/2014 8:08 AM, Arthur Barstow wrote: * Gamepad: Ted and Scott; plan and expectations to get the spec to feature complete state (aka Last Call) and implementation status. Sorry about the late response, I had a vacation in the middle of things there. The Gamepad spec currently has one major issue and a handful of minor issues that prevent it from moving forward. Unfortunately I haven't found time to fix them up, I'm planning on making time in the near future to get those cleaned up. Major issue: Need to spec liveness of Gamepad objects[1]. This was discussed on the list[2] with lots of useful feedback but without really convincing me one way or the other. However, at this point Chrome (and IE's dev preview) have implemented the snapshot behavior, so I think I'm going to write spec text to that effect and change Firefox's implementation to match. A few other minor issues[3] are filed in the tracker, several of which were filed by implementers (Microsoft, Apple) and as such represent real spec issues that need to be clarified to ensure interoperability. Some of them have straightforward answers, some do not. Implementation status: Microsoft has shipped an implementation in their IE developer preview release[4], which I believe means it should ship in IE 12. Chrome and Firefox have been shipping for some time now, and I believe Apple will ship in the near future. The implementations are mostly-compatible modulo the liveness issue discussed above (and probably a few other corner cases including some of the minor issues). Despite these incompatibilities it's quite possible to write code that works across Firefox/Chrome/IE without trouble. Microsoft's own demos work fine on Firefox and Chrome. -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434 2. http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0238.html 3. https://www.w3.org/Bugs/Public/buglist.cgi?component=Gamepadlist_id=34439product=WebAppsWGresolution=--- 4. http://msdn.microsoft.com/en-us/library/ie/dn753843%28v=vs.85%29.aspx
Re: [gamepad] Add an event-based input mechanism
On 10/13/2014 3:03 AM, Chad Austin wrote:
Just as I mentioned in my previous email to this list, I recently was
asked to review the Gamepad API draft specification. My background is
games though I've done some scientific computing with alternate input
devices too.
http://chadaustin.me/2014/10/the-gamepad-api/
I'd like to make a second proposed change to the gamepad API, an
event-based mechanism for receiving button and axis changes.
The full rationale is explained in the linked article, but the summary is:
1) an event-based API entirely avoids the issue of missed button presses
2) event-based APIs don't require non-animating web pages to use
requestAnimationFrame just to poll gamepad state
3) an event-based API could (and should!) give access to
high-precision event timing information for use in gesture recognition
and scientific computing
4) event-based APIs can reduce processing latency when a button
changes state rapidly in low-frame-rate situations
Thanks for the feedback! I think we've been fairly starved for useful
feedback from people with real-world experience. My first implementation
of the Gamepad API in Firefox was solely event-based. The code is still
present in Firefox (it turns out to be useful in testing, if nothing
else), you can enable it by flipping the
dom.gamepad.non_standard_events.enabled pref in about:config. It
generates gamepadbutton{down,up}[1] events and gamepadaxismove[2] events.
I encountered a lot of pushback after making my initial implementation
public indicating that developers wanted a polling-style API, and then
Scott proposed and implemented navigator.getGamepads(), and then I
didn't have the mental stamina to try to figure out the right way to do
events. On the plus side, I think adding events on top of the existing
spec would be fairly straightforward and wouldn't break anything. On the
minus side, someone still needs to figure out what they should look
like. :) Obviously the set of events that Firefox implements is not
great. The gamepadbutton{down,up} events are probably close to what we
want, but gamepadaxismove is terrible.
Right now the #1 priority is getting the existing Gamepad API specified
in an interoperable way, given that we have three
pretty-well-interoperable implementations. I've found it hard to find
the time to finish that spec work up, but I plan to make time in the
near future. Once we can get the currently-implemented bits to CR we
have a list of things[3] that I'd love to tackle for a next version, and
events are already on that list.
Thanks again,
-Ted
1.
http://dxr.mozilla.org/mozilla-central/source/dom/webidl/GamepadButtonEvent.webidl
2.
http://dxr.mozilla.org/mozilla-central/source/dom/webidl/GamepadAxisMoveEvent.webidl
3. https://www.w3.org/wiki/Webapps/GamepadFeatures
Re: [Gamepad] Liveness of Gamepad objects
On 4/30/2014 12:21 AM, Glenn Maynard wrote: My original prototype provided the events mentioned above. The feedback I received was overwhelmingly in favor of a polling API instead[3]. I decided to go ahead with that (actually Scott beat me to the punch and implemented that in Chrome first), figuring we could always spec events in a future revision. (Please try to direct conversations here or to the whatwg list, so everyone has a chance to participate...) If you note the dates you can see that this was well before standardization work started. This was just feedback on a prototype. Supporting polling is a separate issue from whether the Gamepad interface is live or a snapshot. You definitely want to be able to retrieve a snapshot of the current state, and as long as you can do that you automatically support polling. Yes, it's true. In any event, this is going a bit afield. We're not going to spec events for the first version of the spec. We have two mostly-compatible implementations shipping in Firefox and Chrome supporting polling, I'd just like to nail down the remaining uncertain bits of the spec (like the topic at hand) so others can ship compatible implementations. Once that's done we can certainly discuss features for a next revision, there's already a wiki page[1] to gather ideas. (Aside: I'm not sure if the top one is correct. Does getGamepads()[n].index == n, so that gamepadState[i] always corresponds to lastGamepadState[i]? The spec suggests that with index of the gamepad in the Navigator, but I'm not sure. If so, what is getGamepads()[1] if controller index 1 is disconnected, since you can't reorder the later items? undefined?) Yes, Gamepad.index is the index into the list returned by navigator.getGamepads(), so that holds true. If the latter portion isn't answered in the spec I can add some text to clarify: there are allowed to be holes in the array where controllers were removed. I'm not sure what they are in current practice, but null or undefined both seem like legitimate values. -Ted 1. https://www.w3.org/wiki/Webapps/GamepadFeatures
Re: [Gamepad] Liveness of Gamepad objects
On 4/29/2014 10:39 AM, Ted Mielczarek wrote: The only major issue that needs to be fixed in the Gamepad API spec currently is the liveness of Gamepad objects[1]. After reading through the discussion here I'm leaning towards specifying the snapshot behavior that Chrome implements. Regardless of whether we spec an event-based update mechanism in the future, being able to refer to a snapshot of Gamepad state seems useful, and there's not much overhead in calling navigator.getGamepads()[i] instead of referring directly to a saved Gamepad object. My only reservation is that if Gamepad becomes a snapshot instead of a live object, it feels weird to suggest adding output methods to it (like adding vibration support). Perhaps I'm overthinking it, though. Any other thoughts here? -Ted
[Gamepad] Liveness of Gamepad objects
The only major issue that needs to be fixed in the Gamepad API spec currently is the liveness of Gamepad objects[1]. Currently this is implemented differently in Firefox and Chrome--Firefox uses live Gamepad objects, in that you can take the .gamepad property from a GamepadEvent or a Gamepad from navigator.getGamepads(), assign it to a variable, and check its state on every pass through the event loop to get the latest values of .buttons[]/.axes[]. Chrome uses snapshot Gamepad objects, so the Gamepad you get from navigator.getGamepads() is static, and you have to call getGamepads() on every pass through the event loop to get the latest state of the controller. I obviously have a bias towards what I've already implemented, but I can see the appeal of both approaches. With the live approach you can take a Gamepad object and assign it as a property of another object and use it that way, like player.input = gamepad, which makes it easy to manage Gamepad input as part of other code. With the snapshot approach you can easily save an old snapshot so that you can compare two snapshots and see what's changed. (Additionally as an implementation detail this maps very well to the Windows XInput API, which is a polling-based API.) Does anyone have any feedback on which of these seems more natural? Is there any precedent in the web platform to prefer one approach over the other? -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434
Re: [Gamepad] Liveness of Gamepad objects
On 4/29/2014 1:34 PM, Brandon Jones wrote: I don't think that API design should be driven by implementation details, but it may be useful to provide some background on Chrome's Gamepad implementation here: The current polling-only API Chrome uses is largely due to practicality with the multiprocess architecture. The gamepad data is acquired in the central browser process, placed in shared memory, and then polled by the tab processes when getGamepads() is called. This cuts down on a lot of IPC overhead that would otherwise result from constant Hey, Gamepad N changed! messages broadcast to all tabs. Given that, if we decide that the gamepad objects should be live and not snapshots I think that Chrome will probably put a system in place where the first access of a gamepad object property does a behind-the-scenes poll and then does not poll again until control has been given back to the browser. (Which is probably not an issue since many games will be processing input in a rAF loop.) I can't think of any scenario where a forced policy of one update per frame would be detrimental, but I'm open to feedback on the matter. I think what I'll wind up writing in the spec will describe the liveness in terms of tasks[1], which is how web specs talk about the event loop nowadays. Something like changes in the state of the gamepad should queue a task in the task queue to update the state of the Gamepad object. So your proposed implementation would match that exactly, which is nice. This is what we're already doing in Firefox, either by virtue of simply handling input on the main thread, or posting events from a background thread that's handling input. Performance-wise, I think this will wind up being functionally equivalent to your existing implementation anyway--assuming that content is polling navigator.getGamepads() in a rAF loop, you're going to be delivering one state update per frame anyway. If it were my call I'd vote for gamepad objects being snapshots simply because it will add some additional overhead to make them live and it avoid concerns about observing GC, but I don't really object to either design. Anne mentioned the observable GC concern, he said the spec should state that the lifetime of Gamepad objects is tied to the lifetime of the global, which isn't too terrible. (There aren't going to be a ton of them in play anyway.) I agree that having to make an architectural change like this sucks, I wish I had spec'ed it better from the beginning. I certainly don't want to enforce the Firefox implementation as correct just because it's mine, that's why I started this discussion. -Ted 1. http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task
Re: [Gamepad] Liveness of Gamepad objects
On 4/29/2014 7:28 PM, Glenn Maynard wrote:
Gamepad objects should definitely be a snapshot. Otherwise, change
events could only expose the most recent state of the gamepad. For
example, if the user presses a button and then releases it very
quickly (before the down press gets handled by script), and you fire
two change events, the script would never see the buttons as pressed.
This is a good point--if we have live objects then if we do implement
change events we'd need to store the state elsewhere. Firefox has
gamepadbutton{press,release} events and gamepadaxismove events[1][2]
(behind a pref), they actually do this already but it's not fantastic.
(That said, I'm confused--where's the event to tell the user that the
gamepad has changed? Surely this API doesn't require the developer to
poll, which would lose inputs at the slightest GC skip and could never
give high resolution timing.)
My original prototype provided the events mentioned above. The feedback
I received was overwhelmingly in favor of a polling API instead[3]. I
decided to go ahead with that (actually Scott beat me to the punch and
implemented that in Chrome first), figuring we could always spec events
in a future revision.
I'd also be very surprised if I received a Gamepad object and its
values were live--the interface looks like a snapshot.
The interface is...not incredibly consistent because I designed some of
it with the live object model in mind and Scott designed some of it with
the snapshot model in mind.
On Tue, Apr 29, 2014 at 9:39 AM, Ted Mielczarek t...@mozilla.com
mailto:t...@mozilla.com wrote:
snapshots and see what's changed. (Additionally as an implementation
detail this maps very well to the Windows XInput API, which is a
polling-based API.)
You can't just map a gamepad.xButton property to
NativeInputAPI.getCurrentXButton(), because you need to guarantee
that if you read the property twice in a row without returning to the
event loop the result is always the same, even if the button state
changes while the script is executing. You could prevent this by
caching the result and clearing the cache when scripts aren't running,
of course.
I meant mapping navigator.getGamepads to a poll of XInput and
returning the result for each gamepad there, not polling on each access
of .buttons/.axes.
-Ted
1.
http://mxr.mozilla.org/mozilla-central/source/dom/webidl/GamepadButtonEvent.webidl
2.
http://mxr.mozilla.org/mozilla-central/source/dom/webidl/GamepadAxisMoveEvent.webidl
3. https://bugzilla.mozilla.org/show_bug.cgi?id=604039
Re: [Gamepad] Liveness of Gamepad objects
On 4/29/2014 7:35 PM, Oren Freiberg wrote: Originally I was leaning towards live model but I am now leaning towards a snapshot model being the better option. We also found that there was added overhead with making the values live. Having had a few developers play around with both the idea of a snapshot vs live I observed it was much easier for them to add the snapshot approach to their already published games. It also seemed easier for them to conceptual grab the concept I guess because it seemed like a more natural model that fit with their games where at each frame they grab the snapshot to modify that frame then repeat. This is good feedback, thanks. Currently due to the implementation difference users are forced to consume the API as if it was providing snapshots anyway if they want their code to work in Chrome, so settling on a snapshot model would simply codify that existing behavior. We risk breaking content that has special-cased Firefox's behavior or only works in Firefox, I suppose, but the API doesn't have much surface area and hasn't been around that long so that doesn't actually seem all that bad. -Ted
[Gamepad] Future work
Hello, We've decided that the Gamepad spec is feature-complete at this point. We'll be doing some polish work to get it moving to last call status, but new features will be pushed out to a v.next. In light of this we've created a wiki page[1] to gather potential features for a future spec version. If you have ideas for additions to that list the best way to communicate them is to send mail to the list so we can discuss it. Thanks, -Ted 1. https://www.w3.org/wiki/Webapps/GamepadFeatures
Re: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9
On 4/4/2014 8:40 AM, Arthur Barstow wrote: Re testing, are you and/or Scott going to submit tests? If not, is there someone else that can help/lead the testing effort? I don't have any non-Mozilla-specific tests currently, and the Mozilla-specific ones I have are not feasible to use cross-browser. If I get the other spec work (and implementation work) out of the way I can write some tests. The only compelling thing I've seen mentioned that we should address soon is the interaction with systems where the gamepad is also used for controlling the browser UI, such as on consoles, which was discussed recently on the list[2]. By soon, do you mean in v1 or a subsequent version of the spec. Given that it's still a vague idea I am fine with punting that to a subsequent version of the spec. There is one spec bug filed that I know describes an incompatibility between the Chrome and Firefox implementations[3]. It's not terrible for content authors to work around (if their code works in Chrome it will work in Firefox), but we should tighten the spec language to make the expected behavior there clear. I think that's the only thing that absolutely needs doing before we could get to last call status. Given this, perhaps the best way forward is to address this high priority bug before a LCWD is published. I agree. I'll keep this on my radar and try to get it done in the next few weeks. I also think it would be helpful if new features and requirements beyond what is already specified were documented. As I mentioned to Vincent re PointerLock, such features can be documented in a wiki (such as [IDB-Features], Bugzilla, etc. (If you want to use a wiki for v.next tracking, I'm willing to bootstrap it.) Having a wiki to document v.next work would be great, I know we have a few things to put on there right away. If you can put up a skeleton page I'd be happy to fill it out with what I see as topics for v.next. -Ted
Re: [gamepad] Haptic Feedback/Controller Vibration
On 4/4/2014 10:06 AM, Florian Bösch wrote: On Fri, Apr 4, 2014 at 3:45 PM, Kostiainen, Anssi anssi.kostiai...@intel.com mailto:anssi.kostiai...@intel.com wrote: In the initial versions of the spec we indeed considered such reuse. Here's my recent summary: http://lists.w3.org/Archives/Public/public-device-apis/2014Apr/0002.html If you have a navigator.gamepads and a navigator.vibrator how do you know which vibrator belongs to which gamepad? And do you want to end up with a navigator.forcefeedback, navigator.flightPedals, navigator.spacemice, navigator.hapticdevice, navigator.hotas, navigator.thrustquadrant, navigator.artificialHorizons, navigator.radioPanels, navigator.touchscreens, navigator.trimPanel, navigator.missileControl, navigator.steeringWheel, navigator.carPedals, navigator.racingWheel, navigator.gearStick, navigator.joyStick, navigator.etc? And how would you know which of those belong together into one device? This is my last reply to you, because I don't think you're being constructive. Anssi's posts were discussing the possibility of reusing the Vibration *interface* in the Gamepad spec, such that we could declare that Gamepad implements Vibration, and wind up with a Gamepad.vibrate method that works like navigator.vibrate. I don't know if this is what we want to do, but it's worth investigating so we don't reinvent the wheel if we don't have to. -Ted
Re: [gamepad] Haptic Feedback/Controller Vibration
On 3/24/2014 3:55 PM, Florian Bösch wrote: I might point out that haptic feedback devices are alive and well: snip There's a few more outputs than speakers though, for instance: snip I'd note that all of the devices you've mentioned fall way out of the scope of what we're trying to cover with the Gamepad API. I'd like to keep even future direction work pretty closely scoped to things that appear on standard Gamepad controllers. Trying to spec every input device in existence will make the spec unworkable. Spec'ing standard rumble motors that are found on all modern controllers seems sensible. Spec'ing a way to access a microphone/speaker that's present on a controller seems sensible. I think anything more complicated than that is likely out of scope. -Ted
Re: [April2014Meeting] Seeking status and plans from Editors not attending meeting; deadline April 9
On 4/2/2014 7:05 AM, Arthur Barstow wrote: * Gamepad: Ted and Scott; plan and expectations to get the spec to feature complete state (aka Last Call) and implementation status Implementation status: Firefox and Chrome both implement the current ED with a few minor inconsistencies--Chrome has not yet implemented connection/disconnection events, and Firefox doesn't have the timestamp property yet (both are being worked on). Chrome is shipping an unprefixed implementation soon, Firefox should hopefully ship unprefixed in the next release (just missed 28). Microsoft appears to be at least considering implementation, with their new IE status site showing the status as In Development[1]. Plan for last call status: I think we'd consider the spec primarily feature complete at this point. It seems to meet the use cases we intended. There's a lot more that could be added to a future version, but we have two compatible implementations shipping right now so it seems like a good place to stop. The only compelling thing I've seen mentioned that we should address soon is the interaction with systems where the gamepad is also used for controlling the browser UI, such as on consoles, which was discussed recently on the list[2]. There is one spec bug filed that I know describes an incompatibility between the Chrome and Firefox implementations[3]. It's not terrible for content authors to work around (if their code works in Chrome it will work in Firefox), but we should tighten the spec language to make the expected behavior there clear. I think that's the only thing that absolutely needs doing before we could get to last call status. -Ted 1. http://status.modern.ie/#/ 2. http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0515.html 3. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21434
Re: [gamepad] Haptic Feedback/Controller Vibration
On 3/24/2014 1:04 AM, Brandon Jones wrote: Mozilla has played around with gamepad vibration a bit already: https://bugzilla.mozilla.org/show_bug.cgi?id=680289 There's been some mixed messages, but so far the basic idea seems to be to either extend the existing Vibration API http://www.w3.org/TR/2014/WD-vibration-20140211/ to handle multiple motors (and presumably associate it back to a specific pad) or to add a very similar looking vibrate function to the gamepad API. Something like: vibrate(int motorIndex, float intensity); Our primary intention there was simply don't reinvent the wheel if you don't have to. If we can map controller vibration to the existing Vibration API that saves us having to do a whole bunch of spec work ourselves. Given the extra complexity of having multiple vibration motors at different frequencies it may be unavoidable though. I think it's still worth pursuing, we should at least talk to the people behind the Vibration API to see if we can leverage their work. Personally I think that there's got to be a little more to it than that. For one, you'll want to be able to query not only how many motors a device has but have a way of expressing what type of feedback that motor provides (is it a heavy motor, etc.) and possibly some description of it's locality (The Xbox One controller has motors in each trigger, and the Steam controller has motors under each touchpad.) I have no idea how to concisely and robustly communicate that information. This also assumes that the device has simple X-Input style feedback, not the more complicated joystick force feedback that was all the rage in the 90s. (Which is far more complicated and fairly dead, so I doubt it's worth addressing at all.) Figuring all this out is one of the reasons we punted on this. I'd love to come back around to it, but I'd like to get the spec finalized first. As for controller speakers, I see the argument that it's a type of controller feedback, but I don't think it should be conflated with controller vibration. I see them as two very distinct features. It /is/ an interesting feature to consider on it's own, though. Yeah, short of having an actual audio output on the controller (like the Wii remote, or a headset attached to an Xbox controller), exposing rumble as Web Audio seems unnecessarily complex. At the platform level the API tends to be just set this motor to this intensity, so there's a lot of layers of abstraction in between. -Ted
Re: [gamepad] Haptic Feedback/Controller Vibration
On 4/3/2014 12:05 PM, Florian Bösch wrote: Every controller is an assemblage of input and output hardware. It's vastly much easier to to oversee what kind of devices you'll get which are: * Buttons (down or up) * Axes (scalar value) * Rumbles (speed) * Motors (negative/positive force and/or scalar value for position) * Screens (bitmap) * Lights (intensity and/or color) * Touchpads (touch events) * Text displays (text) That's not a monolythic API, that's how every other game controller API in existence on any platform works (like evdev, DirectInput, etc.). The attempt to wrap specific usecases is what is a monolythic monster API that tries to be everything and the kitchensink in the end. Note: DirectInput has been deprecated in favor of XInput, a much simpler API that maps directly to the Xbox 360 controller: http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001%28v=vs.85%29.aspx Trying to design an API that's everything to everyone is extremely hard and likely to produce unsatisfactory results. We chose to focus on the most useful subset of things that are common to all controllers. I believe the API we've spec'ed is useful in spite of not covering everything that exists in the world. I am not opposed to the idea of extending it to cover other common features of game controllers, but I do think we'll stick to concepts that are widely accepted (like vibration) and not bleeding-edge things supported by a single device (touchpads, colored LED). If these things gain traction then it makes sense to discuss spec'ing them. Otherwise you run the risk of spec'ing something that has only one hardware example, thus making the API hard to generalize to other devices that introduce similar (but not identical) features in the future. -Ted
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
Re: [gamepad] Reasoning behind GamepadButton struct
On 2/20/2014 1:35 PM, Brandon Jones wrote: I've been working with the Gamepad API implementation in Chrome recently, trying to bring it up-to-date with the latest editors draft of the spec (https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html). While generally I feel like it's a good update to the working draft I'm puzzled by the decision to change the gamepad buttons from an array of floats to an array of GamepadButton structures. Specifically, it appears to add complexity to the interface and implementation without providing new information to developers. I can see that if a piece of hardware provided custom deadzones on axes which would eventually be interpreted as buttons that it may be convenient to use that to determine the pressed state, but no hardware I know of actually does so. (XInput suggests a trigger deadzone of 30/255, but that's an arbitrary guideline and probably works well for most similar hardware.) If there is concern about input noise providing false positives presses for these types of buttons it would seem pretty trivial for the browser implementation to apply the deadzone internally, and only provide non-zero values above the desired threshold. I made this change to support two major use cases: 1) Analog buttons with known (or at least recommended) threshold values (like the XINPUT_GAMEPAD_TRIGGER_THRESHOLD you mentioned). While it's possible for applications to use an estimate here, it felt better to allow implementations to use API-provided information when available. 2) Controllers with both analog and digital sensors on buttons. The DualShock 3 (and presumably DualShock 4) controllers are like this--they have a separate digital switch and analog sensor on most buttons, so you do legitimately have separate pressed and value for each button. Not supporting this means you're throwing away one of the values. FWIW it looks like Apple has codified this in their Game Controller framework for iOS/OS X 10.9 as well[1], their GCControllerButtonInput class has pressed and value members. I recognize that Mozilla has already implemented the API as described in the editors draft, and I don't want to place additional burden on them to change it unnecessarily. I'm happy to update Chrome's implementation to match, but I want to ensure this is the right direction before I do. It's also worth noting that many of the existing web apps that use the API (though they are admittedly few) expect the buttons to be exposed as floats, and as such updating Chrome's implementation will break these use cases. (New fields like mapping and connected, on the other hand, can be exposed without requiring changes from the app). Right, which is why I felt like now was the time to make this change, before anyone shipped a non-prefixed version of the API. I didn't want to worry about making a non-backwards compatible change in the future when we had consumers of an unprefixed API. Anyone using Chrome's existing prefixed API will have to change to support the non-prefixed version anyway, and it's not much more work to support the GamepadButton change[2]. I apologize if this has been addressed before, as I've only recently started working on the implementation and am not familiar with the full spec history. I haven't seen this particular point discussed in the archives, however, so I figured it was worth bringing up. My coworker Alan sent a mail about the remaining things we wanted to clean up in the spec a while ago, and I filed a spec bug on this issue[4], and we didn't get any feedback either way so I proceeded with it. Unfortunately we haven't got a lot of feedback on the spec in general, I'm hoping that will change as we get more consumers. (Hopefully they don't ask for breaking changes, though!) Thanks for taking on the task of making Chrome's implementation match the latest spec, it's appreciated! -Ted 1. https://developer.apple.com/library/ios/documentation/GameController/Reference/GCControllerButtonInput_Ref/Reference/Reference.html#//apple_ref/doc/c_ref/GCControllerButtonInput 2. https://github.com/luser/gamepadtest/blame/master/gamepadtest.js#L70 3. http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0958.html 4. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388
Re: [gamepad] Seeking status and plans
On 10/14/2013 3:34 PM, Marcos Caceres wrote: Hi All, The Gamepad API was briefly discussed at the LXJS conference. See: http://www.youtube.com/watch?v=ekvaKmVfjtct=5m30s It seems at least one developer is very unhappy with it. Have we received any other feedback from developers about it? Has any effort been made to reach out to other developers to get feedback? Thanks for the pointer. I watched that portion of the video and it's not very constructive feedback. I'll reach out to him (considering he's a coworker) and see if I can find out more specifics. We heard from quite a few developers while implementing the first draft of the API and they were overwhelmingly in favor of the current design. I haven't heard much in the way of feedback from developers actually testing the implementation we've shipped, so it's possible there are issues with it in practice. I'd definitely like to hear more we declare things finished. -Ted
Re: [gamepad] Seeking status and plans
On 10/2/2013 12:31 PM, Arthur Barstow wrote: Hi Ted, Scott, If any of the data for the Gamepad spec in [PubStatus] is not accurate, please provide corrections. Also, if you have any new information re your plans for the spec - last published 29-May-2012 - or the spec's status with respect to being feature complete, implementation status, etc., please let us know. -Thanks, ArtB [PubStatus] http://www.w3.org/2008/webapps/wiki/PubStatus Hi Art, Thanks for the nudge! My work on the spec (and the Firefox implementation) fell by the wayside for many months, but I found some time to work on my implementation recently. We (Mozilla) are shipping a very-close-to-spec implementation in Nightly builds, and it's available behind a preference in our current release (Firefox 24). I'd actually like to ship our implementation in release soon, I just have a few minor implementation bugs (with significant impact) to fix as well as one possible breaking spec change[1]. With those in order I'd be pretty happy to ship. We'd be shipping unprefixed, as is our new policy. It's my understanding that Google has been shipping a prefixed implementation that's also pretty close to the spec for some time now, but that Scott suffers from the same Gamepad is not really my full-time job problem that I do. He'd be more equipped to talk about this than I am, certainly. In terms of feature-completeness I think the spec is basically done. Aside from that one breaking change I'd like to make I don't think there's anything else we want to address right now that couldn't be done in a future release of the spec. We've wanted to keep the scope small from the beginning and I think we did okay. It definitely needs some more work (mostly polishing of the text, fixing the existing bugs), but we could certainly get out a new WD with the most recent text. -Ted 1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21388
Re: controller vibration / rumble
On 8/5/2013 1:11 PM, Tab Atkins Jr. wrote: On Thu, Aug 1, 2013 at 2:31 AM, Mikkel Staunsholm staunsh...@gmail.com wrote: Any comments on that? Should it resemble the vibrations api more (with patterns, and turning it off by setting strength to 0)? Should it be in the vibrations api instead (I don't think so)? Regards, Mikkel Staunsholm @staunsholm PS! I don't know if it is possible/feasible to make rumbling work on osx/linux - fx. JInput doesn't report any ps3 rumblers on osx... It seems pretty clear to me that controller rumbling should be as closely matched with phone vibration as possible. We've discussed this before, and I'm pretty sure we'd rather just use the existing Vibration API exposed via a Gamepad object somehow. If that API doesn't do everything we need then it'd be better to discuss changes in the scope of that spec rather than inventing a whole new API for something so similar. -Ted
Re: [Gamepad] spec status
On 5/2/2013 12:23 PM, Florian Bösch wrote: I'd like to note that the current semantic (in google chrome) of press button to connect device is not very user friendly. Not all buttons register as buttons (some register as axes) and won't do anything. Some devices are also devoid of buttons (like the oculus rift) to press. I believe my current implementation in Firefox allows interacting with either a button or an axis. The downside to that is that it's not great unless you also implement deadzones for axes, otherwise you can wind up accidentally sending input to pages. I don't think devices like the Oculus Rift are in scope for this spec, we've explicitly stated that we're only attempting to spec interaction with gamepad devices that are comprised of buttons and axes. -Ted
[Gamepad] spec status
Hello there, The Gamepad spec hasn't seen a lot of activity lately, and it's primarily my fault. I got tied up in other work and didn't have time to work on my implementation in Firefox or the spec. I dug out of that and managed to land an initial implementation which is currently available in Firefox nightly builds, and I've been making small changes to the spec to clean up some issues. While fixing up my implementation to match the spec and testing vs. Scott's implementation in Chrome I've found a few spec issues that we'll have to work through. I'll detail these in separate emails shortly. I'd like to get both the spec and my implementation into a shippable state in the very near future, so I don't want to add any significant new features. I'd just like to clarify and tighten up the language so we can be sure to ship interoperable implementations and also not make future spec work difficult. Regards, -Ted
Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15
On Wed, Sep 26, 2012 at 10:27 AM, Arthur Barstow art.bars...@nokia.com wrote: * Gamepad - Scott, Ted - what's the status of the spec and its implementation? We probably need to discuss a bit more, but I think the spec is pretty close to a first version. The one large issue that we haven't tackled yet is how button layouts should be described. Scott and I have talked about that a bit, but we need to nail it down. I'm reasonably happy with the rest of it, I think there's enough there to be useful without wandering off into more complex territory. AFAIK Chrome has shipped an implementation. The Firefox implementation is hung up in review still because it's been a side project for me. I'd like to get it landed in nightly builds soon. -Ted
Re: [gamepad] Polling access point
On Thu, Jul 26, 2012 at 9:20 PM, Scott Graham scot...@chromium.org wrote: There's no particular indication at the spec level to indicate stopping the gamepad polling, based on the assumption that it's an implementation detail. Maybe there should be some way for content to hint that though? I guess an implementation could timeout and shutdown background resources if the content does not request data for some amount of time too. I was thinking that this isn't much different than the use case in the geolocation API spec[1]. Perusing that spec shows that it has watchPosition / clearWatch APIs for explicitly registering/unregistering for location updates. I don't know if I particularly want to add an API like that, but conceptually we might want something like that. In my current implementation in Firefox, the background polling is triggered by the page adding event listeners for one of the DOM events. I don't recall offhand if unregistering for the events stops the polling, or if it takes having the document unloaded. -Ted 1. http://www.w3.org/TR/geolocation-API/
