SUMMARY STEPS TO REPRODUCE 1. Plug in a Wacom Intuos drawing pad into a Chromebook that supports Android apps. Krita 4.4.1 installed. 2. Try to draw and make it recognize pen pressure. OBSERVED RESULT Pen pressure is completely ignored even if the pen pressure button is available and turned on. It works with the Pixel Slate pen, but not with the Wacom Intuos 4. EXPECTED RESULT What's important to note here is that another popular drawing/photo editing software Photopea (www.photopea.com), IS able to recognize this pen pressure just fine. In fact, it's a web based "app" and yet it's able to use it properly. I'm hoping that Krita would consider adding this device. Many artists use Wacom drawing tools and now with Android Krita on a Chromebook (which are getting really popular with students/school and the generic population), I think it would be worthwhile to get this feature working. SOFTWARE/OS VERSIONS Device: Google Pixel Slate (i5 model) ChromeOS: Stable 86 Android app (early access): Krita 4.4.1
Since I made this feature request, I've also discovered that the progressive web app (PWA) https://canvas.apps.chrome/ by Google also detects pen pressure and works really well with Wacom. They have a different problem whereby the cursor remains as an arrow when drawing for some reason. But that's beside the point.
Hello! Someone did mention this bug in the past. Unfortunately I don't have the right hardware to debug this. So, could you please use the beta from https://krita.org/en/item/first-beta-of-krita-4-4-2/ and then attach the tablet events log: https://docs.krita.org/en/contributors_manual/user_support.html#gathering-information Note: I suspect events to come as Touch Events, which we only started recording since krita-4.4.2
(In reply to Sharaf from comment #2) > Hello! > > Someone did mention this bug in the past. Unfortunately I don't have the > right hardware to debug this. So, could you please use the beta from > https://krita.org/en/item/first-beta-of-krita-4-4-2/ and then attach the > tablet events log: > https://docs.krita.org/en/contributors_manual/user_support.html#gathering- > information > > Note: I suspect events to come as Touch Events, which we only started > recording since krita-4.4.2 Thanks for responding. I can definitely do this and more than happy to "supply the hardware" to get it working. I'll try and install that later. It's an APK and requires I do a bunch of non standard stuff to get it installed: https://chromeos.dev/en/android-environment/deploying-apps But I will do that and report back once I have the log.
Ok, got it done BUT... I successfully installed it. But when I enable logging and do strokes, nothing is recorded. I tried multiple times using the mouse and the wacom pen. Nothing. It records pressing various brushes and stuff just fine. I can see those. But mouse clicking isn't recorded at all when drawing lines on the canvas. Furthermore, the wacom pen no longer draws at all in this beta. It was drawing before the beta, just no pressure. Now it doesn't draw at all.
Confirmed in About it's 4.4.2-beta1
(In reply to Luc from comment #4) > Ok, got it done BUT... > > I successfully installed it. > > But when I enable logging and do strokes, nothing is recorded. I tried > multiple times using the mouse and the wacom pen. Nothing. It records > pressing various brushes and stuff just fine. I can see those. But mouse > clicking isn't recorded at all when drawing lines on the canvas. Did you press the "Enable Logging" button in the Log Viewer Docker (bottom left button https://imgur.com/3AYcNcO.png)? > Furthermore, the wacom pen no longer draws at all in this beta. It was > drawing before the beta, just no pressure. Now it doesn't draw at all. This is interesting and could be caused by me removing my old patch for Qt https://invent.kde.org/graphics/krita/commit/801692e4841afa3c5f1fb7b7305fda1de3b55b29 this does give me a little clue as to where the problem might lie. Though a proper log would be more useful :)
(In reply to Sharaf from comment #6) > (In reply to Luc from comment #4) > > Ok, got it done BUT... > > > > I successfully installed it. > > > > But when I enable logging and do strokes, nothing is recorded. I tried > > multiple times using the mouse and the wacom pen. Nothing. It records > > pressing various brushes and stuff just fine. I can see those. But mouse > > clicking isn't recorded at all when drawing lines on the canvas. > > Did you press the "Enable Logging" button in the Log Viewer Docker (bottom > left button https://imgur.com/3AYcNcO.png)? > > > Furthermore, the wacom pen no longer draws at all in this beta. It was > > drawing before the beta, just no pressure. Now it doesn't draw at all. > > This is interesting and could be caused by me removing my old patch for Qt > https://invent.kde.org/graphics/krita/commit/ > 801692e4841afa3c5f1fb7b7305fda1de3b55b29 this does give me a little clue as > to where the problem might lie. Though a proper log would be more useful :) I did. Like I said, I can record other events like pressing a new brush button. But when I click, nothing is recorded at all. I can export a log of button pressing.. but that won't be very useful to you. lol Interesting indeed. Now that I know something was done, I can also tell you that in the last version, the brush was represented by the proper little circle when hovering over the canvas. But now in this beta, I have the circle but also a large mouse cursor. Presumably this mouse cursor shouldn't be there and may explain why it's not drawing. If I use the actual mouse (NOT wacom mouse), then it draws fine and the cursor disappears. So yeah, sounds like you're in the right section of code.
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.
Assigning this to myself.
Thanks for taking this on. Obviously it's the holidays, but as you need any testing from me, don't hesitate to ask.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/655
Hello, I think I have fixed the problem, could you please test this APK: https://drive.google.com/file/d/1vuZvqG8UdgTOl_3ds5kNfDzCD7yEK05-/view?usp=sharing It is signed with my key, so it may require you to uninstall the existing one. I've also added some debug statements in case this doesn't work. Hopefully we won't need them :) PS: This is built from master with some symbols being built without optimizations, so it being slow is normal and expected.
Git commit 6fe29b52ff896a2766d42964aea217966af61173 by Halla Rempt, on behalf of Sharaf Zaman. Committed on 19/01/2021 at 09:53. Pushed by rempt into branch 'master'. Android: Properly handle tablet events Qt didn't properly pass down tablet events which caused problems with hovering, TabletPress/Release. Related: bug 423299, bug 431611 D +0 -76 3rdparty/ext_qt/0098-Handle-Primary-and-Secondary-stylus-buttons-on-Andro.patch A +107 -0 3rdparty/ext_qt/0102-Android-Properly-handle-Tablet-events.patch M +1 -1 3rdparty/ext_qt/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/6fe29b52ff896a2766d42964aea217966af61173
OK, just gave it a shot. Mostly good news... So it appears that it now recognizes pen pressure! Hooray! So things seem to be working. BUT... 1. There is a huge lag, I'm hoping it's because of your comments that it's supposed to be slow and will be fixed once it's finalized properly. I've actually submitted a different request a while back (December) about pen lag but that was using the Pixelbook pen. Wacom WAS super fast but definitely isn't anymore. Anyways, just want to make sure this is expected in this prelim release. 2. The bigger issue left is that no matter what, I have a black mouse cursor present. I can see the brush, but it also has a stuck mouse cursor on top of the canvas. That mouse cursor would need to be removed when you're in the canvas area but reappear when you leave the canvas so when you access menus and such, it would work. But awesome that you got the pen pressure working! Once the basic bugs have been ironed out, I'll get my wife to actually try it. She's the actual artist and is quite proficient with Krita. She'll better be able to evaluate if everything behaves as an artist would want. I'm just the "tech brains" in the family. lol
Just to add, the latency seems to improve if the brush size is reduced. So when I reduce it, it's much better. Somehow increasing the brush size adds lag.
OK, my wife indicated that it's pretty normal for lag to increase with brush size. With that being said, once the cursor problem solved, maybe you can also have a look at bug id 430829. lol I don't know if you can improve that, but once again there are apps that do a much better job on latency. Anyways, that's another topic. Hopefully you can remove the mouse cursor correctly.
Thanks for testing! 1. Yes, the lag is very much expected with my APK, because I built some symbols without any optimizations and there is a ton of verbose output. (which we didn't need, yay!) 2. Reading past comments, do I understand this correctly? There wasn't Mouse cursor in the version downloaded from Play Store and it did draw but the pressure didn't work. However, in my APK mouse cursor doesn't go away?
Correct. I'd love to double check that, but my is an art teacher and is working from home with covid. She has monopoly of the tablet right now. But I will verify this at lunch time for you since she has the Android version installed. But from memory, that's correct. No cursor in Android version (correct) but no pressure. Your latest version has pressure but now has a cursor. Again, as soon as I can interrupt her, I'll verify this before you go on a wild goose chase. :)
I am WRONG. Please don't go looking for a solution there. I was convinced it disappeared... but no, the cursor was there and is still there in your latest build. So I guess that problem needs to be resolved. I think I'm getting confused because with the Pixelbook pen it's fine. So it's just that the Wacom tablet is interpreted as a mouse. Sorry for the confusion.
Oddly, this too is one of the problems I cannot reproduce on my Pixelbook, even with an external tablet. However, there is an API to change mouse cursor, it was added a few years back. So, maybe we'll implement it since there is a special section in chromeOS' docs for it. But I think it is unrelated to this bug. So, I'll close this as fixed :) Thanks for the input!
Sounds good and agreed. Should I open another bug for the cursor problem? To be clear, we have Pixel Slates.
(In reply to Luc from comment #21) > Sounds good and agreed. Should I open another bug for the cursor problem? > > To be clear, we have Pixel Slates. Yes, sure.
Done. https://bugs.kde.org/show_bug.cgi?id=431859 Appreciate the help on this one. Thanks!