Type of device* : Graphics tablet
Brand and version of the device: Huion Inspiroy H610 Pro V2
System** : Windows
* graphics tablet/display tablet/2-in-1 laptop/Android tablet
** Windows/Linux/Mac/Android, + version (you’ll find it in Help -> Show system information for bug reports)
Description of the issue (you can include screenshots):
I’m having trouble getting the right click on my stylus to work while in Krita. It works fine on my desktop. Sometimes it works on google chrome, sometimes it doesn’t.
In Settings → Configure Krita → Tablet settings → Open Tablet Tester,
hovering over the grid and pressing the upper stylus button, sometimes I get nothing, sometimes I get B = 2 recorded as part of that event.
In Settings → Configure Krita → Canvas Input Settings,
I expanded the Zoom and Rotate group then double-clicked on Add Shortcut,
pulled down the drop down and selected Mouse Button,
double-clicked in the Input field to get Edit Mouse Input, the Mouse Button entry said ‘None’.
Clicked that and it asked for Input. Used the stylus upper button in there and sometimes it detected it as a ‘Right Button’, sometimes nothing at all.
Going back in, expanded the Show Popup Palette group.
The Mouse Button said Right Button for Activate.
However, the pop up pallete is still not showing when I right click with my stylus.
Well, that’s how I wanted to start too, but @AhabGreybeard was once again faster…
But I’m posting it anyway, despite possible partial redundancies:
What version of Krita, and what Windows exactly are you using?
Have you tried right-clicking (RMB) to bring up the pop-up palette, and if so, does it work?
Have you created a separate profile for Krita in the driver interface of your graphics tablet, and have you done the same for all other programs you use with your graphics tablet? If you haven’t done so yet, please do so to avoid collisions between the different programs and their functions, and to customize each program individually.
To create a profile, in the current Huion drivers, click on the drop-down box labeled “All Programs” in the title bar and select the program you want to configure. As said, do this for each program!
I am using Windows 11.
The RMB only works when using my mouse.
I have created a separate profile for Krita in the driver interface of my graphics tablet.
Do you mean the Chrome browser on Windows or ChromeOS on a Chromebook?
The stylus button press is sometimes not being sent to krita.
That suggests a fault in the stylus/tablet itself.
However:
It could be a strange tablet driver and OS interaction problem.
Krita and other applications do not ‘talk to’ the tablet. They listen to the OS which interacts with the tablet driver. Various things can cause problems with that pathway of events and messages.
Do you have any other peripherals which required you to install drivers for them?
Do you have any ‘assistance’ utilities that map keyboard presses to particular functions?
Do you run any games on your PC?
Make sure that you are not running any other applications when you’re using krita if there are strange tablet problems like this.
Even so, it may have been damaged by a Windows update. It can happen.
A full uninstall of the tablet driver followed by reinstallation and reworking of the configuration and settings would be needed to fix that problem in that case.
As a final and simple thought, does the Wintab vs Windows Ink setting in krita match the Windows Ink setting in the tablet settings.
I’d suggest that you use Wintab and disable Windows Ink in the tablet settings.
It’s in the Krita Default profile. Do you use that profile?:
You simply disable the Windows Ink option in the tablet utility to have Wintab.
In krita you must also have Wintab selected in Tablet settings.
Close the tablet utility and restart krita to make sure all changes are carried out.
Did you remake application specific profiles and make all settings as they were before.
If this is a result of using Wintab instead of Windows Ink then you may need to go back to using Windows Ink, even though that can have its own complications caused by the OS level Windows Ink ‘assistance’ options which are set at the OS level.
You have a large collection of things that can interfere with OS level software and its driver interaction and are deliberately designed to do so!
Please consider this: All over the world, there are many thousands of people who use krita on Windows with many different makes and models of graphics tablet and they don’t have any problems.
I have no idea what effect or consequences that might have.
After disabling the Windows Ink option in the tablet utility and having Wintab selected in Tablet settings. I restarted Krita and now my pen is completely unresponsive when hovering over my tablet.
Yes I remade application specific profiles and made all settings as they were before. This was not a result of Wintab, I was using Windows Ink when I used the right click in the Tablet Tester.
What keyboard and mouse combination works okay with Krita?
I am using a Logitech “G602” 11 button wireless mouse and as a tablet from Huion the “NEW 1060PLUS(8192)” also referred to as the “Inspiroy H1060P”, the keyboards are a full size keyboard from LogiLink via USB cable and a small wireless keyboard with no label or manufacturer name. I am running the tablet in administrator mode on a Z620 workstation from HP.
OS: Windows 10 Pro x64;
CPU: 2x XEON E5-2643 v2 @ 3.5 GHz;
96 GB RAM;
Graphics card: Radeon RX 580 8 GB RAM;
In addition, I have a lot of other hardware that I can connect and disconnect individually via USB hubs, with switches for each port.
With me, this runs smoothly!
That list of ‘supported tablets’ is not actually a list of tablets that krita is designed to support. It’s a list of tablets that have been reported as working with krita either by the developers themselves or by users who report their findings.
Krita is designed to support any tablet that correctly provides (via its driver and the operating system) signals that conform to the expected Wintab or Windows Ink standards of tablet output signals.
After mapping my right click to a different button on my pen. i.e. The bottom button rather than the top button, I can now successfully right click and open up the pop-up pallete.
However, now I have a new issue. After opening the pop-up pallete, my cursor disappears while hovering over the pop-up pallete.
I hope you don’t mind my jumping in. This is very interesting. You’re the first person I’ve heard of where a mis-match works (using WinTab in Krita yet Windows Ink in tablet interface). Maybe I can learn something new from your setup.
When you create brushstrokes in Krita’s tablet tester, do you get mouse and stylus moves and pressure %?
Using Windows 10 and my old Wacom CTH 490/K tablet, I tried setting krita to Wintab and the tablet to Windows Ink.
It worked but there were more than the usual number of Mouse Moves mixed in among the Stylus Move events.
With my usual Wintab at both ends, there are a few regular Mouse Moves among the Stylus Move events. (I didn’t try the two other possible combinations.)
On my Linux system, which can only be Wintab, there are no Mouse Move events when I use the stylus.
I have no idea what the cause or significance of all that is.
It should be remembered that many stylus/tablet problems with pressure sensitivity have been solved by changing settings so that the Wintab vs Windows Ink settings are the same at both ends.
This implies that tablet drivers combined with the Windows OS show variation in behaviour and I wouldn’t be surprised if that changed from tablet model to tablet model and from driver version to driver version or from Windows update to Windows update (or even from day to day or different phases of the moon).
Krita listens to what it’s told and that’s all it does. Sometimes it can make sense of what it’s told and sometimes it can’t.
I usually have upper stylus button set to right-click (B=2 tablet record) and lower button set to middle-click (B=4 tablet record).
If I swap those settings over then I get lower button gives B=2 tablet record and the popup palette, with upper button gives B=4 tablet record and the Pan hand for no-contact panning.
I have no technicall/functional problems with that arrangement and both actions work fine in their usual functional way.
(Note: It seems that the B=2 and B=4 tablet records do not indicate which stylus button has been pressed. They indicate which click-action has been activated.
That can be confirmed by setting one of them to Space for contact panning and observing that the tablet record shows B=0 or B=1 depending on no-contact or contact on the tablet surface.)
When I activate the popup palette and hover over it, the on canvas painting cursor changes to the ‘system’ cursor, as it does when I move the painting cursor outside of the painting workspace, e.g. onto a docker.
The situation with your tablet-driver-OS combination seems to be unusual.
I have no idea why that is or how the various problems could be fixed
