- From: Rick Byers <rbyers@google.com>
- Date: Tue, 26 Mar 2013 07:55:45 -0700
- To: Scott González <scott.gonzalez@gmail.com>
- Cc: Sangwhan Moon <smoon@opera.com>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
- Message-ID: <CAFUtAY87b02851LR0jqTGuohTO_Y4KuPPd4qk0O2M4g0X4qN7g@mail.gmail.com>
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>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> 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 >> >> >> >
Received on Tuesday, 26 March 2013 14:56:32 UTC