Bug 427302 - Timing problem with Huion Kamvas pro 20 stylus for on canvas tool chooser.
Summary: Timing problem with Huion Kamvas pro 20 stylus for on canvas tool chooser.
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tablets (tablet issues are only very rarely bugs in Krita!) (show other bugs)
Version: 4.3.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-03 17:28 UTC by popolon
Modified: 2020-10-03 18:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description popolon 2020-10-03 17:28:05 UTC
SUMMARY
On a Huion Kamvas pro 20, using it's own driver directly in Xinput, or with Wacom driver mapping, when I click on rear button (equivalent to right mouse button) to select a tool or change color on canvas, the chooser disappear immediately. I have to do a very very short click on the button to keep the chooser open

STEPS TO REPRODUCE
1. launch Krita
2. press the second button of the pen (near from user) the chooser appear
3. release the second button to move and choose tool or color => the chooser disappear.

OBSERVED RESULT
* With a very short click it works, the chooser still display after release, that's OK
* With a standard click-release < 0.5s but not very short, the chooser appear and disappear synchronously.
* With a long press and release, when the button is pressed the chooser is displayed, and at the moment the button is released, the chooser disappear.

EXPECTED RESULT
the chooser should be left open, to be able to choose color or tool.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:  Arch Linux on x86_64, Krita 4.3.0
(available in About System)
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1

ADDITIONAL INFORMATION

I use Wacom mapper, I mean, in /etc/X11/xorg.conf.d/50-tablet.conf
<pre>
Section "InputClass"
    Identifier "Tablet"
    Driver "wacom"
    MatchDevicePath "/dev/input/event*"
    MatchUSBID "256c:006e"
EndSection
</pre>
I tested previously Krita without this mapping, everything has the same behavior, using this mapping has other advantages on os settings (multiscreen management)

I tested with evtest how behave the button, if there was some flip-flap or something like, that, everything works like the mouse. this button is seen as a right mouse button more generally and works well on different applications

The button event is reported as this by evtest, so correctly (only 1 press event at moment where I start to press the button and and 1 release event at release time) :
<pre>
Event: time 1601743953.270929, type 1 (EV_KEY), code 332 (BTN_STYLUS2), value 1
Event: time 1601743953.336980, type 1 (EV_KEY), code 332 (BTN_STYLUS2), value 0
</pre>

With my mouse where the access to the chooser works finely, I have eactly the same behavior :
<pre>
Event: time 1601743905.219164, type 1 (EV_KEY), code 273 (BTN_RIGHT), value 1
Event: time 1601743905.419162, type 1 (EV_KEY), code 273 (BTN_RIGHT), value 0
</pre>

I notice that on top menu, when I click on this button, a menu appear (starting with toolbox, not the menu displayed, that appear with left mouse button), it appear it is kept shown, or disappear, depending on the very sensible move of the stylus. if I let the button pressed, I can access finely on its elements.

Is there other tool I could test, the problem is probably at another layer or linked to another tested event ?
Comment 1 Tiar 2020-10-03 17:31:06 UTC
Can you please check if it works better in an appimage? (Appimages has different version of Qt and contains some patches, including tablet support ones).
Comment 2 popolon 2020-10-03 18:30:12 UTC
I tried with appimage linked from Krita website (krita-4.3.0-x86_64.appimage) and it works just fine.
Comment 3 popolon 2020-10-03 18:39:54 UTC
Thank you very much for your quick answer, hope it will help other too :).