Re: IE implementation of navigator.maxTouchPoints

Thank you Jacob!  Since it sounds like there's no harm in having this
"redundant" code, I think we'll keep it.  It ensures our platform responds
more rationally in the face of any such bugs (even if they were to all be
fixed at some point).

Rick

On Mon, Sep 22, 2014 at 1:38 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

>  They see the IsTouchDevicePresent() logic as redundant (other than it
> just so happens the Win7 bug makes it return false in the one trackpad
> case).  As spec’d/documented, there shouldn’t be a need for the
> IsTouchDevicePresent() code. So it’s really a choice of whether you want to
> have your implementation exploit the bug or not (they’re not likely to
> fix that bug though).
>
>   *From:* rbyers@google.com [mailto:rbyers@google.com] *On Behalf Of *Rick
> Byers
> *Sent:* Wednesday, September 17, 2014 3:54 PM
> *To:* Jacob Rossi
> *Cc:* Sangwhan Moon; Sangwhan Moon; public-pointer-events@w3.org; David
> Bokan
> *Subject:* Re: IE implementation of navigator.maxTouchPoints
>
>
>
> Thanks Jacob.  What we ended up landing
> <https://codereview.chromium.org/563853002> is slightly more involved
> than that - re-uses our existing touchscreen detection logic:
>
>
>
> bool IsTouchDevicePresent() {
>
>   int value = GetSystemMetrics(SM_DIGITIZER);
>
>   return (value & NID_READY) &&
>
>       ((value & NID_INTEGRATED_TOUCH) || (value & NID_EXTERNAL_TOUCH));
>
>  }
>
>
>
> int MaxTouchPoints() {
>
>   if (!IsTouchDevicePresent())
>
>     return 0;
>
>
>
>   return GetSystemMetrics(SM_MAXIMUMTOUCHES);
>
> }
>
>
>
> Does your Windows input team see any problem with relying on this?  We
> have been using this IsTouchDevicePresent code for awhile (took some
> feedback from users to get it here), so using it also in MaxTouchPoints
> seems very reasonable and low risk to us...
>
>
>
> Thanks,
>
>    Rick
>
>
>
> On Fri, Sep 12, 2014 at 5:38 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
> wrote:
>
> Upon further discussion with the Windows input team, it looks like it's
> actually a Win7 bug that SM_DIGITIZER is false in these cases and that it's
> definitely not the case that this represents the difference between a
> touchscreen and a touchpad.  They advised against this using this pattern.
>
> Unfortunately, there is not a way to differentiate rogue touchpad drivers
> from touchscreen.  In Windows 8+, we're encouraging touchpad manufacturers
> to use Precision Touchpad, which enables the same scenarios without virtual
> touch drivers.
>
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/dn467317(v=vs.85).aspx
>
> -Jacob
>
>
> -----Original Message-----
> From: Jacob Rossi [mailto:Jacob.Rossi@microsoft.com]
> Sent: Friday, September 12, 2014 10:49 AM
> To: Sangwhan Moon; Rick Byers
> Cc: Sangwhan Moon; public-pointer-events@w3.org; David Bokan
> Subject: RE: IE implementation of navigator.maxTouchPoints
>
> On Wed, Sep 10, 2014 at 6:46 PM, Rick Byers <rbyers@chromium.org> wrote:
> >
> > Thank you!  Indeed it looks like this is Windows 7 only, and unlike IE
> we do still want to support touchscreens on Windows 7 (a small but
> non-trivial fraction of our touchscreen users are still on Windows 7).  It
> looks like SM_DIGITIZER is false in these cases, so I think we can try
> looking at SM_MAXIMUMTOUCHES only when SM_DIGITIZER is true. Sound
> reasonable to you?
>
> I'm not an expert with these APIs. I have a mail thread with the Windows
> team that builds these APIs asking for advice and any implications of the
> design you suggested. I'll let you know what I find out.
>
> -Jacob
>
>
>