Bug 406668 - Touch docker/QML does not response to tablet input with WinInk
Summary: Touch docker/QML does not response to tablet input with WinInk
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (show other bugs)
Version: git master (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-04-19 03:40 UTC by Alvin Wong
Modified: 2020-05-17 09:30 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alvin Wong 2019-04-19 03:40:37 UTC
Touch docker/QML does not response to tablet input with WinInk on my SP5. Works with WinTab though.

I feel like I've fixed something similar in the past, but I forgot what it was exactly...
Comment 1 tusooa 2019-05-07 12:47:35 UTC
Can confirm this on Surface Pro 4.
Comment 2 Dmitry Kazakov 2019-05-14 08:46:23 UTC
I can reproduce with Intuos 5. Let's fix it :)
Comment 3 Dmitry Kazakov 2019-05-16 08:32:11 UTC
Please test the package in this task: https://phabricator.kde.org/T10935

It should fix at least some of the problems.
Comment 4 Dmitry Kazakov 2019-05-16 09:09:10 UTC
Git commit d684bc557d4fe1782d78896d007fb75ecf6c0bf1 by Dmitry Kazakov.
Committed on 16/05/2019 at 09:08.
Pushed by dkazakov into branch 'master'.

Add workaround for handling table press correctly in WinInk mode

Original problem: widgets do not get synthesized mouse-down and
mouse-press events until the stylus is released

Reason: if the app accepts the event, WndProc should report
that to the system (by returning true). This is the only way to
prevent Windows from starting some system-wide gestures, like
click+hold -> right button click. If we ignore the event, then
OS postpones all synthesized mouse events until the entire gesture
is completed.

The patch implements a "hackish" workaround for the original problem
by using the following rules:

1) All tablet-move events are ignored (without synthesized mouse events
   OS doesn't generate any Enter/Leave events)

2) All not-accepted tablet press- and release-events and also reported as
   ignored (without it D&D doesn't work).

3) All accepted tablet press- and release-events are reported as "accepted",
   **but** we artificially synthesize mouse events for them.

TODO: there are still two problems:

1) Perhaps this synthesizeMouseEvent() is not needed at all. But we should
   first check if Qt relies on these synthesized messages anywhere in the
   code or not.

2) If we still keep synthesizeMouseEvent(), then it should fetch actual
   tablet buttons from QGuiApplicationPrivate::tabletDevicePoint(). Right
   now it always synthesizes left-click, whatever the button was pressed/
   released.

A  +243  -0    3rdparty/ext_qt/0051-Add-workaround-for-handling-table-press-correctly-in.patch
M  +1    -0    3rdparty/ext_qt/CMakeLists.txt
M  +17   -0    plugins/dockers/touchdocker/TouchDockerDock.cpp
M  +2    -0    plugins/dockers/touchdocker/TouchDockerDock.h

https://invent.kde.org/kde/krita/commit/d684bc557d4fe1782d78896d007fb75ecf6c0bf1
Comment 5 Dmitry Kazakov 2019-05-16 09:09:10 UTC
Git commit 8dd4d8b98361eab3acfa7a6f05d7b38fc532d0de by Dmitry Kazakov.
Committed on 16/05/2019 at 09:08.
Pushed by dkazakov into branch 'master'.

Fix using tablet on QML widgets

In previous versions of Qt (wintab impeplementation) the events were
marked by Qt::MouseEventSynthesizedBySystem flag only when they were
synthesized from touch, not from tablet events. This is what
QWindowsTabletSupport does and what QQuickWindow expects (it
filters out all synthesized events). This patch recovers the old behavior
for the new QWindowsPointerHandler tablet API implementation.

A  +52   -0    3rdparty/ext_qt/0050-Fix-using-tablet-on-QML-widgets.patch
M  +1    -0    3rdparty/ext_qt/CMakeLists.txt

https://invent.kde.org/kde/krita/commit/8dd4d8b98361eab3acfa7a6f05d7b38fc532d0de
Comment 6 Halla Rempt 2019-05-16 09:44:24 UTC
Git commit 37f4021dfee6a07d0385181f5181657d0457f644 by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 16/05/2019 at 09:44.
Pushed by rempt into branch 'krita/4.2'.

