Krita on Windows supports either WinTab or Windows Ink.
For more detail see:
(add screenshot)
Changing this setting requires the user to restart Krita.
The Krita UX makes it seem like Krita has specific knowledge about the APIs in use. This used to be the case. But in modern versions of Krita, all pen input handling is done by Qt. Krita just interacts with QTabletEvent.
[ Tablet Driver ]
↓
(WinTab OR Windows Ink / WM_POINTER)
↓
[ Qt Windows Platform Plugin ]
↓
QTabletEvent
↓
[ Krita Application Code ]Krita does not directly implement WinTab or Windows Ink. Krita delegates all tablet input handling to Qt, and only configures which API to use when the Qt application starts.
See: https://krita.org/en/release-notes/krita-5-3-release-notes/
Krita has been using Qt5 for a long time. In March 2026, Krita started moving toward Qt6.
Krita 6 is the first version of Krita that uses Qt6.
On Windows, Qt supports two mutually exclusive tablet input paths:
WM_POINTER (the default)
WinTab
See: WinTab vs WM_POINTER
To consume tablet data, use QTabletEvent. See QTabletEvent, which abstracts away the pen API.
What happens:
User selects WinTab in Krita UI
Krita saves a config value
User restarts Krita
On startup, Krita reads the config
Krita configures Qt’s Windows backend based on the config
Qt chooses the tablet backend during platform plugin initialization. Specifically, this happens in the Windows platform plugin.
Initialization happens BEFORE QApplication is fully running.
Qt cannot hot-swap WinTab ↔ Windows Ink.
The WM_POINTER/WinTab decision must be made at process startup.
Qt6 is new for Krita (starting in Krita 6.0 in March 2026).
The paths are slightly different for Qt5 and Qt6 in Krita. See the Implementation notes.
Callers such as Krita do not know which API is being used at runtime. They may, of course, remember how they configured Qt to start.
Last updated