Bug 406219 - [WACOM] pen buttons swapped
Summary: [WACOM] pen buttons swapped
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (other bugs)
Version First Reported In: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-04 14:15 UTC by Piotr
Modified: 2019-04-15 11:04 UTC (History)
4 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 Piotr 2019-04-04 14:15:32 UTC
SUMMARY
Lower button on the pen always registers as right click(B=2 in tablet tester) and upper always as middle click(B=4), which is opposite to what I have in wacom tablet properties, switching it there has no effect.

Krita set to WinTab, Windows Ink disabled in Wacom Tablet Properties.

SOFTWARE/OS VERSIONS
Windows: 10 x64 1809 
Krita: 4.2.0-pre-alpha (git d8abbc5)
Tablet: Wacom Intuos Pro M (PTH-660) wired mode, driver 6.3.33-3
Comment 1 wolthera 2019-04-04 18:23:50 UTC
This might be related to our recent attempts at fixing the tablet support with qt 5.12.

Can you attach some of the debug from the tablet tester?
Comment 2 Piotr 2019-04-04 18:44:27 UTC
I don't know how to get more from it, it seems pretty basic. I just observed output like this one (this was with lower button pressed):

...
Stylus move X=63.09 Y=145.23 B=2 P=25.8% (DRAW)
Stylus move X=63.17 Y=145.23 B=2 P=13.6% (DRAW)
Stylus release X=63.17 Y=145.23 B=0 P=0.0%
Mouse release

I just observed B value (bitfield?), how it corresponds with pressed buttons on stylus, and to regular mouse.
What I got is that in this build:
B=1 regular draw, mouse left
B=2 draw with lower stylus button pressed, mouse right
B=4 draw with upper stylus button pressed, mouse middle
This is independent from what I set in tablet preference utility, even if I set for eg. lower button to 'disabled' it still reacts as right button and reports B=2.

I noticed it first, when I wanted to move the canvas, and instead pop-up palette appeared...
Comment 3 Piotr 2019-04-04 18:48:28 UTC
Let me make a guess: Krita/Qt picks up some kind of physical, low level button id instead od one mapped by the driver.
Comment 4 Scott Petrovic 2019-04-05 14:58:55 UTC
There have been some recent changes to the Wintab and WinInk stuff that we have been doing to help fix the Qt 5.12 bugs.

Could you test out the latest Windows nightly build and let us know if the situation is any better?
Comment 5 Scott Petrovic 2019-04-05 15:07:06 UTC
switching to needs info
Comment 6 wolthera 2019-04-05 15:07:53 UTC
Scott, he is on the nightlies, in particular on the build from yesterday, and there haven't been extra tablet changes since then.

https://phabricator.kde.org/R37:d8abbc50a7c2f8032760fe5f5ed150b1f00ad11f
Comment 7 Piotr 2019-04-05 21:23:53 UTC
About krita versions, what I have:
krita-nightly-x64-v4.2.0-prealpha-338-g703cbfbfae all ok
krita-nightly-x64-v4.2.0-HDR-129-g3d29280681 buttons ok, pressure sensivity not working
krita-nightly-x64-v4.2.0-HDR-133-gd8abbc50a7 pressure ok, buttons swapped as in this issue
Comment 8 Alvin Wong 2019-04-06 11:38:04 UTC
Our WinTab implementation might have a specific change to swap the two buttons that isn't in Qt.
Comment 9 Dmitry Kazakov 2019-04-15 11:04:08 UTC
The bug should be fixed now. Qt just didn't use any button information provided by WinTab. Now it is implemented
Comment 10 Halla Rempt 2019-04-15 11:04:57 UTC
Fixed in 

commit 7c7becc740a11ea350e09e10843a8877b1601204
Author: Dmitry Kazakov <dimula73@gmail.com>
Date:   Sat Apr 13 18:25:53 2019 +0300

    Add patch for Qt to support stylus button remapping
    
    The user can remap the stylus buttons using tablet driver settings.
    This information is available to the application via CSR_SYSBTNMAP
    WinTab feature. We should fetch this information every time the
    stylus gets into proximity, because the user can change these settings
    on the fly.
    
    See full patch review:
    https://codereview.qt-project.org/#/c/258966/