SUMMARY At least with my stock Intuos pen, dragging the pen on the scratchpad while also attempting to utilize canvas inputs by holding any of the pen buttons will break further drawing functionality of the scratchpad, until Krita is restarted. For example: if you hold the pan canvas pen button and attempt to pan the scratchpad, further drawing on the scratchpad is prevented. It also happens if you hold the pop-up palette pen button while dragging the pen on the scratchpad. STEPS TO REPRODUCE 1. Open Brush Settings. 2. Hold a pen button. 3. While holding a pen button, drag pen across the scratchpad. OBSERVED RESULT Nothing happens and the scratchpad is no longer usable until Krita is restarted. EXPECTED RESULT It is understandable if the canvas inputs wouldn't work with the scratchpad (as I understand, it's basically a different sort of canvas), but at the very least, attempting to use them with the pen shouldn't break the scratchpad. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian sid (available in About System) KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.12.9 (Appimage) ADDITIONAL INFORMATION No errors will be outputted to the terminal. The scratchpad fill buttons will still work. This issue seems isolated to the pen buttons, as utilizing the corresponding canvas inputs with a mouse/keyboard won't break the scratchpad. The scratchpad will also still work if you hold a pen button and click with the mouse.
I can replicate this result with the Jan 17 4.4.3 alpha (git 29bd818) appimage. The mouse can be used to pan the scratchpad and paint on it. My Intuos stylus provides a middle click signal (B=4 on the tablet tester) but does not pan the scratchpad. After the lock-up condition happens, the stylus can still paint on the canvas.
I decided to investigate this more since I found it strange that I only started noticing this recently, despite my tendency to accidentally click my pen buttons. As of 4.1.0 (haven't checked previous versions, 4.0.0 crashes at startup for me at this point), holding the pen button appears to draw on the scratchpad at minimum pressure despite not even touching the tablet. This effect is not visible on every brush as it can depend on the pressure sensors used, hence I didn't notice it before making this report. In 4.4.0 (haven't checked the betas), it starts to have the current breakage along with the behavior described above. Both of these behaviors still happen as of 4.4.2. The behavior described in the report is a regression, and I'm not if I should bother making a separate report for the other behavior.
I can confirm this also happens on Windows 7 SP1 64bit and not only with an Intuos drawing tablet, but also with a mouse. To reproduce with a mouse, just right-click while drawing a stroke on the scratchpad. On my system once the bug is triggered neither mouse nor stylus can draw in the scratchpad, doesn't matter which device did the triggering, so that's also a little different than what tom & Ahab have reported on Linux. Tested a bunch of builds Bugged 4.4.2, 4.4.3-alpha, & 5.0.0-prealpha Not Bugged 3.3.1, 4.0.1, 4.2.0, 4.3.0 Combining this with Tom's tests it appears this started either with the 4.4.0 dev. cycle or somewhere in the 4.3 'dot' updates Not sure if this means anything, but while all the scratchpad fill functions continue to work, they are unable to remove the stroke that was being drawn when the bug was initiated. I'm attaching a small video in a zip demonstrating this Something else that may be of note in the video; you can tell the moment the bug is initiated (at roughly 00:15) because the the foreground color changes to white. when in the scratchpad right-clicking sets the foreground color*, which is a feature I was not aware of this until a few weeks ago. if it's a fairly new addition maybe it's related to the drawing problem. (*This only works with a mouse not the Intuos pen for some reason)
Created attachment 135158 [details] video demonstrating scratchpad bug
I can reproduce the bug in krita/4.3 branch, but cannot reproduce that in the current master. Works: 9321eb2b22f0a330ba5d63bb7bb03a779de8fe28 Fails: c22b6d6c77aabd7d604b6485e91b7ff82621a4ad
Okay, master also fails, it is just a bit random due to reordering of the tablet events.
Git commit 7b9ee471b5a1d62b55646d934637fecc24155cab by Dmitry Kazakov. Committed on 05/02/2021 at 12:01. Pushed by dkazakov into branch 'master'. Fix lockout in the scratchpad when using right button on a tablet The tablet driver may generate mouse/tablet events in an interleaved way, so we should make sure that not more than one stroke is started at the same time. M +10 -0 libs/ui/widgets/kis_scratch_pad.cpp M +1 -0 libs/ui/widgets/kis_scratch_pad.h M +43 -22 libs/ui/widgets/kis_scratch_pad_event_filter.cpp M +2 -0 libs/ui/widgets/kis_scratch_pad_event_filter.h https://invent.kde.org/graphics/krita/commit/7b9ee471b5a1d62b55646d934637fecc24155cab
Git commit 28f3d7bb3345baaa6800caa0ae06a70333507258 by Dmitry Kazakov. Committed on 05/02/2021 at 12:02. Pushed by dkazakov into branch 'krita/4.3'. Fix lockout in the scratchpad when using right button on a tablet The tablet driver may generate mouse/tablet events in an interleaved way, so we should make sure that not more than one stroke is started at the same time. M +10 -0 libs/ui/widgets/kis_scratch_pad.cpp M +1 -0 libs/ui/widgets/kis_scratch_pad.h M +43 -22 libs/ui/widgets/kis_scratch_pad_event_filter.cpp M +2 -0 libs/ui/widgets/kis_scratch_pad_event_filter.h https://invent.kde.org/graphics/krita/commit/28f3d7bb3345baaa6800caa0ae06a70333507258
*** Bug 434527 has been marked as a duplicate of this bug. ***