Hi,
Got the qt.qpa.input.tablet events logging and got the results below. I
also compiled the tablet tester from
https://github.com/callaa/QTabletTest and get the same behaviour so
it’s not a PyQt problem.
I’ve included the events as seen at the application level in the
output stream for both a Wacom tablet and Astropad.
Wacom:
—
qt.qpa.input.tablet: proximity change on tablet 0: current tool 2 type 1
unique ID 70514773065729
<PyQt5.QtGui.QTabletEvent object at 0x10ab97168> 171
TabletEnterProximity
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 356.0, 399.0 root pos 698.0, 636.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 357.0, 399.0 root pos 699.0, 636.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 358.0, 400.0 root pos 700.0, 637.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
: (lines suppressed)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 365.0, 433.0 root pos 707.0, 670.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 365.0, 434.0 root pos 707.0, 671.0 buttons 0x1
pressure 0.00 tilt 0, 0 rotation 0.00
TabletPress: pointer=1 pressure=0.0 tilt=(0,0)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 365.0, 434.0 root pos 707.0, 671.0 buttons 0x1
pressure 0.65 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6470588445663452 tilt=(0,0)
MousePress
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 365.0, 436.0 root pos 707.0, 673.0 buttons 0x1
pressure 0.65 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6480811834335327 tilt=(0,0)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 365.0, 436.0 root pos 707.0, 673.0 buttons 0x1
pressure 0.65 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6451514363288879 tilt=(0,0)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 370.0, 445.0 root pos 712.0, 682.0 buttons 0x1
pressure 0.64 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6421911716461182 tilt=(0,0)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 381.0, 463.0 root pos 723.0, 700.0 buttons 0x1
pressure 0.64 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6421911716461182 tilt=(0,0)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 384.0, 469.0 root pos 726.0, 706.0 buttons 0x1
pressure 0.64 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6431372761726379 tilt=(0,0)
MouseMove
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 386.0, 474.0 root pos 728.0, 711.0 buttons 0x1
pressure 0.64 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6431372761726379 tilt=(0,0)
MouseMove
: (lines suppressed)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 388.0, 486.0 root pos 730.0, 723.0 buttons 0x1
pressure 0.61 tilt 0, 0 rotation 0.00
TabletMove: pointer=1 pressure=0.6117647290229797 tilt=(0,0)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 381.0, 478.0 root pos 723.0, 715.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
TabletRelease: pointer=1 pressure=0.0 tilt=(0,0)
MouseMove
MouseRelease
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 381.0, 478.0 root pos 723.0, 715.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
70514773065729 pos 381.0, 478.0 root pos 723.0, 715.0 buttons 0x0
pressure 0.00 tilt 0, 0 rotation 0.00
qt.qpa.input.tablet: proximity change on tablet 0: current tool 2 type 1
unique ID 70514773065729
<PyQt5.QtGui.QTabletEvent object at 0x10ab97168> 172
TabletLeaveProximity
—
So a bunch of events while the pen hovers, then the first event with
buttons 0x1 with pressure >0 gets reported as a TabletPress event and
the rest as TabletMove events. Mouse events get released for some of the
tablet events but not all.
Then the next event with buttons 0x0 and pressure=0 gets reported as a
TabletRelease.
Astropad:
—
qt.qpa.input.tablet: proximity change on tablet 0: current tool 2 type 1
unique ID 4582773633348209
TabletEnterProximity
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 193.0, 302.5 root pos 535.0, 539.5 buttons 0x64
pressure 0.00 tilt 29, 9 rotation 0.00
TabletPress: pointer=1 pressure=0.0 tilt=(29,9)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 193.0, 302.5 root pos 535.0, 539.5 buttons 0x1
pressure 0.09 tilt 29, 9 rotation 0.00
TabletRelease: pointer=1 pressure=0.0941176488995552 tilt=(29,9)
MousePress
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 191.1, 302.3 root pos 533.1, 539.3 buttons 0x1
pressure 0.09 tilt 29, 9 rotation 0.00
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 189.0, 296.8 root pos 531.0, 533.8 buttons 0x1
pressure 0.09 tilt 29, 9 rotation 0.00
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 189.0, 296.8 root pos 531.0, 533.8 buttons 0x1
pressure 0.07 tilt 29, 9 rotation 0.00
MouseMove
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 187.8, 285.3 root pos 529.8, 522.3 buttons 0x1
pressure 0.15 tilt 29, 9 rotation 0.00
MouseMove
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 187.8, 286.7 root pos 529.8, 523.7 buttons 0x1
pressure 0.20 tilt 29, 9 rotation 0.00
MouseMove
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 199.9, 266.4 root pos 541.9, 503.4 buttons 0x1
pressure 0.22 tilt 29, 9 rotation 0.00
MouseMove
: (lines suppressed)
qt.qpa.input.tablet: event on tablet 0 with tool 2 type 1 unique ID
4582773633348209 pos 333.1, 336.1 root pos 675.1, 573.1 buttons 0x0
pressure 0.00 tilt 27, 4 rotation 0.00
MouseRelease
qt.qpa.input.tablet: proximity change on tablet 0: current tool 2 type 1
unique ID 4582773633348209
TabletLeaveProximity
—
No hover events obviously, but first event has buttons 0x64 pressure
0.00 which gets reported as a TabletPress but then the next event with
buttons 0x1 pressure 0.09 gets reported as a TabletRelease and
subsequent events are reported as Mouse despite continuing to receive
tablet events.
So it could be the change of buttons signature is getting interpreted as
lifting the pen. Seems like a bug in both Astropad and QT. Astropad
should send the first event as buttons 0x0 but QT could be made more
robust since it’s clearly still receiving tablet events (with
pressure, tilt etc) but just doesn’t interpret them properly.
Any idea what I’d need to patch in QT to fix this?
Alexei
On 23 Mar 2016, at 0:11, Alexei Gilchrist wrote:
On 22 Mar 2016, at 20:18, Rutledge Shawn wrote:
On 22 Mar 2016, at 02:30, Alexei Gilchrist <te...@runbox.com> wrote:
Hi all,
I'm trying to use Astropad (app provides OsX tablet interface with
an iPad) with an app I’ve written and I'm getting odd results with
tablet events in QT. First of all, I've been in contact with the
devs and they seem to think it's a QT bug rather than an Astropad
bug, and in any case Astropad works with other graphics programs
that I've tried.
Why do they think it’s a Qt bug? Maybe they should tell us what we
are doing wrong if they know.
I guess there must be a Mac daemon which tries to emulate a Wacom by
sending the same events? It’s not only for Qt applications, right?
But Qt applications work with a real Wacom but not Astropad, so they
must not be emulating the events exactly the same.
It is running a daemon that handles communication with the
corresponding app on an iPad. One reason to believe it’s a QT bug is
that Astropad works fine with other applications such as Gimp,
SketchbookEpress, InKist, Photoshop, all respond to pressure
variations so multiple toolkits are able to interpret the synthesised
events correctly.
You can enable the logging category qt.qpa.input.tablet to see how
the events come in (the code is in qnsview.mm).
Cool. Didn’t know that. I Need to figure out how to display the
logging events in pyqt as setting
export QT_LOGGING_RULES='qt.qpa.input=true'
or editing ~/.config/QtProject/qtlogging.ini is not reporting to the
console, maybe the python logging module which I’m using is taking
over stderr. Will play around and see if I can get some feedback.
I'm coding in python using pyqt and have Python 3.5.0 and QT 5.5.0
installed.
At the level of QWidget you get an initial TabletPress event with
pressure=0 followed immediately by a TabletRelease event with
pressure>0 at which point the rest of the stroke is only reported as
mouse events, with are low frequency and don’t contain pressure
info.
Astropad:
TabletPress: pointer=1 pressure=0.0 tilt=(27,12)
TabletRelease: pointer=1 pressure=0.13333334028720856 tilt=(27,12)
MousePress
MouseMove
MouseMove
...[ many MouseMove ]...
MouseRelease
Works as you'd expect with Wacom tablet, though accepting the tablet
events does't stop the mouse events being fired (minor niggle):
That’s https://bugreports.qt.io/browse/QTBUG-47007 It’s probably
always been that way, at least in Qt 5, because the platform plugins
are doing this mouse emulation when necessary. (In some cases the
window system will send a synthesized mouse event itself, in which
case we don’t need to.) Plugins don’t pay attention to whether
the tablet event was accepted or not, because sending events from the
platform plugin into the application is asynchronous, going through a
queue. We assume the tablet event is rejected because that’s the
default policy (outside of QtQuick where we assume an event is
accepted), so the default is that the application does nothing, and
then it gets a mouse event (so that you can use the stylus to
interact with widgets etc.) AFAIK there isn’t a nice mechanism to
wait and see whether the app accepted the tablet event or not; we’d
have to wait until the asynchronous delivery is done, somehow.
In older Qt versions, you needed the mouse event (which means you
should reject the tablet event, according to the docs) in order to
find out what buttons on the stylus were pressed. But if you reject
the tablet press event, you don’t get movement updates as tablet
events, and the mouse events are compressed (as you noticed). Now,
QTabletEvent has buttons too, so you no longer need to do that, but
there may still be some legacy applications that are already written
to work that way. So I’m not sure whether we should fix that now,
or will it be seen as a behavior change which breaks applications? I
guess fixing it in 5.7 or later ought to be OK at least. But it’s
nontrivial to fix.
This is not much of a problem as a TabletPress is delivered before a
MousePress so it’s easy to toggle a pen_down variable and ignore
mouse events.
QTBUG-51617 is about labelling the mouse events as synthesized so
that you can at least easily know which mouse events to reject. It
should be fixed now on X11 (for 5.6.1), we just need to make sure the
other platforms work consistently. So you can have a mouse handler
which ignores such events.
Will take a look at those, it would be a more robust solution in case
the ordering of events should change.
TabletPress: pointer=1 pressure=0.4313725531101227 tilt=(0,0)
MousePress
TabletMove: pointer=1 pressure=0.45098039507865906 tilt=(0,0)
MouseMove
TabletMove: pointer=1 pressure=0.45098039507865906 tilt=(0,0)
TabletMove: pointer=1 pressure=0.4470588266849518 tilt=(0,0)
...[ many MouseMove and many more TableMove ] ...
TabletRelease: pointer=1 pressure=0.0 tilt=(0,0)
MouseMove
MouseRelease
At the level of QApplication I'm seeing TabletEnterProximity and
TabletLeaveProximity events as you'd expect.
Cool. Are you using an iPad Pro? Otherwise it can’t detect
proximity, but maybe it synthesizes those events when you press?
Yes, using an iPad pro. Astropad mirrors the mac screen to the iPad
pro and captures pencil and finger events synthesising corresponding
events on the mac. Effectively creating a Cintiq like tablet. I’m
guessing they add the proximity events for compatibility with apps
that are coded for a wacom tablet and looking for the hover (iPad pro
does’t detect pencil proximity).
When I first contacted the Astropad devs you could trick their code
into sending some sequence that QT transmitted with TabletMove events
for one stroke after doing a stroke on a wacom tablet. I pointed out
the problem and sent then a test app and got back:
I wanted to let you know that we found a workaround for this. It does
appear to be a bug in QT, but we figured out what event from Astropad
was confusing it. By removing this event (which doesn’t appear to
be necessary) QT once again works with Astropad.
Since then, they’ve updated their code and no TabletMove events are
generated at all. Not sure why they concluded that they’d created a
workaround, but they’re no longer responding to me pestering them :P
Alexei
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
