Krita enforces pen mode for tablet on the canvas area, making the cursor jump around and using the program near impossible. If I change the tablet setting to pen mode, it works fine but is really frustrating to use as pen mode is horrible. (Yeah, it's about preference and I know that pen mode is more widely used but ugh)
Supporting mouse mode is a new feature; therefore I'm setting this to "wish". Unless someone appears who cares enough to code this, it's unlikely to be implemented, though.
Well, there is a way to implement this... but mind you, it will make use of the actual cursor coordinates which has only per-pixel precision and thus will be way less precise than using Pen mode, especially when under 100% zoom. I've checked the mouse mode support in Clip Studio Paint and I can see that it also use the cursor coordinates. I would guess every other software that support WinTab mouse mode would be doing the same.
Mouse mode isn't a new feature, though making support in Krita for it might be considered a new feature. I got my first Wacom tablet 12/31/2008 and had decided immediately that pen mode made no sense for people drawing on a non-screen surface and staring at a monitor. This is especially true for people who have multiple monitor setups (even though you can set it to one monitor for the mapping, it's still preferable for me to use mouse mode). I for one, would like to see Krita support mouse mode which as far as I understand would only work in WinTab, especially given that other programs support it. I would also like to see this as a feature since not everyone uses Pen mode for their tablet.
Yes, we consider adding things to Krita that Krita didn't do before new features, so this gets to be classified as a wish, not a bug.
Hi Wade, I hate to say this, but I spent a night reading Wacom's WinTab documentation and the demos they provide, yet I still have no idea how a program can really make use of mouse mode for real. None of the demos work properly under mouse mode and there really seems to be no way to detect whether mouse mode is enabled. May I ask you for a bit of help? Can you list some applications that you find to support mouse mode with pressure sensitivity, and write down what options you need to set in each of the application in order for it to work (if any)? I would also want you to test this in those applications: Draw a stroke with the tablet, and when you are still drawing, move your mouse and see if the stroke follows it. You don't have to test all of them, just test whichever applications you find convenient to do so.
(In reply to Alvin Wong from comment #5) > Hi Wade, > > I hate to say this, but I spent a night reading Wacom's WinTab documentation > and the demos they provide, yet I still have no idea how a program can > really make use of mouse mode for real. None of the demos work properly > under mouse mode and there really seems to be no way to detect whether mouse > mode is enabled. > > May I ask you for a bit of help? Can you list some applications that you > find to support mouse mode with pressure sensitivity, and write down what > options you need to set in each of the application in order for it to work > (if any)? > > I would also want you to test this in those applications: Draw a stroke with > the tablet, and when you are still drawing, move your mouse and see if the > stroke follows it. You don't have to test all of them, just test whichever > applications you find convenient to do so. Absolutely, it's the least I can do. --------------------------------------------------------- --------------------------------------------------------- Drawpile 2.0.8 and older use an older WinTab code from QT, but the newer version going forward (not released yet, only in testing) might actually make use of your improved code for Windows Ink users and Wintab support with a separate version for people using Mouse mode. That being said, mouse mode works just fine with no additional configuration. Same for Pen mode, only settings that need changed are within the program that controls the tablet for Wacom. Note that "Enable Bug Workarounds" is not checked under Edit, Preferences. When attempting to move the mouse while either continuously drawing with the pen or stopping the stylus pen input, the mouse causes the cursor to move as well in the designated direction. Windows, Linux, or Mac https://drawpile.net/download/#Windows --------------------------------------------------------- PaintTool Sai 1.2.5 supports Pen mode and Mouse mode, only configuration needed is under "Others (O)", "Options", "Digitizer Support" tab, and then click "Mouse". When attempting to move the mouse while either continuously drawing with the pen or stopping the stylus pen input, the cursor refuses to move with input from the actual mouse device. Windows Only https://www.systemax.jp/en/sai/ --------------------------------------------------------- Adobe Photoshop 2014 and newer support Windows Ink. The only real configuration needed is a small file to make Photoshop use Wintab to get pen pressure. Once that's done, photoshop supports Mouse Mode or Pen mode without any additional configuration within the program even when switching between modes. Currently using 2018. When attempting to move the mouse while either continuously drawing with the pen or stopping the stylus pen input, the mouse causes the cursor to move as well in the designated direction. Note: Lazy Nezumi Pro was turned off for the testing done above. Supports Windows and macOS. The filename: PSUserConfig.txt Location: [Drive]:\Users\[User Name]\AppData\Roaming\Adobe\Adobe Photoshop CC 2015\Adobe Photoshop CC 2015 Settings\ File Contents: # Use WinTab UseSystemStylus 0 --------------------------------------------------------- Lazy Nezumi Pro isn't specifically a drawing program, but a pen stabilizer. There's a feature under settings, Tablet Options, to enable "Tablet Mouse Mode". This allows it to be synced up properly in Photoshop when Lazy Nezumi Pro is on. This program can be "hooked" into other programs as desired. Windows Only https://lazynezumi.com/ When attempting to move the mouse while either continuously drawing with the pen or stopping the stylus pen input, the mouse causes the cursor to move as well in the designated direction in Photoshop. --------------------------------------------------------- SpeedyPainter works with both pen and mouse mode with no additional configuration when changing modes. When attempting to move the mouse while either continuously drawing with the pen or stopping the stylus pen input, the cursor refuses to move with input from the actual mouse device. Windows Only, available in this website or in the Windows Store. http://speedypainter.altervista.org/
I don't know if this would help, but it looks promising. I'm not sure if you saw this (section 3.7). I'm not a programmer by any means by the way, I am computer savvy though (custom build desktops and the like). http://www.wacomeng.com/windows/docs/wacomwindevfaq.html#_Toc276983627 There's a lot of other information there too that might be useful. I'm not sure what website you ended up reading. http://www.wacomeng.com/windows/docs/wintabbackground.htm http://www.wacomeng.com/windows/index.html
(In reply to Wade from comment #6) Thanks for the info. I did a bit of testing with some of them and here are my findings: Drawpile 2.0.8 uses the WinTab support from Qt, which happens to contain an ugly hack which takes the system cursor location for handling mouse mode. That code for some reason wasn't backported to the WinTab code in Krita, but it could've been intentional. SAI 1.2.5 switches WinTab to pen mode by default. The option it provides for enabling mouse mode actually causes SAI to handle the relative movement of the tablet by itself. It also moves the system cursor by its own tracking, instead of letting the Wacom driver do it. This is why moving the mouse doesn't affect the strokes made by the tablet. It also doesn't follow the mouse mode settings in the Wacom settings, but instead provide its own speed settings. This also allows making use of the full tablet resolution to get sub-pixel position for painting. SpeedyPainter doesn't work in mouse mode for me at all. Anyway, I dislike the idea of using the mouse coordinates for painting, so I did have the idea to implement relative mode in the WinTab code, just like how SAI does it. I didn't really consider it then due to how it would have to move the system cursor around, but seeing that I had to do it anyway in the Windows Ink code, I'm feeling a bit more comfortable with going this direction.
(In reply to Alvin in Comment 8 ) As long as it works well, that's really all that matters. I only have two concerns. My first concern is that since it over-rides driver controls for the tablet, I would hope that either the Mouse Acceleration is an adjustable feature or it's just turned off altogether. My second concern is that even though Sai does use the tablet in relative mode and over-ride settings, it still sometimes jumps around unexpectedly while being in mouse mode (as well as all my tablet settings), so I'm hoping that this is something that could be coded to prevent that bit from happening as well. As far as SpeedyPainter goes, I appear to have been mistaken about it working in mouse mode. I guess that's what I get for using the program on the middle of three monitors, I somehow missed that. My apologies.
Hi, the developer of Drawpile here. I'm using Krita's Wintab event handler in the latest master branch version of Drawpile. I copied the mouse mode hack from Qt source and it seems to work. Specifically, these lines: // Get Mouse Position and compare to tablet info const QPoint mouseLocation = QCursor::pos(); // Positions should be almost the same if we are in absolute // mode. If they are not, use the mouse location. if ((mouseLocation - globalPos).manhattanLength() > m_absoluteRange) { globalPos = mouseLocation; globalPosF = globalPos; } I had to replace QWindowsCursor::mousePosition() with QCursor::pos(), since QWindowsCursor is a private API. Adding these lines didn't seem to break anything on my computer and Wade also reported that it fixed mouse mode for him (and didn't break pen mode.)
One Drawpile user just reported this: https://github.com/drawpile/Drawpile/issues/568 Looks like there was a good reason the mouse mode hack was left out of Krita. If the tablet coordinates are offset from the mouse coordinates so that the offset is very close to the m_absoluteRange threshold, it will result in random jagged lines being drawn when the threshold is crossed.
(In reply to Calle Laakkonen from comment #10) > Hi, the developer of Drawpile here. > I'm using Krita's Wintab event handler in the latest master branch version > of Drawpile. I copied the mouse mode hack from Qt source and it seems to > work. [...] > > Adding these lines didn't seem to break anything on my computer and Wade > also reported that it fixed mouse mode for him (and didn't break pen mode.) (In reply to Calle Laakkonen from comment #11) > One Drawpile user just reported this: > https://github.com/drawpile/Drawpile/issues/568 > > Looks like there was a good reason the mouse mode hack was left out of > Krita. If the tablet coordinates are offset from the mouse coordinates so > that the offset is very close to the m_absoluteRange threshold, it will > result in random jagged lines being drawn when the threshold is crossed. Ah, thanks for the info! The report you linked to seem to show an offset between the cursor and the tablet though. I suspected there is an error in calculating the WinTab coordinates, which I've made a patch here [1](https://phabricator.kde.org/D10685), but I couldn't verify without affected hardware and drivers. Back to the hack from Qt: I have a problem with it, which is that it can go wrong in a few ways: - The tablet event may snap to the system cursor if it lags behind the WinTab position. - It could cause the jumps when there is just a slight offset in the WinTab coordinates calculation, just enough to cause it to jump at the middle of the screen. - When in mouse mode, if the absolute WinTab position happens to be close enough to the screen position of the system cursor, it may cause a hiccup in the line when it decides not to snap to the system cursor for a moment. The worst thing is that it decides on its own. In Qt it is possible to configure the threshold via a command line option, but still... I would prefer an explicit option to either use the system cursor position or not. Using the system cursor position for drawing is also just awful; the tablets have a higher-than-mouse precision for a reason! Anyway, I plan to start working on this along with a bunch of other WinTab-related stuff after Krita 4.0 is released.
*** Bug 391265 has been marked as a duplicate of this bug. ***
Just wondering if there's any update on this since 4.0 & 4.0.1 has been released.
Not really, since I haven't have much free time to code for Krita lately.
Just wondering if we have any updates on this since it's been a year since this thread was originally started. I'd help out if I could, but I lack programming experience. That being said, I can always donate or do a subscription. I'm just particularly anxious about this feature since I do use Krita for certain tasks that it does better than some other programs I use, but I'm hard pressed to switch to it as it is now since I hate using pen mode. Cheers though on all the hard work you guys do, I realize you have a MOUNTAIN of code, thousands of line to deal with, multiple systems to support, etc etc. I just was hoping for a tiny update on this was all.
*** Bug 409031 has been marked as a duplicate of this bug. ***