<ada> Hiya everyone!
<atsushi> good morning!
<Manishearth> https://github.com/immersive-web/webxr-gamepads-module/issues/23
<Manishearth> https://github.com/immersive-web/webxr-input-profiles/issues/105
Ada: Welcome! At the bottom of the agenda email there is a list of issues that are in the pre-CR issues and are the last blockers before CR. If anyone would take up an issue that would be a big help toward the goal of CR.
Ada: Starting agenda item about whether hands should be presented with a gamepad.
Manish: This isn't about exposing articulated hand support, that will be a separate spec with a hand object or similar. The current question is on the hololens et al you can click and grab and they should trigger select and squeeze events. The question is whether non-physical objects should have a gamepad object with input mapping.
Manish: One argument that the gamepad is supposed to be for physical gamepads. Another is that it's nice for one API to expose these very similar events. Hands will definitely trigger grap/squeeze etc but should they have a gamepad object? Also, should there be a generic hand profile?
Brandon: One thing I wanted to point out is that this has ramifications beyond hands. Chrome currently exposes cardboard style inputs without a gamepad, it only is an input source with select events. If we say that the hands should have gamepads then it probably makes sense for cardboard, as well, despite it being captures by the single event. That's not my preference but I understand why it could make sense. Or, if we want to carve out
hands as special.
Alexturn: Part of having select and squeeze events is to create a viable path without gamepads. I'm more comfortable with cardboard not having a gamepad because more middleware will handle the non-gamepad case. I was worried that hands would be the only exception and so unsuported so many pages wouldn't know how to handle inputs without gamepads. I want to avoid hands emulating the gamepad because all of the pages assume their existance.
Brandon: The other thing that the events exist for is the user activation event. So, playing back media you're going to want to use those events and not just gamepad events.
Artem: I don't see anything wrong with exposing gamepads on hand objects however we're more interested in full hands API as Manish mentioned. Oculus is introducing hands tracking for Quest so without hands representation it's super confusing. You can do gestures but you don't see your hands. I'm afraid of forgetting about the full hands API because this support (hands with gamepads) exist.
Nell: The main question I have is that currently generic input profiles (not specific to Quest, hololens, etc) at the minimum if we expose the gamepad object then what is the minimum conformance for the gamepad object? Is it trigger, touchpad, etc... Are folks suggesting a similar namespace for hands? Or, are they expecting hands having input at gamepad.0 or 1. What does conformance for hands' gamepad objects look like? If I can't know
from the profile, it's not a good situation.
<Zakim> alexturn, you wanted to talk about semantic vs. physical hand mappings
Alexturn: I can speak to what OpenXR and by extension WebXR. We're exposing physical hands with select and squeeze actions. You can have a select and squeeze path with names that overlap with controllers. So, for WebXR where we put slot 0 and 1 with select and squeeze events then they'd map to select and squeeze to a hand. So, conformance to "generic hand" would be select and squeeze in the same slots on the gamepad. Separately you could
use articulated hand joints and render a hand.
Nell: Are those expected to be analogue data? So gamepad.0 would be interpolated between 0 and 1?
Alexturn: They would be floats.
Nell: Artem, does that align with your expectations?
Artem: I think it will be 0 or 1.
NellWaliczek: The trigger and squeeze are the two you could support?
Artem: One is select and one is "exit from VR" so I'd need to check on other gestures.
NellWaliczek: So it may be that generic hand can't assume the squeeze so what does that imply? Different profiles?
alexturn: I would imagine more common would be grab-and-move so it would be good ot know beforehand to know whether platforms will support it.
NellWaliczek: So maybe we need several generic profiles for hands. Could you put comments in the relevant issue so we can get spec text and the registry updated? Artem, could you make a PR with your changes?
<Manishearth> https://github.com/immersive-web/proposals/issues/48
Manishearth: I wanted to mention that there's a proposals issues for articulated hands. If you're interested please comment there.
<Ravi> hi, Ravi from Magicleap, we would like to get back on GitHub with respect to generic events for hand gesture
(linked above)
<NellWaliczek> Thanks, Ravi!
Alexturn: Artem, please follow up with Oculus hand tracking forks to know whether squeeze will be supported.
Brandon: I thought airtap and bloom are the two Hololens gestures.
alexturn: We'll support WebXR so additional gestures are possible.
NellWaliczek: Are we aware of devices with hand support but no controller support?
alexturn: It could be true for Hololens.
NellWaliczek: I wanted to know whether there would be no controller fallback.
alexturn: Yes, on Hololens.
<Manishearth> https://github.com/immersive-web/webxr/pull/900
Next agenda item: User permissions API for feature requests
Manish: This PR uses the permissions API underneath so it simplifies logic and lets us use the features the platform exposes.
NellWaliczek: A quick question for Mounir. What does "running out of time" in your review comments.
mounir: I was just saying that I had to leave that day.
NellWaliczek: Ok, great that it's not more existential.
Brandon: Currently we return the granted features and I know that's something we've asked about in the past. What is the use case for that. Does anyone on the call looking for a way to query for that?
Manish: We had some issues with concrete uses. I think #722.
NellWaliczek: You want to know whether there are developer use cases for querying a current session for its granted capabilities?
Brandon: Yes, if I ask for this in an upcoming permission am I going to get a prompt?
NellWaliczek: A Sumerian customer may want to put up a more contextually relevant message about the feature that was declined but I don't think we can check whether it's declined or just not supported.
NellWaliczek: I need a way I can detect it so I can tell the user that it's not available.
Brandon: Looking at current features (reference spaces) there's an alternate way to determine whether it's supported. It's not clear whether that's true for future features. It would be potentially useful to differentiate between denied and not-available.
NellWaliczek: It's possible that future APIs will return different values for refusal and never-available so our customers will want to know that.
Brandon: Thank you, that adds context.
mounir: We are exposing granted features. If it's denied we won't tell you what was denied. I wonder if that will be solved by repeated requests to determine which ones are denied.
mounir: It's not clear that browsers would make that granularity available to users. It feels like we have a feature from the device which isn't the case. Asking for permission status doesn't help at the moment. I expect every browser to return everything.
NellWaliczek: Could you clarify? I understand asking for each feature to determine whether it's available.
mounir: The permission API won't expose whether the device exposes the feature. It exposes whether the UA allows the feature.
NellWaliczek: I don't care whether it was declined or not possible. With the features we have today you can request them and then check if they are available. Perhaps we need to put guidelines in the spec that features that are required or optional must have a way to query whether it is available.
mounir: Yes, that's important to features. We should not have request session shaped differently just for that. That should be a separate API from permissions.
NellWaliczek: Let's be sure that guidance is in the spec text for future features.
mounir: Sure, that is in general a web principle.
<Zakim> alexturn, you wanted to talk about eye tracking as such a feature
alexturn: I wanted to mention eye tracking as a future feature with above average privacy impact. You may then want to be in an env with the headset but then enable eye tracking. If the app wants to enable it then it needs to explain beforehand why it will request the permission.
alexturn: So, apps will want to know whether it has been / will be refused or whether it's not ever possible.
NellWaliczek: We didn't spec how the permission prompt would be displayed, so it could be in HMD or on a separate screen, for example.
alexturn: In addition to upgradability there would be this addition query to know how ot manage the request.
klausw: This may be a short conversation. The way the spec was written it says the input source needs a primary action which seems over-prescribed. Vive trackers may have input-less auxiliaries. A separate topic would be touches on an input device then they may or may not count as primary inputs and may or may not generate mouse events.
klausw: So, the spec is currently more specific than it needed to be.
NellWaliczek: The background is that the things noted are intentional but perhaps not right. When we looked at it we excluded things like the vive trackers because we didn't want over-broad category. So, Vive trackers could be a space not an input source. Given that we don't do that yet, what does it mean for other sorts of tracked spaces and consistency for how they're reported? A future tracker like an image tracker would fall into a
different category.
NellWaliczek: So, we wanted ot exclude things without a primary input source. We received feedback that things like screen touches should have primary and secondary inputs.
NellWaliczek: I'll review this, thanks.
bajones: I remember Nell's recounting of the history the same way. That may not have been the right decision, we have more context around the decision now for things like finger tracking and screen-based sessions. The Vive tracker is useful but a weird case. The trackers are used as alternative inputs, either by strapping them to their joints for skeleton tracking or they'll put an AR-15 controller with a tracking puck on top.
<Zakim> NellWaliczek, you wanted to ask about the profile id
bajones: There's really no way to differentiate between the two uses (skeleton / controller) as Vive assumes a bespoke app using the trackers that makes its own assumptions. Looking at touchscreens maybe does point toward separating it out. Maybe if the device has at least primary input then it can be an input device.
<ada> am i frozen?
NellWaliczek: The one question about Vive trackers would be what the profile ID would be. We don't have a profile ID for generic "no data given". What do people think it should report?
bajones: The Vive puck is capable of reporting All The Buttons or none and we can't know.
NellWaliczek: If we report the pucks we need a sense of conformance but I don't know what that would be.
klausw: I don't have an urgent use case for pucks. This was motivated by the finger side of things. Having alternate channels other than input sources would work but we don't have that now. Maybe we don't need to solve it now but I wanted to check whether we purposefully made it so specific.
<Zakim> kip, you wanted to mention that one use case could be for accessibility
kip: A quick sidenote: Two use cases are for accessibility for input for alternate means like a puffing (blowing into a tube) or something without gestures but allows visualization of something in space so the user can safely stand in the space.
bajones: That use case is awesome. 🎉
bajones: In terms of trackable objects that aren't inputs, most of the native APIs that have that they just stuff them into the input APIs anyway. A vive puck would show up in the OpenXR input system. We might want to make a distinction I suspect we'll be fighting the native systems a bit.
<Zakim> NellWaliczek, you wanted to ask what openxr is using for profile ids?
NellWaliczek: There is a question about OpenXR that maybe alex could answer. What are the pucks reported as in OpenXR?
Alex: That hasn't been solved.
NellWaliczek: Maybe we shouldn't address it yet, too. Klaus, maybe the spec shouldn't address a puck (or device without primary action) so we're not blocking the changes in flight.
bajones: We can spec out with multi-touch without endorsing one way or another additional tracked objects.
Ada: Think we're near the end of the call. One last minute news item: please look at the help-wanted issues listed in the email, particularly in the pre-cr milestone.
Ada: The other thing I wanted to note is that in February we're thinking about another face-to-face, probably in Seattle and probably on Feb 12th & 13th. I'll send out more information when we have a venue. If there is a Seattle-area person who could volunteer a venue please contact cwilso or I.
Ada: Any other topics?
Meeting complete!
<kip> puck
Maybe present: Ada, Alex, Artem, bajones, Brandon, klausw, Manish, Nell