Bug 407595 - Pen -> Mouse switching shows mouse draw failure
Summary: Pen -> Mouse switching shows mouse draw failure
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Debian stable Linux
: NOR minor
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-05-16 11:50 UTC by Ahab Greybeard
Modified: 2019-06-20 15:51 UTC (History)
1 user (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 Ahab Greybeard 2019-05-16 11:50:09 UTC
SUMMARY
This problem happens with appimages and does not happen with Windows builds.
It has been observed with a Debian 9 (Stable, fully updated) system using a Wacom Intuos Paint tablet (CTH 490/K).
It's inconvenient but it's not a major problem. It happens on Debian 10 (Testing but under full freeze) in a different way as noted below.
This was tested with the 4.1.7 appimage and the latest (15th May) 4.2 alpha appimage and Windows versions.

When changing from drawing with a pen to drawing with a mouse, the mouse does not draw and the brush profile outline does not track the cursor. The cursor must be moved off the workspace and then back to the canvas, as a 'recovery method' in order to get the brush outline moving. After the cursor moves off the workspace, the brush outline tracks the cursor as it returns to the workspace. A single mouse click is needed (on the workspace border area or the canvas) to get the mouse drawing again. Further, a mouse click before moving off the workspace will result in that extra single mouseclick not being needed after the cursor is brought back onto the canvas.
Other tools such as line tool, colour picker and selection tools show the same mouse action failure and 'recovery method' characteristics.

Note: With the 4.1.7 appimage, the additional mouse click is not required to enable drawing with the mouse after tracking has been recovered in the way described above.

In Debian 10, the brush tracks the mouse after switching but a click on the canvas is needed before it will draw.

In ADDITIONAL INFORMATION, tablet tester outputs for stylus to mouse transition are shown for different krita versions and different operating systems. They are all different. 


STEPS TO REPRODUCE
1. Create a new image and zoom out a little to show a border area (for convenience). Use the pen and Freehand Brush to draw with any brush preset. Remove the pen from the tablet area.
2. Move the mouse and attempt to draw. Note the lack of drawing and lack of brush outline response to the cursor.
3. Move the mouse off the workspace, e.g to an adjacent docker or the toolbar. Note the brush profile outline will be removed from the canvas and will now track the cursor as it returns to the workspace and the mouse will not draw on the first attempt unless it is clicked on the workspace border or canvas area first.
4. Also note that switching to drawing with a pen at any stage does not show any problems but then switching back to the mouse repeats the mouse drawing problem situation.

OBSERVED RESULT
As noted in STEPS TO REPRODUCE above.

EXPECTED RESULT
The mouse should be able to draw on the canvas after use of the pen.

SOFTWARE/OS VERSIONS

Krita

 Version: 4.2.0-alpha (git 7a773b1)
 Languages: en_GB, en
 Hidpi: true

Qt

  Version (compiled): 5.12.2
  Version (loaded): 5.12.2

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 4.9.0-9-amd64
  Pretty Productname: Debian GNU/Linux 9 (stretch)
  Product Type: debian
  Product Version: 9

Hardware Information

  GPU Acceleration: auto
  Memory: 16049 Mb
  Number of Cores: 8
  Swap Location: /tmp


ADDITIONAL INFORMATION

Tablet Tester: 4.2 alpha appimage Debian 9
---------------------------------------------------
Stylus press X=343.46 Y=19.28 B=1 P=4.0%
Stylus move X=344.64 Y=18.31 B=1 P=4.9% (DRAW)
Stylus move X=345.32 Y=17.45 B=1 P=5.0% (DRAW)
Stylus move X=346.16 Y=16.69 B=1 P=5.1% (DRAW)
etc
Stylus move X=347.67 Y=17.45 B=1 P=2.6% (DRAW)
Stylus move X=348.18 Y=17.45 B=1 P=0.0% (DRAW)
Stylus release X=348.18 Y=17.45 B=0 P=0.0%
(switch to mouse)
Mouse press X=305 Y=30 B=1
Mouse move X=305 Y=31 B=1
Mouse move X=302 Y=35 B=1
etc
Mouse move X=301 Y=43 B=1
Mouse move X=301 Y=44 B=1
Mouse release


Tablet Tester: 4.1.7 appimage Debian 9
-----------------------------------------------
Stylus press X=273.00 Y=19.41 B=1 P=16.3%
Mouse press X=272 Y=19 B=1
Stylus move X=272.16 Y=19.62 B=1 P=25.7% (DRAW)
Stylus move X=271.32 Y=19.84 B=1 P=29.3% (DRAW)
Mouse move X=271 Y=19 B=1
Stylus move X=270.64 Y=20.05 B=1 P=30.9% (DRAW)
Mouse move X=270 Y=20 B=1
etc
Stylus move X=265.93 Y=21.13 B=1 P=36.8% (DRAW)
Mouse move X=265 Y=21 B=1
Stylus move X=265.42 Y=21.56 B=1 P=20.3% (DRAW)
Stylus move X=265.42 Y=21.56 B=1 P=0.0% (DRAW)
Stylus release X=265.42 Y=21.56 B=0 P=0.0%
Mouse release
(switch to mouse)
Mouse press X=212 Y=71 B=1
Mouse move X=212 Y=72 B=1
Mouse move X=211 Y=75 B=1
etc
Mouse move X=207 Y=80 B=1
Mouse move X=207 Y=81 B=1
Mouse release

Tablet Tester: 4.2 alpha Windows 10
------------------------------------------------------
Pen tip brought near
Stylus press X=291.29 Y=26.20 B=1 P=15.3%
Mouse press X=291 Y=26 B=1
Stylus move X=290.62 Y=26.41 B=1 P=23.7% (DRAW)
Mouse move X=290 Y=26 B=1
Stylus move X=289.95 Y=26.52 B=1 P=27.1% (DRAW)
Mouse move X=289 Y=26 B=1
Stylus move X=289.44 Y=26.52 B=1 P=32.3% (DRAW)
etc
Stylus move X=271.08 Y=35.36 B=1 P=47.9% (DRAW)
Stylus move X=271.08 Y=34.93 B=1 P=22.6% (DRAW)
Mouse move X=271 Y=34 B=1
Stylus release X=271.08 Y=34.93 B=0 P=0.0%
Mouse release
Pen tip taken away
(switch to mouse)
Mouse press X=219 Y=96 B=1
Mouse move X=218 Y=101 B=1
Mouse move X=218 Y=102 B=1
Mouse move X=218 Y=104 B=1
etc
Mouse move X=214 Y=112 B=1
Mouse move X=214 Y=113 B=1
Mouse move X=213 Y=113 B=1
Mouse release

Tablet Tester: 4.2 alpha appimage Debian 10
--------------------------------------------------

Pen tip brought near
Stylus press X=254.26 Y=28.67 B=1 P=17.1%
Stylus move X=252.75 Y=29.53 B=1 P=19.5% (DRAW)
Stylus move X=251.23 Y=30.29 B=1 P=19.8% (DRAW)
Stylus move X=249.72 Y=31.15 B=1 P=20.5% (DRAW)
Stylus move X=248.71 Y=31.69 B=1 P=24.5% (DRAW)
etc
Stylus move X=242.31 Y=38.80 B=1 P=2.4% (DRAW)
Stylus move X=242.31 Y=38.80 B=1 P=0.0% (DRAW)
Stylus release X=242.31 Y=38.80 B=0 P=0.0%
Pen tip taken away
(switch to mouse)
Mouse press X=271 Y=63 B=1
Mouse move X=271 Y=63 B=1
Mouse move X=271 Y=64 B=1
Mouse move X=269 Y=70 B=1
etc
Mouse move X=260 Y=97 B=1
Mouse move X=259 Y=99 B=1
Mouse move X=257 Y=100 B=1
Mouse release
Comment 1 Dmitry Kazakov 2019-06-19 16:08:50 UTC
Git commit 869aaea7c1c7b9fd0f09232290706745d84f23ae by Dmitry Kazakov.
Committed on 19/06/2019 at 16:08.
Pushed by dkazakov into branch 'master'.

Don't eat mouse press events on Linux

Since we explicitly accept all the tablet press events, Linux
is guaranteed not to generate any synthesized mouse presses for
them. Therefore, we shouldn't eat them.

On Windows, the events are synthesized by the OS, so we need
to eat them still.

M  +8    -1    libs/ui/input/kis_input_manager.cpp

https://invent.kde.org/kde/krita/commit/869aaea7c1c7b9fd0f09232290706745d84f23ae
Comment 2 Ahab Greybeard 2019-06-19 18:32:02 UTC
This fully fixes the problem in Debian 10 (thank you), but Debian 9 still has the problem where the brush profile outline doesn't track the mouse cursor until the recovery action of moving outside the workspace has been done - the single mouse click after recovery is no longer needed though.

The difficulty is probably that Debian 10 has a newer version of xserver-xorg-input-wacom and libwacom* packages and they are obviously different.

On a personal level, I'll try to backport these from Debian 10 to Debian 9 and try to make progress in fully preparing a Debian 10 system (which is due for formal release in July) for my regular use.

This is something to bear in mind in the future if anyone with a Debian 9 system reports this problem.
Comment 3 Halla Rempt 2019-06-20 09:52:17 UTC
Thanks for the extra information!
Comment 4 Halla Rempt 2019-06-20 10:49:28 UTC
Git commit d6b1e66ee75a6be721c45deab08591f1309c0122 by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 20/06/2019 at 10:33.
Pushed by rempt into branch 'krita/4.2'.

Don't eat mouse press events on Linux

Since we explicitly accept all the tablet press events, Linux
is guaranteed not to generate any synthesized mouse presses for
them. Therefore, we shouldn't eat them.

On Windows, the events are synthesized by the OS, so we need
to eat them still.

M  +8    -1    libs/ui/input/kis_input_manager.cpp

https://invent.kde.org/kde/krita/commit/d6b1e66ee75a6be721c45deab08591f1309c0122
Comment 5 Ahab Greybeard 2019-06-20 15:51:16 UTC
FYI and for future reference:
Using the Debian 10 standard repositories, I manually backported the *wacom* packages into my Debian 9 system and then put a 'hold' on them.

My now updated Debian 9 system works well and does not show this bug anymore.

Debian 9 has LTS to June 2022 so there may be some people in the future who have this or similar wacom driver related problems with Debian 9.