Post by Shawn Rutledge Post by Shawn Rutledge
On 28 June 2012 13:03, Christian Spielberger
Post by Christian Spielberger
I got multitouch on top of XInput 2.2 to work.
See http://youtu.be/sRSC4CEYmIg !
See https://gitorious.org/~cspiel/qt/cspiels-qt-4_8-with-xinput2_1 !
Maybe the branch can be the base for the multitouch integration for X11.
Excellent! I was planning to work on Qt 5 support for XI 2.2 soon, so
that should be helpful.
However due to the way the code has been rearranged, the patch will be in
different files anyway.
To be more specific: due to the introduction of QPA it's quite different; in
Qt 5 the platform XCB plugin generates touchpoints of type struct TouchPoint
to put into a QWindowSystemInterfacePrivate::TouchEvent, whereas in your patch
you can generate a QTouchEvent::TouchPoint directly. However from reading
your code I learned of the existence of the pre-converted coordinates:
touchPoint.setPos( QPointF(xideviceevent->event_x, xideviceevent->event_y) );
touchPoint.setScreenPos( QPointF(xideviceevent->root_x, xideviceevent->root_y)
as opposed to having to get them from the valuators and convert them manually.
But there are some odd things about it: you used XLib so you get them as
doubles, but in xcb they have 16.16 fixed-point format, so I have convert them
Another oddity is that when testing a touchscreen, each xXIDeviceEvent from
xcb has the correct coordinates already, whereas with an Apple Trackpad, both
of them will be at the same point where the cursor is. Maybe that's because
the touchpad is a relative device rather than absolute, or maybe it's an xcb
bug? Because what I think I want is that the first touchpoint should be at
the cursor position, and the second one should be offset the same distance
from the first as my second finger is offset on the trackpad. But with the
current version of my patch, if I run the fingerpaint example, all the fingers
are superimposed, so you just get different ellipses in different colors
painted on top of each other. (At least the major/minor axes are unique
depending on pressure.) So I'm thinking of calculating the offset from the
converted raw point to the given root_x and root_y for the first point, and
then somehow offsetting the second and subsequent points. But I'm not sure if
it's right for Qt to do that; if it's a bug or oversight in xcb (or somewhere
else), maybe it will get fixed there eventually.
Post by Shawn Rutledge
Would you like to convert your changes into a patch
on gerrit so it can be reviewed to go into 4.8.x? I can also test it on a
couple of devices.
I noticed you deleted the code to deal with the valuators completely, so that
means in your branch there is no support for pressure or major/minor axes,
right? When I run fingerpaint against your branch, it is indeed insensitive
to pressure, I just get circles all the same size. I don't think you should
be ignoring all the valuators, even though you are correctly making use of the
given points from the event itself.
The axes are supposed to describe the size and shape of the elliptical contact
patch of your finger against the touch device. I have tested my Qt 5 patch on
the following devices:
Lenovo S10-3t: has neither pressure nor axes; 2 points max
Apple Bluetooth trackpad: has major and minor axes plus (bogus?) orientation,
5 points max; points from the XI2 event are all at the same position as the
Apple trackpad on a Macbook Pro (17" from 2009 or so): has major and minor
axes plus ABS Pressure (NOT Abs MT Pressure), 5 points max; forgot whether it
has orientation; points from the XI2 event are all at the same position as the
ExoPC: no axes, has Abs MT Pressure but sometimes I have seen it go to the
minimum possible value if there are 2 fingers. 10 points max.
What I mean by "bogus orientation" on the trackpad is that instead of having
per-finger orientation, it exists only if 2 or more fingers are pressed, so it
would seem to be related to the angle between them; but it's quite jumpy, and
I'm not sure what a range from -31 to +32 is supposed to mean anyway. High-
end Wacom tablets apparently give 3 angles: the rotation of the stylus, and
two vertical angles w.r.t. the Wacom surface. I think the orientation is
supposed to be like the stylus rotation angle, and should really be on a per-
finger basis, so I guess we should call it rotation to be consistent, so that
we are ready in case future touch devices report more than one angle as well.
If the trackpad has a high density grid of capacitive sensors, then I think
the idea is that trackpad's processor should be fitting an ellipse to each
blob, and reporting the width, height and rotation of the ellipse. (Or maybe
the driver does it?) If rotation was really not reported from each of the
curve-fit ellipses, I wonder why.
The data coming from the BT trackpad looks like this
XI2 event type 19 seq 333 detail 400 pos 0x3D00000,0x28F0000
976.000000,655.000000 root pos 2896.000000,679.000000
valuator class label 636 value 71.000000 from range -2909.000000 ->
3167.000000 name Abs MT Position X
valuator class label 637 value -14.000000 from range -2456.000000 ->
2565.000000 name Abs MT Position Y
valuator class label 638 value 128.000000 from range 0.000000 -> 255.000000
name Abs MT Touch Major
valuator class label 639 value 168.000000 from range 0.000000 -> 255.000000
name Abs MT Touch Minor
tp 400 state 2 pos norm QPointF(0.490454, 0.486357) area
QRectF(2886.81,666.686 18.3749x24.6289) angle 0 pressure -1
but with even larger values for the axes on the Macbook Pro. So I decided to
convert the value such that that maximum value corresponds to max finger width
in mm (it's #defined to 10mm - perhaps a bit much) and convert that to pixels
based on the actual screen resolution.
MVH, Shawn Rutledge ❖ "ecloud" on IRC