Fix using tablet on QML widgets

In previous versions of Qt (wintab impeplementation) the events were
marked by Qt::MouseEventSynthesizedBySystem flag only when they were
synthesized from touch, not from tablet events. This is what
QWindowsTabletSupport does and what QQuickWindow expects (it
filters out all synthesized events). This patch recovers the old behavior
for the new QWindowsPointerHandler tablet API implementation.

A  +52   -0    3rdparty/ext_qt/0050-Fix-using-tablet-on-QML-widgets.patch
M  +1    -0    3rdparty/ext_qt/CMakeLists.txt

https://invent.kde.org/kde/krita/commit/37f4021dfee6a07d0385181f5181657d0457f644
Comment 7 Dmitry Kazakov 2019-05-21 21:09:36 UTC
Git commit ae31080ac4fa4f7a571a196bbdf2f203c6c0dc87 by Dmitry Kazakov.
Committed on 21/05/2019 at 21:09.
Pushed by dkazakov into branch 'master'.

Fix popup palette in WinInk mode

We should eat synthesized events more carefully in the popup
palette. The events may come either to the triangle widget or
to its parent widget, depending on the implementaiton. Therefore
we use a special event filter for that (KisMouseClickEater).
Ref T10935

M  +29   -21   3rdparty/ext_qt/0051-Add-workaround-for-handling-table-press-correctly-in.patch
M  +1    -1    libs/ui/CMakeLists.txt
A  +70   -0    libs/ui/KisMouseClickEater.cpp     [License: UNKNOWN]  *
A  +29   -0    libs/ui/KisMouseClickEater.h     [License: UNKNOWN]  *
M  +20   -27   libs/ui/kis_popup_palette.cpp
M  +3    -4    libs/ui/kis_popup_palette.h

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/kde/krita/commit/ae31080ac4fa4f7a571a196bbdf2f203c6c0dc87
Comment 8 Halla Rempt 2019-05-23 12:17:29 UTC
Git commit 47b63a2d3e9e6f9efe686861ee220afc73b7e737 by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 23/05/2019 at 11:57.
Pushed by rempt into branch 'krita/4.2'.

Fix popup palette in WinInk mode

We should eat synthesized events more carefully in the popup
palette. The events may come either to the triangle widget or
to its parent widget, depending on the implementaiton. Therefore
we use a special event filter for that (KisMouseClickEater).
Ref T10935

M  +29   -21   3rdparty/ext_qt/0051-Add-workaround-for-handling-table-press-correctly-in.patch
M  +1    -1    libs/ui/CMakeLists.txt
A  +70   -0    libs/ui/KisMouseClickEater.cpp     [License: UNKNOWN]  *
A  +29   -0    libs/ui/KisMouseClickEater.h     [License: UNKNOWN]  *
M  +20   -27   libs/ui/kis_popup_palette.cpp
M  +3    -4    libs/ui/kis_popup_palette.h

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/kde/krita/commit/47b63a2d3e9e6f9efe686861ee220afc73b7e737
Comment 9 Dmitry Kazakov 2019-05-24 13:30:41 UTC
I think the bug can be considered as closed now after this commit:)

https://invent.kde.org/kde/krita/commit/ae31080ac4fa4f7a571a196bbdf2f203c6c0dc87
Comment 10 Dmitry Kazakov 2019-05-24 14:54:37 UTC
Okay, Alvin reported that QML dialogs (not widgets) do not respond to tablet clicks on his surface pro. So I will reopen the bug, but unset release-blocker tag.

On my Wacom5 device in WinInk mode, the QML dialogs respond to clicks fine.
Comment 11 Dmitry Kazakov 2020-05-06 21:27:13 UTC
Okay, I think I should check that on the Yoga device
Comment 12 Dmitry Kazakov 2020-05-15 17:40:34 UTC
Hi, Alvin!

Could you please check if the bug is still reproducible in Krita 4.3 Beta1?

https://krita.org/en/item/first-beta-of-krita-4-3-0-released/

I have checked on touch-enabled Lenovo Yoga device in WinInk mode and it seems to work perfectly fine...
Comment 13 Alvin Wong 2020-05-17 09:30:12 UTC
Not reproducible with 4.3.0 beta1.