Re: Distinguishing input from multiple users

Thanks Sangwhan.
I do think we  should do something here, probably combined with
enumeration/query APIs (eg. how many touchscreens are there, and how many
contacts do each support).  It's not clear to me how we'll want to do this
in full - eg. a deviceId on the PointerEvent and then additional APIs that
operate on device IDs, or an API for looking up the device ID for a pointer
ID.  So my preference would be to defer to v2, but I don't have strong
feelings about it.

For the WiiRemote scenario, would you expect it would use a custom
pointerType, and would each 'device' have exactly one pointer?  If so, then
it seems like an app would need to know that for your pointerType, each
pointer is a distinct user (in contrast to touch for example), and having
deviceId wouldn't add much, would it?  Multi-user multi-pointer input would
definitely be a problem though.  Or maybe the problem is that you'd want
sites to work without knowing about Wii remotes in particular - if so I'm
not sure how that would work.

Rick



On Tue, Mar 26, 2013 at 9:03 AM, Sangwhan Moon <sangwhan@iki.fi> wrote:

> Just to clarify - sorry for not being explicit, this is not a LC comment -
> nor do I think this should be a v1 showstopper. The added complexity just
> to get the device ID right on all platforms is probably not worth the
> hassle to be forced into v1.
>
> The specific use case I had in mind was for HTML games on a console (or
> PC, TV) - as I've seen a [1] workaround implementation possibly due to the
> very reason that there wasn't a standard that could be readily used.
>
> (Although as with all software "let's do it later" also tends end up being
> "let's not do it ever", but let's imagine that won't happen)
>
> The [2] Gamepad API has this concept - although it's a bit more complex -
> but it shares the idea.
>
> --
> Sangwhan Moon
>
> [1] http://my.opera.com/Vital/blog/the-wii-remote-api
> [2] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html
>
>
> On Tuesday, March 26, 2013 at 11:55 PM, Rick Byers wrote:
>
> > Sangwhan, can you elaborate a bit on the scenario you see this being
> useful in? Adding a deviceId to the event (or some other mechanism to
> correlate pointers to devices and get information about those devices)
> seems like it could be handy, but I'm wondering if this is something we'd
> really want to try to get into v1.
> >
> > No existing input API has this, right? Are there examples of real-world
> sites that are hurting as a result?
> >
> > Thanks,
> > Rick
> >
> >
> >
> > On Mon, Mar 25, 2013 at 7:29 AM, Scott González <
> scott.gonzalez@gmail.com (mailto:scott.gonzalez@gmail.com)> wrote:
> > > I like the idea of having a device id associated with each event. I've
> also heard requests to be able to listen for when a device is
> connected/disconnected.
> > >
> > >
> > >
> > > On Sun, Mar 24, 2013 at 1:54 AM, Sangwhan Moon <smoon@opera.com(mailto:
> smoon@opera.com)> wrote:
> > > > In the specification as of today, there is no reliable way to
> detect/associate
> > > > input from multiple users - as PointerEvent.pointerId is the closest
> thing that
> > > > can be used to detect such a thing, which sadly doesn't guarantee a
> reliable
> > > > pointerId to user mapping.
> > > >
> > > > I see two approaches for resolving this:
> > > >
> > > > 1) Re-define PointerEvent.pointerId in a way that:
> > > > - How indices are generated and reserved for non-mice is normative,
> so it
> > > > can heuristically map to a specific input device.
> > > > - Indices are not recyclable.
> > > >
> > > > (and possibly add the concept of "available pointers", or redefine
> "active pointers")
> > > >
> > > > 2) Add a new deviceId member in the PointerEvent interface.
> > > >
> > > > (and possibly add methods to enumerate available devices)
> > > >
> > > > I'm not sure which would be the best way to handle this, although I
> am a bit
> > > > skeptical about the first idea as detecting the device will possibly
> leave corner
> > > > cases where the heuristics may fail.
> > > >
> > > > --
> > > > Sangwhan Moon, Opera Software ASA
> > >
> >
>
>
>
>