For unknown reasons, my custom hot-key of ctrl+middle mouse is not working with my tablet. At the same time, Krita stopped recognizing pen pressure from my tablet. My tablet is an old Bamboo (CLT-470). Middle button+touch is still performing "zoom" as I wish it to, but stuttering like it's losing frames. This is the second time this version of Krita has failed to properly recognize my tablet's settings, particularly the "middle mouse button". My tablet's settings are properly set up in both Krita and in my computer. Closing and reopening Krita did not fix this, unplugging and replugging in my tablet did not fix this. Nothing changed with Krita or my tabet. The hotkey still works for mouse controls, and the tablet is communicating perfectly with everything else that isn't Krita. I have no tried a reboot at this time as my computer takes ages to reboot. Will update once I have had a chance to reboot. STEPS TO REPRODUCE 1. Leave Krita idle for extended period of time? 2. ??? 3. ???I have no idea OBSERVED RESULT Pen pressure not functional, middle mouse button (on tablet) + keyboard input not functional. EXPECTED RESULT Pen pressure and button responsiveness. SOFTWARE/OS VERSIONS Windows: 10 Home 2004 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.12.9 ADDITIONAL INFORMATION Krita Version: 4.4.2 Languages: en_US, en Hidpi: false Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.19041 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: true Hardware Information GPU Acceleration: auto Memory: 16327 Mb Number of Cores: 8 Swap Location: C:/Users/Christina/AppData/Local/Temp Current Settings Current Swap Location: C:/Users/Christina/AppData/Local/Temp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 30 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 900 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 1 Screen: 0 Name: \\.\DISPLAY1 Depth: 32 Scale: 1 Resolution in pixels: 1920x1080 Manufacturer: Model: Refresh Rate: 60
Update following a reboot: full computer reboot fixed the error, however Krita was still the only program that had a problem with the tablet. I never previously had issues with Krita and my tablet before this version of Krita, so I'm certain the issue is primarily on Krita's end.
Sorry, but tablet issues are really almost never actually bugs in Krita. Tablet drivers keep per-application data which means that sometimes a tablet will not work for one or another application, but still work for others. That doesn't mean it's a bug in the application.
(In reply to Halla Rempt from comment #2) > Sorry, but tablet issues are really almost never actually bugs in Krita. > Tablet drivers keep per-application data which means that sometimes a tablet > will not work for one or another application, but still work for others. > That doesn't mean it's a bug in the application. Almost never. That doesn't mean Always Never and I would appreciate it being looked into a _little_ more than "it's your tablet" and "it's not a bug", please. I first encountered the issue when I updated Krita several months ago. It's been stable since then, until last night when I returned to working in Krita after having it open and idle for a few hours and the issue returned until a reboot. Before that idle period Krita and the tablet had both been working together perfectly fine. I frequently leave Krita idle, and my tablet is almost always plugged in. Again, I Never had tablet issues with Krita prior to my current version of Krita. The tablet model itself is too old to have driver updates, so it's not anything that's changed with the drivers, but when the issue first occurred I did uninstall and re-install the drivers to be safe. The issue is on Krita's end, not my tablet. Something about the Krita update as caused it to occasionally "forget" my tablet settings for no readily apparent reason.
Okay, let me put it stronger: we _cannot_ look into this. This is something specific to your setup, which nobody else is going to be able to reproduce. That is really clear from where you say "it worked again after a reboot". We cannot fix things that are not problems in Krita's code, and this isn't a problem in krita's code, but in the tablet driver and/or windows.