When using a Wacom Penabled TabletPC (Thinkpad X201T, X230T, Cube i7 Stylus) with a 2 button/switch stylus (UP-911E-02DD) under Windows 10, Krita does not react to the Top Barrel Button's mouse event on canvas. Reproducible: Always Steps to Reproduce: 1. Windows 10 X64 (not tested on other versions of Windows) 2. Krita 3.0.1 3. Wacom Penabled Tablet PC (like: Thinkpad X201T, X230T, Cube i7 Stylus) 4. Wacom Penabled compatible 2 barrel switch stylus (like: UP-911E-02DD) 5. Wacom Feel Driver installed, checked "Use 2 button Pen" and "Hover Click", Unchecked "Show ripple effect", set Top Barrel Button to Right Click, Bottom to Middle Click. (same as Ubuntu) Actual Results: Top Barrel Button (mapped as Right Click at the moment) cannot call up Krita's Popup Palette on canvas. In fact, no matter what mouse event you assigned to the Top Barrel Button, Krita does not react to them on the canvas. However, In Settings>Canvas Input Settings, Krita can read the signals sent by the Top Barrel Button. Meanwhile, Top Barrel Button Right click seems to be recognized by other apps on the same Windows 10 system. Expected Results: Krita react to the Top Barrel Button mouse event on its canvas. Workaround: 1. In Krita's Settings>Canvas Input Settings, change your target action into "Key combination". In this case, add a Key combination shortcut "Ctrl+P" to "Show Popup Palette". 2. In Wacom Feel Driver, map Ctrl+P to Top Barrel Button.
Hey Tyson, could you make a tablet-log? That way we can see what Krita thinks the top-barrel is.
Created attachment 101172 [details] Krita under Windows 10 Cube i7 Stylus Top Barrel Button tablet log Hi, wolthera I don't know exactly what the tablet log was saying, but it seems Krita thinks the top barrel button belongs to a mouse and block its signal?
Yeah, it seems the backside/topbarrel is seen as a mousevent instead of a tablet one. And thus blocked for some reason.
Thats pretty old bug but i can actually confirm that still exists. Thing is that you can open this popup menu but you have to right click outside of canvas ( i click on top bar, not sure what the name of this is but you will get Toolbox, Tool Options, Grid and Guides, Palette etc. menu. With this menu opened just click top pen button when mouse cursor is in range of Canvas. It works but sure there is some problem. Ive tested this on Surface pro1 (win8.1) and cube mix plus (win10). Both with up817e and up814 pens.
I have some information to add too, and not a good news. On newer Surface models (maybe SP3 and newer) and most convertibles that uses Wacom AES pen technology, the pen barrel buttons can't be mapped to both middle click and right click. Under Windows you can only map the barrel buttons to right click. Under Linux you can assign the upper button to anything, but the lower button is locked as eraser mode trigger. I believe Wacom purposefully did this to most Wacom AES digitizers they supplies to 3rd party manufacturers for non-tablet portable PCs. The device's API is so over enigmatized there is no way a person outside of Wacom can figure out how to customize the thing. I have a Lenovo Yoga 730 that has exactly this problem and I can confirm that every convertible (Dell, HP) I tested with a similar design that share pens, all of them behaves the same. Only Lenovo Miix 520 can do the mapping properly (but it is not an ideal competitor to MSP13 due to short battery life and small screen). Thus Krita is having difficulty promoting itself to the users of most Surface like owners. So this bug is better off become a request of 2 new features: 1) Allow Krita to accept mouse click events while the stylus is in range. In this way we can use a mouse/touchpad/trackball to recreate middle/right click. Right now, I must lift up the stylus before Krita would accept any mouse events. 2) The ability for Krita to map a stylus's eraser to something else, or just to emulate right click or middle click.
I'm horribly afraid that that isn't even possible the way Qt handles events :-(
(In reply to Boudewijn Rempt from comment #6) > I'm horribly afraid that that isn't even possible the way Qt handles events > :-( It's okay, this issue was basically Wacom being stingy and tries to screw over its customers. It's unnatural for an application to workaround a deliberately devised hardware limit. If it's impossible, let's just close this bug. On the other hand... Is it possible for Krita to directly handle xinput (the event system used by gamepads)? I'm currently using a gamepad and assigned right-click to one of its buttons alongside with other Krita shortcuts. It works pretty well although I had to use a event translator like antimicro to achieve this. As far as I know, there are many other artist who use a NES style wireless/bluetooth gamepad to do the same thing in place of Wacom's overpriced, overcomplicated Expresskey Remote Controller. This is really a productivity booster, especially for those who lives in a tight space. If it is easily feasible for Krita to handle xinput, and you are not against the idea, I would love to submit a wishlist report! ;)
(In reply to Tyson Tan from comment #7) The reason I would love to have direct xinput support in Krita is because an event translator like antimicro has a lot of limitation and introduces delay and key event congestion issues. It is also technically complicated. So if Krita can just assign actions to gamepads, it would be a life-saver.
I think it could be done, but it wouldn't be easy!
Qt Gamepad [1] is actually a thing, and that uses XInput on Windows. [1]: https://doc.qt.io/qt-5/qtgamepad-index.html
Git commit c30c6f424c4226531738c93a5d01548e986cba8a by Dmitry Kazakov. Committed on 17/04/2019 at 17:30. Pushed by dkazakov into branch 'master'. Implement a hack for right- and middle-buttons on weird tablet devices If should fix the following cases: 1) Wintab drivers that do not generate tablet events for right-click and middle-click. 2) WinInk mode. With the patch both right- and middle-clicks should be available with the stylus buttons. To activate a workaround just add the following to your 'kritarc': rightMiddleTabletButtonWorkaround=true This hack just ignores tablet events for right- and middle-click and starts to use mouse events for them. Please be careful, the hack will make right- and middle-strokes less precise. And it also can just break the tablet support completely. Related: bug 399585 M +0 -5 libs/ui/input/kis_input_manager.cpp M +36 -6 libs/ui/input/kis_input_manager_p.cpp M +3 -2 libs/ui/input/kis_input_manager_p.h https://commits.kde.org/krita/c30c6f424c4226531738c93a5d01548e986cba8a
Hi, all! Could you please test this package and check if the workaround fixes the problems you had? The patch affects both modes, Wintab and WinInk. https://yadi.sk/d/db3yUdmPLm8wAg 1) Unpack the package 2) Add to %LOCALAPPDATA%\kritarc: 'rightMiddleTabletButtonWorkaround=true' 3) Run Krita, if needed, activate WinInk or Wintab and restart 4) Test the problem
I can confirm that this workaround works.
Great! Then I can close the bug! Thank you everybody for helping with testing and generation of log files. They helped a lot! :)