| Summary: | [Wacom] Pressure Sensitivity Not Working (only for Krita) 3.1.1 | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Gamekiller48 |
| Component: | Tablets (tablet issues are only very rarely bugs in Krita!) | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | major | CC: | halla |
| Priority: | NOR | ||
| Version First Reported In: | 3.1.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
DebugView log
Picture of the bugged cursor |
||
Created attachment 103719 [details]
Picture of the bugged cursor
Added a picture of the bugged-out mouse cursor that appears while using the pen input
I'm sorry, but this is not a bug in Krita... There is something up, but it's specific to your system. You could make a tablet log to see whether Krita actually can open the wintab dll, but even that doesn't mean a whole lot. The wacom drivers sometimes get really confused about which application gets a wintab context. Last weekend, in three drawing sessions, my own cintiq didn't work with Krita, and after a reboot it did. If you check photoshop forums, there are plenty of complaints about that, too, and even some where the user tells the Adobe people "but Krita works, so it must be a bug in Photoshop". There just isn't anything we can do from within Krita to make the drivers more stable. In an attempt to find the source for the problem I have decided to try out Krita Gemini. The problem is NOT present in Krita Gemini - this application recognizes pressure sensitivity. Since the problem however still persists in Krita, I conclude that the problem is - in fact - not the driver. My hypothesis: Since Krita Gemini was specifically designed for Tablet input, it might use the Windows Ink API for the pen input data, while Krita still uses wintab. A recent Windows 10 update however has enabled Windows Ink as the default input interface for graphic tablets. Krita now hooks into wintab and listens for pressure data, which wintab can't provide as it never receives this data in the first place, since Windows Ink is now the interface between my graphic tablet and my computer. Interesting discovery! Intrigued by why pressure sensitivity works in Krita Gemini and not Krita, I wondered if my first reaction of suspecting Windows Ink truly was correct - so I decided to check for other possible explanations. During this I uninstalled Krita 3.1.1 and rolled back to an older version of Krita - and would you look at that: pressure sensitivity somehow works again! Now, obviously I wanted to find out when exactly this switch from 'working' to 'not working' happened, so I downloaded the installers for all stable releases between the version I got working and the most current one: Krita 3.0, Krita 3.0.1, Krita 3.0.1.1, Krita 3.1.0 and Krita 3.1.1 And it turns out that 3.0 is the only version of all of those that work for me (I haven't checked any older versions than that). It seems like something changed between Krita 3.0 and 3.0.1 that somehow changed how Krita handles pressure sensitivity? Since 3.0.1 was a minor release though, I wasn't able to pin down what exactly changed between those versions. Nope. Krita Gemini also uses the wintab api. The big difference is that Gemini doesn't ask for the tablet name. There are some other changes. BUT: Krita works with wacom tablets for hundreds of thousands of people, including the developers. It turns out you are right. I'll write down how I fixed the error, in case someone uses the bugtracking system to find a solution to the same problem: Step one: reset the multi monitor offset (close Krita, start Krita by mouse, press shift, then press the pen on the graphic tablet) - select the input value that has (wintab) at the end. Step two: press windows+P, change the monitor setting to 'duplicate monitor', then change it back to 'extend monitor' Step three: done. Pressure sensitivity should work again. |
Created attachment 103718 [details] DebugView log First of, this bug is pretty much identical with the bug reports 358428 and 364887 - I chose to submit this as a report of it's own because of different version numbers and an UI bug that doesn't seem to be present in those other two reports. The problem is the following: Using Krita on a Cintiq 13HD, Krita for some reason completely ignores the pressure sensitivity of my pen. It's either 0% (the mouse cursor moves, but the brushes don't transfer anything), or 100% (solid color at maximum oppacity) - shading is impossible this way. System: Windows 10 64bit Krita 3.1.1 (the most recent version at this point in time) Wacom driver 6.3.20-5 (the most recent version at this point in time) Nvidia GeForce Game Ready Driver 378.49 (the most recent version at this point in time, problem also existed with older drivers) Steps to reproduce: 1.Open Krita 2.Use any brush and press on the screen Attempted troubleshooting on my part: - Uninstalling and reinstalling Krita - Restarting the PC - Deleting Krita appdata folder - Uninstalling and reinstalling Wacom drivers - Updating GPU drivers The problem persists. Another problem (apparently connected to this issue) is that the brush cursor looks different while using the pen input, while looking normal when using the mouse. A small black bar appears right below the center of the brush, which is distracting while painting. Sometimes I'm also able to move the mouse independently from the brush outline when using the pen. Taking a screenshot of this bugged-out cursor isn't possible via the windows built in screenshot software (snipping tool or print-button), as the mouse cursor gets disabled/hidden during the screenshot. I would add both a picture of the cursor and a DebugView log of an instance where this error occurs, but it appears I can only add one attachment? The log seems more important however, so I'll attach the DebugView log (I'll take the liberty to censor out parts of the filepaths that contain personal information though.). If any information is missing, please ask, I'll try my best to answer (this is my first bugreport, so there's a good chance I missed something)