Re: Some comments about Pointer Events

On Tue, Nov 20, 2012 at 5:02 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
>
> |  Can you give me a "for instance" for you proposed approach?
>
> I already did: The Samsung SPen Android APIs returns
>    - 0 when no contact
>    - 1 when normal pressure (or when there's contact with the finger)
>    - any positive number proportionnally to the normal pressure
>
> However, their documentation says that the "expected" range is usually 0-1 (but that if the user modifies the pressure settings it's possible to get the stylus to work in a [0-0.5] or a [0-2] range instead).
>
> So, to put things in perspective, it seems that the "normal value" of most styluses is their "maximal" value (unless they have been reconfigured to be less or more precise).
>
> My recommendation would then be to specify that the value returned by "pressure" is unrestricted (apart from being positive) but is -likely- to lay in the [0-1] range. However, some styluses + driver configurations may end up with results higher than 1.0 (for example if the user increased sensibility and didn't check 'clamp values at 1'). Maybe that use case isn't very well spread for now (and maybe some UAs will ignore values higher than one and clamp them) but at least an UA (that wants to support a specific kind of input device that can have a "hard pressure" mode) can do that and still respect the specification.

I support this notion - in particular that 1 indicates "normal" or
"expected full" pressure but larger values are permitted.  I think it
will be effectively impossible to achieve precise and consistent
semantics across OSes / devices, but I'd still like to see UAs have
some ability to try to provide a normalized value where there is at
least two reference points (no pressure, nor normal/full pressure).

We hit this with the touch events spec on Android.  Touch events [1]
says: "a relative value of pressure applied, in the range 0 to 1,
where 0 is no pressure, and 1 is the highest level of pressure the
touch device is capable of sensing;".  I discovered [2] that it was
possible to get values above 1 on Android.  This value comes from the
Android MotionEvent.getPressure API, which the documentation states
that the value "generally ranges from 0 (no pressure at all) to 1
(normal pressure), however values higher than 1 may be generated
depending on the calibration of the input device.".  So there's no
great way to fix this spec violation - either need a complex
auto-normalization algorithm, or more likely just clamp discarding
potentially useful information.

[1] http://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#widl-Touch-force
[2] https://bugs.webkit.org/show_bug.cgi?id=91799

>
>
> Also, I would prefer if a device that doesn't support pressure could return '1' instead of '0' when it's being pressed down. Alternatively, we could use a 'supportsPressure' property. Or we could do both.
>

Received on Tuesday, 20 November 2012 14:22:46 UTC