Registered Member
|
Hi, I have applied the patch. Here are the errors: 1. Ghost lines around the top hal of the image. http://en.zimagez.com/zimage/test4111.php + log: http://pastebin.com/Kn1Mprke (This is new came with the patch.) 2. Maximum pressure error. The maximum pressure seems to become 0 pressure the brush indicator circle seems to indicate low pressure and there is no drawing on the canvas. http://en.zimagez.com/zimage/test5101.php + log: http://pastebin.com/PjdHTGyG 3. Cursor movement and the stroke display is out of sync. Actually it occurs with vertical lines (I could reproduce it in the middle of the canvas too.). I draw a vertical line beside a ruler. I cnnot really create a screenshot for this. The stokes appear on the canvas in larges chunks and the brush indicator does not follow the pen movement in real time neither. Here is the log: http://pastebin.com/VdqDxf5A I hope I could help a little. |
Registered Member
|
Oh.. I'm starting to get a feeling that it would be easier for me to fix the driver itself instead of trying to do all these workarounds... But it would sure demand at least this weird hardware
Ok, I'll try to look at the logs more tomorrow. Probably I'll find some way out. The problem is that I cannot directly apply the patch I was sending you before, because in that case you will not be able to finish any line with zero pressure, that is all the lines will end with non-zero pressure and will not have narrow ending. That makes the things a bit complicated |
Registered Member
|
Well, for me the strangest thing is: when I have patched Qt to recognise the tablet with the evdev driver none of these strange things happenned. At least if I remember it well. So maybe somehow patching Qt 4.8 would be a better approach? (If I know well ubuntu definatelly applys some of their patches to their packages..... ) (If you can make sense of this pproach then me I can think about creating a test environment with running krita from a speccially compiled Qt somehow) Or just making krita compatible with QT5 because there are rumours that Qt5 will be compatible with the evdev driver.
|
Registered Member
|
Hm, could you tell which patch exactly you did apply to Qt? Probably, that would help quite us quite much
|
Registered Member
|
Hi, it was the path here: https://bugreports.qt-project.org/brows ... ent-178238 and it was mentioned in this forum here: viewtopic.php?f=139&t=98347&start=15#p244965 and here: viewtopic.php?f=139&t=98347&start=90#p297979 and as it turned out it didn't helped much because even though you have made changes and krita recognised the my tablet as tablet, further workaround was needed. It seems there is still a difference if you modify qt and the workaround . I do not know why because I didn't got into deep in Qt or Krita. |
Registered Member
|
In relation to my own experience of this problem,
I should also mention a few things, sorry if they have already been mentioned: * xinput test <deviceid> reports normal pressure values all the way up to 1023 no matter what I do. That is, there is no 'sudden fall to 0' experience' as I press harder. This to me suggests that the events that Krita is receiving and interpreting are different from the ones that the evdev driver is actually producing. * GTK2 apps (MyPaint, GIMP) respond perfectly to pressure, clicks, and have no line breakages. To me this indicates either a very sophisticated filtering, or that they just get better quality events / interpret those events better. * GTK3 apps (MyPaint git master) experience this type of breakage, and also QT5 apps (DrawPile). This also points at a basic difference in how events are being queued and handled -- that along with this progression to a better overall input-handling model there have been notable regressions too. EDIT: In regards to your most recent workaround, this unsticks buttons most of the time, with the side effect of making spinners very 'stiff' (pressing on them does not make the value change, except for one initial step. Later when releasing pressure, it seems that the tens of changes that I was expected are applied all in the space of half a second (so it goes from 0.5 to maximum, 1.0, in no time at all. This has also made the crop tool and perspective-grid tool responsive. The perspective/distort tool is still unresponsive |
Registered Member
|
Hi!
I just built it from mater, without any patch. The breaks and jumps are gone, and most of the time it works as it should, except two issues at teh two ends of the pressure range: 1; Very low pressure: If I draw slowly, the cursor is extremely lagging. It doesn't seem tho as it would draw incorrectly, but I cannot tell for sure, only that I see it like a very love frame per sec animation. Log: http://pastebin.com/NXqbXRUp 2; Maximum pressure: Similarly as Victoria described, when pressure reaches max, the cursor and canvas stops updating as long as I keep it pressed. I can wait as much as I want in this state. Upon lowering pressure, it suddenly catches up. This catchup sometimes works, giving me the line I think I drew while it didn't update the canvas, sometimes it disappears, and sometimes it draws a lower pressure and incorrectly tracked line instead. I tested several times to get logs of the different behaviors: - Drawing the correct (I assume) line upon catching up: http://pastebin.com/bLvdHDGJ - Breaking and missing a part of the line (cursor jumps then stays there until release) and drawing correctly afterwards (happens only if I draw fast, but still randomly: http://pastebin.com/Y8VQ6fEw I couldn't replicate the incorrect line drawn case, and gave up after a while. Next I assume I should try the patch you just linked.
"Sic itur ad astra per aspera."
|
Registered Member
|
Hi,
I have built a custom Qt* on a separate VM (xubuntu 13.10 32 bit ) and installed Krita from the repository and there are pressure with the pen without any problems No issues with the strokes and no issues with the toolbox and menuitem selection. *More preciselly I installed Qt from the repository and replaced the qtcore and qtgui libraries with the newly compiled ones. i could not build proper packages because the VM has run out of disk space |
Registered Member
|
Viktoria: You seem to have had some success, that's great.
Could you clarify which patch you used / changes you made? |
Registered Member
|
Hi, I just applied the simpler version of this patch: https://codereview.qt-project.org/#change,61006 i have changed qt4-x11-4.8.4+dfsg/src/gui/kernel/qapplication_x11.cpp file on line 2512 to this: if (devs->type == ATOM(XWacomStylus) || devs->type == ATOM(XTabletStylus) || devs->type == XInternAtom(X11->display, XI_TABLET, False) ) that's all in this way my tablet was handled as tablet in Qt applications That's all. |
Registered Member
|
Thanks viktoria, I have finally found time to try this out. Unfortunately, in krita, it does not help : krita ignores attempts to draw with the tablet, and clicking with the ellipse tool causes krita to crash.
|
Registered Member
|
I wonder if it's okay to bump this topic again.
So, I've updated to the latest Krita ( 2.8 ) only then all of my non-wacom tablets no longer work (even my oldest tablet too). At least I have my cheapy Wacom Bamboo here, that works fine. I guess the first thing to ask is the release notes. I don't really really understand some of the terminologies but what was the aim/goal? Here are the non-wacom tablets: ID 0460:0004 Ace Cad Enterprise Co., Ltd Tablet (5x3.75) ID 5543:0042 UC-Logic Technology Corp. Tablet PF1209 (AKA Monoprice Tablet 12x9) ID 256c:006e (HUION H610PRO) <---[It worked on Krita 2.7!] Also, I'm glad to finally post here. I think it was about time that I finally join here. |
Registered Member
|
@Yalyn
Did your monoprice work with the previous version? I have one too and it worked with 2.7 but not 2.8 for some reason. Is it pressure sensitive elsewhere [as in other programs/operating systems]? Did you install any drivers to get it to work or it just worked out of box? I know that's a lot of questions but everyone else I know with a tablet uses wacom and it's frustrating that wacom is the only one that gets out of the box support. Also, one of the devs was shocked when I said that my tablet [a monoprice 4x3] worked with 2.7 when everyone else with a monoprice said it didn't work with theirs. |
Registered Member
|
Yes and no. I was able to draw on it but no pressure sensitivity. But for the newer verison it just won't work flat out.
The big Monoprice tablet always work on MyPaint. I used to get it to work in Gimp but not anymore because I switched to a different distro.
I think I messed with the WizardPen back then because I was completely clueless but I no longer mess with it anymore. (It happened when I got into Linux for the first time.)
Well we are using diff. tablets. You are using UC-Logic Tablet WP4030U. Mine is UC-Logic Tablet PF1209. http://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_support_status |
Registered Member
|
I didn't even bother with WizardPen and the like because it was just way beyond my understanding [kernal? Patches? augh!] but I just figured I would have to do most if not all of my art on my main laptop which runs windows 7. I thought I was tech savvy but apparently I am not...
I've tried myPaint on both Linux and Win 7 but got pressure sensitivity on neither. >_> The only programs that work my tablet are SAI, FireAlpaca, SmoothDraw and krita [again, before the update] which isn't bad since they are really great programs but I would like pressure sensitivity on photoshop/GIMP too... This is what I get for wanting a cheap tablet I guess. Thanks for answering my questions. |
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan, sandyvee, Sogou [Bot]