The majority of help requests are about pen pressure and tablet support in general.
With every change mentioned below you might need to restart your PC to see the effect.
For Windows, all devices:
Change API in.
Wintab: older standard; it supports multiple buttons and high number of pressure levels. If it works fine for you, don’t change to Windows Ink. 2-in-1 devices by default use Windows Ink, you can get a Wintab driver but you need to install it separately.
Windows 8+ Pointer (Windows Ink): newer standard; it cuts the pressure levels to 1024. It is more suitable for 2-in-1 devices like Surface Pro and Yoga. Some less known brands might not have this standard implemented.
For Windows, tablet/digitizer devices (not convertible/2-in-1 ones):
Reinstall your driver (Windows Update often breaks tablet driver settings, reinstallation helps).
Wacom tablets: if you get straight lines at the beginnings of the strokes, first try to update your driver: it should be fixed in 6.3.34-3. If it doesn’t work, disable/minimize “double-click distance” in Wacom settings.
XP-Pen tablets, pressure being uneven: either switch to Windows 8+ Pointer (Windows Ink) in, or disable Windows Ink in XP-Pen settings.
Which OS do you use?
Which tablet do you have?
What is the version of the tablet driver?
Please collect Tablet Tester (How to share a file.) text output and share it:
More detailed Tablet Events log:
Go todocker, make sure it’s checked.
In the Log Viewer docker, make sure the first button is pressed (which means the logging is turned on).
Press Ctrl + Shift + T to turn on tablet events logging.
Make a few strokes (depending on the situation, the user supporter or developer can ask you for specific series of strokes).
Press Ctrl + Shift + T to turn off the logging of the tablet events.
Press the third button in the Log Viewer to save the output into a file.
Share the file or share the content of the file: How to share a file.
On Linux, you can just use a console instead of Log Viewer – then you’d only need to enable tablet events logging, not logging in general.
Except for the issue with beginnings of the strokes, Wacom tablets usually work no matter the OS.
Huion tablets should work on Windows and on Linux, on Mac there might be issues.
XP-Pen tablets and the rest of brands can have issues everywhere (on all systems).
If someone asks about a tablet to buy, generally a cheaper Wacom or a Huion are the best options as of 2019, if they want to work with Krita. The List of Supported Tablets.
Issues with rendering animation can be of various shapes and colors. First thing to find out is whether the issue happens on Krita’s or FFmpeg’s side (Krita saves all the frames, then FFmpeg is used to render a video using this sequence of images). To learn that, instruct the user to render as “Image Sequence”. If the image sequence is correct, FFmpeg (or more often: render options) are at fault. If the image sequence is incorrect, either the options are wrong (if for example not every frame got rendered), or it’s a bug in Krita.
If the user opens the Log Viewer docker, turns on logging and then tries to render a video, Krita will print out the whole ffmpeg command to Log Viewer so it can be easily investigated.
There is a log file called log_encode.log in the directory that user tries to render to. It can contain information useful to investigation of the issue (sharing files: How to share a file).
The great majority of issues with onion skin are just user errors, not bugs. Nonetheless, you need to find out why it happens and direct the user how to use onion skin properly.
In case of crash try to determine if the problem is known, if not, instruct user to create a bug report (or create it yourself) with following information:
What happened, what was being done just before the crash.
Is it possible to reproduce (repeat)? If yes, provide a step-by-step instruction to get the crash.
Backtrace (crashlog) – the instruction for Windows is here: Dr. MinGW Debugger, and the debug symbols can be found in the annoucement of the version of Krita that the user has. But it could be easier to just point the user to https://download.kde.org/stable/krita.
When the user has any weird issue, something you’ve never heard about, ask them to reset the configuration: Resetting Krita configuration.
When the user has trouble with anything related to preview or display, ask them to change Canvas Graphics Acceleration in .
Telling people to disable canvas acceleration to get better performance is something we shouldn’t do, ever.
If you don’t understand the question, ask for clarification – asking for a screen recording or a screenshot is perfectly fine.
If you don’t know the solution but you know what information will be needed to investigate the issue further, don’t hesitate to ask. Other supporters may know the answer, but have too little time to move the user through the whole process, so you’re helping a lot just by asking for additional information. This is very much true in case of tablet issues, for example.
If you don’t know the answer/solution and the question looks abandoned by other supporters, you can always ask for help on Krita IRC channel. It’s #krita on freenode.net: The Krita Community.
Explain steps the user needs to make clearly, for example if you need them to change something in settings, clearly state the whole path of buttons and tabs to get there.
Instead ofuse just – it’s easy enough to find and Mac users (where you need to select ) won’t get confused.
If you want to quickly answer someone, just link to the appropriate place in this manual page – you can click on the little link icon next to the section or subsection title and give the link to the user so they for example know what information about their tablet issue you need.