-
Notifications
You must be signed in to change notification settings - Fork 381
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Format of Gamepad identifiers #550
Comments
I agree with @NellWaliczek that the name should be unique and if we are going by the route of human readable string (which I personally like), then besides - there should be, probably, added a model name or something like that. For example, Oculus Touch controllers: those exist in two versions, one for Rift and another for Quest, both named "Oculus Touch". The buttons mapping is the same (with one caveat - there is not touch sensitive thumb rest, but we still can report it for compatibility). So, to identify such controller we'd need either to change the "product-id" to something like 'touch2' or add a , i.e.: oculus-touch-quest and oculus-touch-rift (for example; or oculus-touch-1 and oculus-touch-2). In this case, we still can use the substring 'oculus-touch' to identify the buttons mapping and we also have enough info to determine which GLTF to use to render the controllers. |
That's a really excellent point about the Oculus Touch branding spanning device, I hadn't considered it before. Thank you! Of the examples you gave, I personally like In that light, maybe the appropriate pattern is something more like |
Not super useful feedback but I also personally prefer the human readable string. |
Follow up to this based on a conversation we had while investigating Chrome's implementation, and pulling from the discussion above. It seems like there's two tiers of information we want communicated in this string. The first is button layout. This strikes me as the most important thing we need to communicate, because a fair number experiences will use custom controller models but they'll pretty much all want to have a better understanding of the button data. Furthermore, this is data that can be less specific while still having a large impact, because we already see several instances in the ecosystem where multiple controllers with physical differences still make use of the same button layout. Examples include Windows Mixed Reality controllers (where the Samsung version is subtly different, but the actual controller functionality is identical.) and Oculus Touch (where the Quest and Rift S have a different design but are functionally equivalent to the touch controllers on the original Rift.) The second tier of information is the actual physical model of the controller, which is primarily to inform the model used for rendering. This data is, by necessity, more detailed (and thus more fingerprint-worthy) but also more narrowly in it's utility. As a result I view it as being of slightly lesser importance than the layout data, although the ideal scenario is of course that we provide both. Additionally, we've discussed elsewhere (such as on the calls) that when we've established a controller registry (as described in #578) we probably want to include something in the id that indicates that the gamepad data conforms to a registered device mapping. So, putting all of the above together, I wonder if we want an id layout that looks kind of like this:
The layout is a high-level indicator of what the button mapping is. For example, every Windows MR headset could use an ID of If the model CAN be identified, then the returned string should strive to be as precise as possible about the device, using something like a vendor/product ID when it can. So something like Finally, if the device has an official registry entry the associated ID gets appended to the end like |
Thanks for pulling together your thoughts here! I agree with your analysis that button layout and model are the two primary tiers of bucketing that apps are likely to need to do:
Regarding Given that we won't have an explicit negotiation API here to absorb the compat risk, it may behoove us to optimize for minimal churn as controllers graduate into the registry and skip |
Fixes #550 Describes how the layout and model of a device should be encoded into the gamepad.id. Does not add a registry identifier yet because we need to establish the gamepad registry properly before that can be accurately documented. Also: I finally got to use Bikeshed's railroad diagram feature! Toot toot!
Whatever mechanism we come up with will be most stressed when new input devices are released. For example, it seems likely that in at least some cases:
In addition, third-party lower-volume input devices may be released, and it would be nice to enable users with such devices even if user agents are slow to or do not add support. (Exposing the VID-PID where possible is one way to allow user space to deal with this, but it raises privacy/fingerprinting concerns. Another option might be to expose a raw value from the runtime.) Some other things to consider:
|
tl;dr: I propose the following for discussion:
Much of the difficulty in constructing the string is the limitation of the single In addition, moving the mechanism to
Separating the two also also helps avoid ambiguity. For example, looking at the example in PR #652, what if there was a device not called Oculus Touch that used the In addition, the clear divide would make it easier for users or user agents to choose to not expose the exact controller to minimize fingerprintability while maintaining functionality. For example, if a user has a low-volume controller that is functionally equivalent to the Vive controller, this button layout could be exposed without exposing that the actual controller is the Acme Handifier.
Using separate fields off of |
I really like this suggestion of not overloading the Gamepad.id field, @ddorwin! A few questions:
|
|
Some initial thoughts regarding the registry (#578) / registry ID mentioned above:
|
Follow up from F2F: The Working Group collectively decided that something like David's proposal was a better way to address this, so I'll close down the previous PR for this issue and spin up a new one. Thanks all! |
Further follow up: Chatted with David about the proposal a bit more. Primary concern was that it wasn't clear if simply having a single "fallback" value for the button layouts and model would really be sufficient. Seems like having a sequence of possible mappings in order of descending preference would be more flexible. That would allow developers to easily iterate through the array looking for the first string they recognize, which should in turn be the closest approximation to the actual device that their code can actually support. For example:
This would communicate that the device is ideally rendered as the controller for a Samsung Odyssey+ (assuming that it has any material differences from the base Samsung headset controller, which I don't think it does, but let's not let that get in the way of a good example!) If that model isn't available, though, then the previous gen Samsung controller is fine, and if that's not available then it'll still be close enough if you render it as a generic Windows Mixed Reality controller. Layout identifiers would work the same way, though I'd naturally expect there to be less variation in those. It would be really useful for developers of hardware on a smaller scale, though, to gain broader software support. "I'm technically a Of course, only exposing a single value is always OK, and we should generally set expectations that this array shouldn't be more than 2-3 entries long, because if it's bigger you're likely doing something wrong. Related, it's not clear if exposing some sort of So taking all of that into account, I'd suggest that the relevant IDL would looks something like this: partial interface XRInputSource {
readonly attribute FrozenArray<DOMString> modelName;
readonly attribute FrozenArray<DOMString> gamepadLayout;
} |
Thank you for the nice summary! With that out of the way, we can bikeshed. :)
When picking names and describing the attributes, we may also want to consider what it would mean to add raw value. For example, as we discussed, the order of the arrays may not necessarily be in order of specificity but rather the order in which the application should (the user user agent wants the application to) check. (As an example, if the raw value is added to the end, that's because it should be the last fallback not because it is the least specific.) For future reference, when discussing whether raw value should be first last, we discussed that first may make sense because it is the most specific but that last might be better because applications shouldn't use that unless absolutely necessary. In addition, applications might become dependent on that value if it is first, which could cause them to break on implementations that choose to not expose such values, such as for privacy reasons. |
Fixes #550. Removed any logic regarding using the gamepad id for rendering or layout identification. Introduced the `renderId` and `gamepadLayout` attributes to `XRInputSource` in it's place.
PR #695 is now up to address this issue, for all your bikeshedding needs. ;) |
Fixes #550. Removed any logic regarding using the gamepad id for rendering or layout identification. Introduced the `renderId` and `gamepadLayout` attributes to `XRInputSource` in it's place.
Fixes #550. Removed any logic regarding using the gamepad id for rendering or layout identification. Introduced the `renderId` and `gamepadLayout` attributes to `XRInputSource` in it's place.
Fixes #550. Removed any logic regarding using the gamepad id for rendering or layout identification. Introduced the `renderId` and `gamepadLayout` attributes to `XRInputSource` in it's place.
Fixes #550. Removed any logic regarding using the gamepad id for rendering or layout identification. Introduced the `renderId` and `gamepadLayout` attributes to `XRInputSource` in it's place.
Fixes #550. Removed any logic regarding using the gamepad id for rendering or layout identification and introduces a `profiles` attribute to `XRInputSource` in it's place. The `profiles` is a list of identifiers in descending order of preference that allows for sensible fallback behavior for newer or less common devices.
I wanted to separate this discussion out from the rest of the gamepad-as-the-input-solution work, because it's a reasonably complex topic on it's own.
To recap a bit of the prior discussion here, first off there's some guidelines that we've already set that should be considered (taken from #499):
id
MAY be'unknown'
if the type of input source cannot be reliably identified or the UA determines that the input source type must be masked for any reason. Applications should render a generic input device in this case.id
s of'unknown'
.id
must be a lower-case string that describes the physical input source.oculus-touch-left
), as that can be determined from thehandedness
attribute.Beyond that, I had previously had text that said "For most devices this SHOULD be of the format
<vendor>-<product-id>
. For example:oculus-touch
." But this is an unfortunately loose guideline and could result in manual work being done by the UA to expose every device. Ideally we would want a system that surfaces a name provided by the underlying platform with minimal modification.To that end @thetuvix had previously suggested we use something like the hex representation of USB vendor and product IDs, resulting in strings such as
045e-065d
. That's not human readable, but at least it's automated and consistent. My primary concern with it, however, is that not all platforms will surface their input devices in a way that provides access to USB metadata like this (and depending on the OS/device it may not have said metadata at all.)Some of the native APIs have built-in methods for exposing device identifiers of various forms. For example, in OpenVR you can query a "Prop_RenderModelName_String", "Prop_ModelNumber_String", and "Prop_ManufacturerName_String". Given that we expect to have multiple different devices exposing themselves through such and interface it would make sense to use those. However, that could run into some issues if, for example, the strings they use for an Oculus Touch are different than what's reported when using the Oculus API directly. Also, if the strings reported from the API have the device handedness baked in it would be difficult to scrub that out in a consistent and safe way.
Finally, some APIs may not report a device identifier at all, since there's assumed to only be a single type of controller that they'll be used with. In that case we don't have to report
unknown
since we would know what the device is, but it'll be up to the UA to make up a value.I don't have any great suggestions for this aside from suggesting we just do
<manufacturer>-<model>
, pull those values from the API whenever possible, and if the best way to consume them is USB IDs then so be it. This is effectively the approach that Nell has been taking to the names in the Gamepad Mappings repo thus far, if you want an idea of what that would look like.Any suggestions to allow this to be more automated/consistent are appreciated!
The text was updated successfully, but these errors were encountered: