Hi! I'm using Ugee 2150 (yeah i know it's not wacom, but i don't have 2000$ for a cintiq and still wanna use krita's awesomeness :) ) on krita 3.0 rc1 and it connects all strokes with previous ones (it doesn't do this with mouse). You can see the result in the screenshot. Reproducible: Always Steps to Reproduce: 1.Get Ugee 2150 :) (maybe other Ugee tablets as well?) 2.Draw something in Krita 3.Voila! Actual Results: Krita connected my strokes! Expected Results: Well, krita shouldn't have connected my strokes.
Created attachment 99075 [details] Screenshot showing the bug
Hi there, Can I tempt you to make us a tablet log? It'd be really useful to learn what Krita thinks is happening. Instructions here: https://docs.krita.org/KritaFAQ#What_if_your_tablet_is_not_recognized_by_Krita.3F
Created attachment 99082 [details] Tablet log Interestingly in this log first 2 strokes aren't connected (at least on my screen), but all the next strokes are connected
Btw, I know it's a different bug, but my cursor doesn't update while i move my pen over the screen.
Judging from the log, the tablet's driver is really confused about when the pen is near the tablet or not.
It works fine with krita 2.9 though...
It works perfectly fine in Krita 2.9. It’s a 3.0 regression. Please help me!
Calm down, we rewrote tablet support in 3.0 due to the qt5 port. We are not magical, so we can't wave a wand to fix this bug. It needs either another ugee user to confirm it, or us making an educated guess about what might be wrong in the code. This takes time.
I'm sorry if i sounded rude. I'm not rushing you, i just hope you won't put this bug on the shelf. I can use 2.9 for now - it's not big deal.
It also needs to an actual Ugee tablet -- the log doesn't really tell me what's wrong in this case. It looks okay to me. And if we change the code, we need to test the result with actual hardware (and then we need to test with the brands we do support: Wacom, Huion and Yiynova).
Hello to all, I'm in the process of buying the same tablet, and having it to work well in krita will be important, so I was wondering if it would help if I ship it to one of you to help debug and get it back?
It might help initially, but we really need to be able test every release with it, otherwise there are sure to be regressions.
Maybe we should find someone with ugee tablet (not monitor) and ask him if he/she is having problems? That way you guys could afford a way cheaper ugee device.
Most of them share one driver anyway
Or you need me to donate you a ugee device? I'm afraid i can't do this as i don't have (after buying 2150) money myself :(
Not you personally, but you could club together with the other ownners of Ugee, Peritab, Genius and Trust tablets and together get the project a test tablet. That is something you could initiate, for instance.
Ok. I'll try to do sth about it.
I seem to be experiencing this as well I use a Yiynova 22 inch ,and it happens on Windows 8 on a laptop,with every 3.0 version I tried. 2.9 doesn't have this issue. My Yiynova works perfectly on windows 7,with stable AND 3.0 variants.
Hmm. Interesting. If you keep drawing in krita 3.0 after the bug, cursor will start following the pen with a huge lag, then it will follow it more and more smoothly and finally krita will stop connecting strokes. The only problem with that (besides it being super weird :)) is that the bug will be reset after relaunch (works with all documents in one session though).
I've read this https://krita.org/item/anatomy-of-a-bug-fix/. Does it means that this bug got fixed too? Also I thought Yiynova and Huion have same issues since they are sharing the same UC-logic digitizer isn't it?
I'm using a yiynova mvp22 v3 and I'm affected by this same bug as well. On an interesting side note, I noticed that if I start krita as admin, the end and start points of my lines are no longer being connected as in this bug, however then I have no pressure sensitivity... As the original poster, everything works fine in 2.9. Also, using windows 10, so it isn't just windows 8 that is being affected with this. And while searching in the bug tracker I found: https://bugs.kde.org/show_bug.cgi?id=363808 Sounds like the same bug.
I'm experiencing this as well on my XP-Pen Artist Display 22HD, on Win7 x64. I'm attaching a tablet log. Shown in the log is this, which is odd, but probably a different issue: qtDesktopRect = QRect(0,-1080 1920x2160) wintabDesktopRect = QRect(0,0 1920x1080) (It is a 1920x1080 display)
Created attachment 99377 [details] Tablet Log - XP-Pen Artist Display 22HD
So I managed to get my yiynova to stop doing this! I think the problem was with the latest driver for the tablet. When I was using driver v8.03 (released 4/20/16) from yiynova.com I always got this problem. Last night I thought that since the krita is supposed to support yiynova maybe they had it working with an older driver instead of the newest one. After removing the drivers and then reinstalling v8.01 (released 6/11/15), which was the oldest that supported windows 10, everything worked perfectly. Hopefully this helps narrow down this problem.
*** Bug 363808 has been marked as a duplicate of this bug. ***
Just got my tablet and I don't see this bug in linux
is there a fix in the works for the XP-Pen products, like the XP-Pen Artist Display 22HD? It works in krita 2.9, but not 3.
No, there is no fix in the works. As shown in comment 24, this is a driver issue. Until we get hardware with which we can reproduce the issue, we cannot create a work-around for the broken drivers.
Not sure if this helps, but I'm on a Turcom TS-6580 and having this issue as well, so if anybody has one of those it can likely be replicated.
It happens with my Yiynova22 (v3) too. on both 3 the latest test drivers for 3.01
hi, i am having same issue with ugee M708 on win10, and can confirm the same behaviour as described in (In reply to Thighum from comment #21) > I'm using a yiynova mvp22 v3 and I'm affected by this same bug as well. > On an interesting side note, I noticed that if I start krita as admin, the > end and start points of my lines are no longer being connected as in this > bug, however then I have no pressure sensitivity... As the original poster, > everything works fine in 2.9. Also, using windows 10, so it isn't just > windows 8 that is being affected with this. > > And while searching in the bug tracker I found: > https://bugs.kde.org/show_bug.cgi?id=363808 > > Sounds like the same bug.
I was experiencing this problem out of the box with the Ugee UG-2150 Krita 3.0.1.1 has the same bug for me, reproducible with both drivers from Ugee.cn and ugee.eu websites. Krita 2.9.0 and 2.9.11 both work flawlessly with the following drivers and Windows 10 http://i.imgur.com/Fk72wfZ.png Driver V8.1.2016.329 CP V8.0.2015.129 Wintab32 V8.0.2016.329 For owners like myself who are having more general problems with Ugee drivers, this article was a great help to me with a lot of the wacom issues with WIn10 also being issues here https://artfixed.com/how-to-fix-your-graphic-tablet-and-pen/ The takeway, after lots of trial and error with every permutation possible --- DO NOT HAVE MULTIPLE TABLET DRIVERS INSTALLED! Uninstall all of them, from device manger if needed, and unplug your tablet then restart. Before plugging in the tablet, follow the Ugee instructions to install your driver. After the tablet is setup with the drivers you want to use, check the pen settings inside the driver control panel and BOTH the Windows 10 Control Panels (so holding the pen isn't triggering double clicks or right clicks from the Windows Ink drivers. WIth this done, I haven't had a problem with any of the Windows Ink programs or Gimp. I'm using Krita 2.9 and it fucking rocks with this tablet. Great work by the Krita dev community. Hopefully my lucky stars align and I'll get to use Krita 3.0+ soonish. In the meantime, it would be cool to have a previous versions link on the main download page for more poverty stricken artists among us. I knew where to find the older versions by some of the less technical might not.
*** Bug 372566 has been marked as a duplicate of this bug. ***
I've got a ugee M708 and I can confirm this issue. As reported in bug 366814 the outline doesn't follow the cursor but stays in the place where the stylus was lifted. Then when the stylus gets back to the tablet surface a line connets those two points. I've also tested the tablet with Medibang and there it works fine. If there's anything I can do to help, please let me know.
Wanted to update that I'm no longer having this issue on my Turcom TS-6580 since updating to Krita 3.0.91.
Just tested krita_2.9.9.2ae_beta_x64 This does a lot better job. No jumping connection lines between two strokes. Less lagg. Only thing that's not correct is the outline. It doesn't follow the cursor.
*** Bug 373125 has been marked as a duplicate of this bug. ***
Purchased a Ugee 19" art tablet. My daughter loves your program, and previously used it successfully on her old Wacom, but it is connecting strokes together on the Ugee. When lifting the pen, it ignores and connects to the next brush stroke. Please advise. I've read that there are other people having this same issue. Thank you, Kim
*** Bug 373532 has been marked as a duplicate of this bug. ***
They say it'll help if I install an older version of my Ugee 1910b driver, but... Does anyone know where I can download an older driver? Or maybe one of you have one that you can send me through Gmail?
*** Bug 374213 has been marked as a duplicate of this bug. ***
It seems like this issue is being mentioned in this Qt C++ tutorial. I'm not confident enough in this to do the bug fixing here. Maybe it helps you out on this one. https://youtu.be/CR2qQebqv6I
Created attachment 103078 [details] Tablet Log I was having a problem with my pressure sensitivity stopping after a time until I updated my tablet drivers to the most recent version. Now I'm having this problem too. I'm on a Ugee 1910B, using 3.1.1 I had to cheat a bit (by moving my pen away from my tablet quickly) to reproduce the stroke jumping because Krita gets better about knowing where my stylus is when the Tablet Logging is on. With Tablet logging on it basically works like it should, just a bit laggy. Let me know if you need any more info.
If it makes any difference, I tried my tablet (Ugee 1910B) on my old desktop and it worked fine with the same driver. The computer I'm having a problem on has a AMD FX-8350 CPU The computer that works fine has an Intel(R) Core(TM) i5-3570k CPU Let me know if there is any other information I can provide that could be helpful.
(In reply to Charles from comment #44) > If it makes any difference, I tried my tablet (Ugee 1910B) on my old desktop > and it worked fine with the same driver. > The computer I'm having a problem on has a AMD FX-8350 CPU > The computer that works fine has an Intel(R) Core(TM) i5-3570k CPU Issue shows up on my i5-4670k
(In reply to Charles from comment #44) > If it makes any difference, I tried my tablet (Ugee 1910B) on my old desktop > and it worked fine with the same driver. > The computer I'm having a problem on has a AMD FX-8350 CPU > The computer that works fine has an Intel(R) Core(TM) i5-3570k CPU > Let me know if there is any other information I can provide that could be > helpful. Hi Charles, I'm not a dev, just a fellow user with the same problem, also running an AMD CPU looking to compare notes. I really need to find a C++ and QT for dummies guide but I got the tablet to learn how to draw, not how to code :P What OS build did you have? Run->DxDiag might be the easiest route. What Ugee driver is running? Hovering your mouse over the driver should show this: http://i.imgur.com/Fk72wfZ.png When I get home tonight and try my laptop, my i3 media PC and i5 and we'll compare notes. I don't have a Windows 7 computer to test on.
> Hi Charles, I'm not a dev, just a fellow user with the same problem, also > running an AMD CPU looking to compare notes. I really need to find a C++ and > QT for dummies guide but I got the tablet to learn how to draw, not how to > code :P That's how I got started working on Krita... In 2003, with a little wacom Graphire tablet.
*** Bug 375454 has been marked as a duplicate of this bug. ***
SOLVED!!! (For me) It is really weird why it is now perfect, but now Krita does everything perfectly! I had some pressure issues with Photoshop, so I tried reinstall driver, because I thought what if problem is I installed driver first, then all of other software. And it worked! Photoshop is now pressure sensitive and Krita doesn't connect strokes. I am really happy now. I hope this solution will help you as well!
I'm pretty sure that since all these tablets have the same chip and share the same driver, that this is a problem with some driver versions... In other words, not something that we as developers can do something about.
Note: latest drivers are here https://www.dropbox.com/sh/h0y7c31yh9tvo8z/AADlq33nOBGUltpA2_I2ODnEa?dl=0
Thank you for the update. I can confirm that it also works for the Ugee 2150. I didn't see your dropbox link until later and installed "PEN DISPLAY DRIVER 2017" from http://ugee.net/download/index.html For those with the UG-2150, as of writing they haven't updated their website listing for this model, but have for the UG-1910B. The all caps "PEN DISPLAY DRIVER 2017" works fine thou. Thanks all for the assistance and persistence.
Does anyone know if there's been any breakthroughs with this bug? I mean, Krita is such an amazing product, but I can't use it thanks to this fucking problem. Anything?
As you can see in the last comments, it's a driver problem, and if you install a new driver, the problem should go away. Since we, as developers, don't have access to this hardware, and since it turned out to be a driver problem, not a bug in krita, it makes no sense to ask us for "breakthroughs with this bug".
*** Bug 383626 has been marked as a duplicate of this bug. ***
I had the same problem. My pen seemed to "remember" its last position, resulting in unexpected lines being drawn when I put it down from (more or less) its last position. I solved it be installing an older Yiynova driver. Windows 10 Krita 3.3.0 Yiynova Driver 8.05 -> problem Yiynova Driver 8.04 -> problem Yiynova Driver 8.02 -> no problem I found the driver here: http://www.yiynova.com/En/qudong.php Hope it helps.
Git commit 94151b759b0cd8f7b33fdf857294d2cfe7fac86d by Dmitry Kazakov. Committed on 14/09/2018 at 10:51. Pushed by dkazakov into branch 'master'. Add a workaround for tablets not reporting tablet events in hover mode The bug is caused by the fact that we postpone tablet events by one event (presumably to make it sync with mouse events stream). But some non-wacom tablets do not report tablet move events when the stylus is hovering. It means that the following tablet press event will be positioned incorrectly. This event postponing has come from Qt, and the commit message says it was needed for "relative" mode, which we don't support. I just disabled this postponing, let's check whether it helps people. M +7 -4 libs/ui/input/wintab/kis_tablet_support_win.cpp M +0 -1 libs/ui/input/wintab/kis_tablet_support_win_p.h https://commits.kde.org/krita/94151b759b0cd8f7b33fdf857294d2cfe7fac86d
Git commit ea7a7367a7b65c9134781d6a98260bdfc53c73d1 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 15/09/2018 at 09:08. Pushed by rempt into branch 'krita/4.1'. Add a workaround for tablets not reporting tablet events in hover mode The bug is caused by the fact that we postpone tablet events by one event (presumably to make it sync with mouse events stream). But some non-wacom tablets do not report tablet move events when the stylus is hovering. It means that the following tablet press event will be positioned incorrectly. This event postponing has come from Qt, and the commit message says it was needed for "relative" mode, which we don't support. I just disabled this postponing, let's check whether it helps people. M +7 -4 libs/ui/input/wintab/kis_tablet_support_win.cpp M +0 -1 libs/ui/input/wintab/kis_tablet_support_win_p.h https://commits.kde.org/krita/ea7a7367a7b65c9134781d6a98260bdfc53c73d1