| Summary: | stylus detection fails when switching back to krita with pen detected by tablet | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | Manga Tengu <mangatengu> |
| Component: | Tablets (tablet issues are only very rarely bugs in Krita!) | Assignee: | vanyossi <ghevan> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | dimula73, ghevan, halla, penguinflyer2222 |
| Priority: | NOR | ||
| Version: | 4.4.2-beta2 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Manga Tengu
2020-12-29 01:07:55 UTC
Noticed it works better when krita is in full screen mode. That's a workaround Yes, I can reproduce this. I am not sure we can fix it, though, because when I check with the tablet tester (from the settings app), that also just get mouse events when drawing a stroke after clicking on the window to switch to it from another application. It looks like the os sees a mouse-down now matter what, so sends mouse events instead of stylus events to the applications. When I test this with clip studio, clicking on the canvas just gives clip studio focus, but you have then to click again to start a new stroke. Okay, now I am confused. I've tested both on my 2015 intel mac with 5.1.1 and on my m1 pro with current master. The intel mac runs 10.14.6, the m1 12.6. On both macs I can now cmd-tab to finder, do some stuff, cmd-tab back and when I touch the tablet tester or the canvas, I can draw with pressure from the get go. In neither case does Krita run full-screen. No need to first click somewhere in the ui To reproduce it as of right now, I open krita and overlay another app over it, like telegram. I am in telegram doing stuff I decide to dive back in krita -> I click with my stylus directly on the canvas while not focused on krita and I can observe the strange behavior. Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information. I've finally managed to understand and confirm the issue. And I can confirm it's a bug in Krita itself because the tablet tester gets the correct pressure. Litterally claimed "Wouhou!" Can't wait for the fix! Thanks! I've noticed this problem too, didn't know there was a bug report.
What I've found in my testing is, on macOS Krita doesn't receive a TabletEnterProximity ("Pen tip brought near") event when receiving focus
with the stylus near, but on Windows it does.
Steps to reproduce:
1. Lift the stylus away while focused in Krita
2. Switch to another window and bring the stylus back while in that window
3. Switch to Krita without lifting the stylus away
Result:
On macOS, Krita thinks the stylus is still away and treats it as a mouse (as seen in the tablet tester).
On Windows, Krita knows the stylus is near and treats it as a stylus.
We probably need to discuss this bug during the Monday meeting; however, next Monday is a hospital day for me, and I'm not sure I'll be back in time. Weirdly enough, the tablet tester doesn't show this problem! It seems these are two bugs comment #6 describes krita is not painting correctly despite the tester showing the correct pressure. This behaviour I cannot reproduce (Sonoma macOS 14.4.1, Intuos PS CTL-490, driver 6.4.6-3) The later commented in comment #8 its easy to reproduce, however the tablet tester shows the pointer is seen as a mouse. - I need confirmation that the first issue (stylus loosing pressure with the tablet tester reporting it as a stylus) is present on the latest macOS version, and if you can reproduce it a detailed steps to do so. I tried all suggestions and some more I could think of but I never lost painting with pressure. Hello, yes the original issue is still present in sonoma 14.5 The tricky detail is you need to use another pointing device and then come back to krita: -paint and leave all the UI like you were interrupted by mistake (the cat jumped on the keyboard and hit cmd tab) -then the malicious cat also clicked around with the mouse, not your pen <-- the detail -but you gain back control over the cat and switch back to krita with another cmd tab -you directly make a new brush stroke (you *don't* get near the tablet *without* touching and then away before making a stroke, that's the work around) -you should witness a 100% opacity brush stroke your mouse would make... About the tablet tester, this is an extra info added by participants but the original issue is just about the behavior (the insensitive brush stroke when back in krita) |