Re: 2 proposals for stylus support. Extend range of Touch.rotationAngle. Add Touch.tilt

Hi Denis,
Thanks for joining the discussion here!  I'd love to have Samsung involved
in this group.  Another related topic we should discuss some time if you
(or a colleague) is interested is how the touchscreen hover capabilities of
the S4 should be exposed to the web (we've got a simple prototype
implementation <http://crbug.com/418188> in chrome already behind a flag)

Some relevant context for others in the group: Android stylus users expect
applications / websites to respond to their stylus as they do for touch by
default (eg. dragging sideways with the stylus on the home screen switches
pages, just like it does for touch).  Some Android apps light up to treat
stylus differently, but for the most part it's treated like touch.  For
this reason, android browsers (Samsung's browser, Chrome and Firefox are
all that I've tested) send touch events for stylus input.  Even if we end
up sending something new like pointer events in the future, we'd still need
to send touch events for compatibility for the foreseeable future.

See inline

On Thu, Jan 22, 2015 at 8:53 AM, Denis Pikalov <
d.pikalov@partner.samsung.com> wrote:

>  Hi,
>
>  As mentioned http://crbug.com/393462 about SPen: "...It's reasonable for
> an application to treat stylus input slightly differently from touch input.
> Ideally all details in Android's MotionEvent  would be available to the web
> application... we should consider trying to standardize some additional
> properties on TouchEvent for this..."
>
> We agree, and we have been working to enable some feature we consider
> important.
> Please let us know your opinions about proposals below, which may make
> sense for stylus-type pointers:
>
> 1. Extend range of Touch.rotationAngle up to 360 degrees (to support
> oriented pointers).
> TEE defines only 90 degrees range for rotationAngle - due to symmetry,
> this is enough to define orientation of touch-ellipse, but we think, it
> makes sense to extend the range up to 360 degrees - and reuse this property
> to report orientation of pointer itself, if supported.
> Currently, orientation supported by samsung spen, at least.
>

I definitely support this.  Even outside the stylus use case, it's not
unreasonable that some "touchscreen" devices would be able to accurately
determine finger rotation (eg. by using hand/finger detection above the
surface of the screen).  I see no reason why the extension should be
limited to 90 degrees (but we should have a note saying that in practice
many devices won't be able to report the full range).

2. Add property Touch.tilt
> Tilt can be defined as angle (in range 0..90 degrees) of the stylus away
> from the perpendicular to the screen. Normal use-cases are - advanced
> drawing applications,  like http://goo.gl/jYExOt. Hardware support – yes,
> at least Note4 (+spen) supports tilt currently.
>
Patch for Touch.tilt: http://crrev.com/750013004,
> Tilt API:
> http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_TILT
>

If others in the group are OK with adding stylus-specific properties to
touch events, then this sounds good to me.  I guess in theory this could
represent the position of a finger as well (again with hardware that can
see / sense the finger above the surface), but I'm not sure anyone is doing
that in practice.  Perhaps the S4 technically has this ability?

I'd like to make sure we define these in a way that's easy to map to/from
the definitions in the PointerEvents spec
<https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEvents.html#pointerevent-interface>,
so that implementations of pointer event polyfills can have full fidelity
(and libraries/frameworks can use whichever API they find more
convenient).  There they use 180-degree tiltX and tiltY.  90-degree tilt +
360 degree rotation as you've requested here should be easy to map to/from
that definition, right?  In your definition, I assume stylus rotation is
meaningless when tilt=0, right?  If we add this, then we should probably
include a note with the necessary formula to map between the two
representations.

--
> Denis
>
>