[Development] Extending touch semantic information and Qt backends

[Ariel Molina]

Further investigating i just read:
https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt

Which is a good read about the status of multitouch in the Kernel, moreover
it explains the type of objects to be reported which are divided non
identifiable and identifiable objects.

Moreover it explains about blobs, it's touching ellipse and orientation
(rotation) and even goes as far as talking about hover events.

Ariel



On Thu, Feb 11, 2016 at 12:33 PM, Ariel Molina <ariel at edis.mx> wrote:

> Edward,
>
> I strongly agree with your analysis. Any generalized touch (marker,
> finger, pen) has a general elliptic shape defined by a rectangle, when a
> device does not support that info, touches are just degenerate squares 0 by
> 0 and zero area. But richer devices might provide blob rect and blob angle,
> blob unique ID *and* the type of blob: Touch, PenTouch, Blob either
> uniquely identified or not (and the source of them if we can dream that
> far).
>
> Thinking like this we can easily support Normal Fingertouches (non
> universally identified Touch with only temporary ID, -null blob area, zero
> angle or pressure if not supported-), Makers can be blobs with an ID, area
> and angle; palms, hands, a cup of coffee and others are just unidentified
> blobs on devices that can recognize them (SUR40?, current optical trackers
> and future new devices).
>
> Please correct me, but I see this as paving future support for those
> recent haptic devices such as Apple Pen, Wacoms (and Im sure Google has
> something in the works for Android).
>
> Ariel
>
>
>
> On Thu, Feb 11, 2016 at 8:05 AM, Welbourne Edward <
> edward.welbourne at theqtcompany.com> wrote:
>
>> Very much a digression but ...
>>
>> > TUIO models the touchpoint as a rotated ellipse though, right?  [snip
>> > URL] And I think that’s nice, for finger touchpoints at least
>> > (although markers could be any shape).  It can be assumed to be the
>> > ellipse inscribed in a rect
>>
>> Traditional graphics always thinks in terms of *coordinate-aligned*
>> rectangles, characterised by a width and height with respect to a single
>> fixed coordinate system.  This works fine for the classical (vertical
>> rectangular) screen and even for most modern tablets, where "rotation"
>> may be supported but only in multiples of a quarter turn.  However, once
>> you get to the kind of "touch surface as table" that the reactable video
>> illustrated - a horizontal round table, no less - there ceases being any
>> naturality to any one choice of coordinate alignment.  It's then
>> necessary to support all orientations equally well, without privileging
>> one of them.
>>
>> In such a context, either an ellipse or a rectangle can be reduced to a
>> centre-point, a semi-major axial vector (orienting it) and a semi-minor
>> axis length (at right angles).  Naturally, we can equivalently scale the
>> axes by two to drop the semi-s.  There's then an obvious correspondence
>> between a rectangle and an ellipse via matching characterisation in
>> these terms.  Which you think of that set of parameters as representing
>> is then somewhat arbitrary.  The area of contact between a finger and a
>> flat surface is closer to elliptical than to rectangular; but there's a
>> stronger reason to prefer an ellipse.
>>
>> Now, I know nothing of the implementation details of touch screens: but
>> have to guess that the actual raw data of an object pressing on a screen
>> is a noisy mess of pressure signals from nearby sensors.  The natural
>> way to process that noisy mess shall be statistically and the natural
>> statistical trickery to use for it is going to give you a mean (vector)
>> and variance (matrix).  The former is your centre-point; the latter is
>> (necessarily, from how it'll be computed from raw data) a symmetric
>> positive-definite quadratic form, a.k.a. a metric, which shall be
>> diagonalised by some specific choice of coordinates - characterised by
>> two perpendicular vectors, one of which we get to construe as semi-major
>> axial vector, with the other telling us the semi-minor axis length.  All
>> of this would still be true for markers of stranger shapes, thanks to
>> the noisy mess of physcal sensor data.  So I'm not surprised to hear
>> that a touchpoint ends up represented by these three data - centre,
>> major axial vector, minor axis length - or some geometrical entity
>> equivalent to them.
>>
>> While these data can indeed be understood equally as characterising a
>> rectangle or an ellipse, coming via a metric makes the ellipse (the
>> "unit circle" of the distance associated with the metric) the more
>> natural form.  When major and minor axes are close to equal in length,
>> the ellipse strongly de-emphasises its incidental orientation, becoming
>> completely orientation-agnostic when we get to major = minor, the
>> circle.  In contrast, a rectangle retains its sense of orientation all
>> the way to that degenerate case, where the square still has a definite
>> orientation, albeit modulo quarter turns.
>>
>> We need an orientation in our representation, to support the case where
>> the axial lengths are significantly different, but we need to think of
>> that orientation as only relevant in so far as the axial lengths *are*
>> significantly different.  Data derived from a metric in the form of
>> centre, major axial vector and minor axial size are thus more naturally
>> thought of as describing an ellipse.
>>
>> So let me encourage you to think in terms of ellipses in this modern
>> era, as the more natural reading of "centre, major axial vector, minor
>> axial size" data, rather than in terms of the rectangles you grew up
>> with - they are an artefact of upright rectangular screens.  The tactile
>> UI folk rightly prefer a well-rounded future,
>>
>>         Eddy.
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>
>
>
> --
> Ariel Molina R.
>
> http://edis.mx
>



-- 
Ariel Molina R.

http://edis.mx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160212/0a91d6fa/attachment.html>