And I so hoped that having one uc-logic based tablet work would mean the rest would work, too!

Hi, Viktoria, Storm and others!

Since yesterday Krita has a new nice support for evdev tablets (also in Krita Lime)!

Please test it and report if it works with your device or not Even if it works fine, it would be really interesting for us to know that this device is supported, so tell us!

Hey, I'm using Krita 2.9 Pre-Alpha on Kubuntu 12.04 and my generic tablet Genius EasyPen i405 seems to be working with evdev. Thank you very much Krita developers!

You note that my tablet is the i405 "UC-Logic Tablet WP5540U" model using evdev driver. it is not the "KYE EasyPen i405X" that I have understood that it can use Wacom drivers.

Okay by reading the front page and the blog you guys said to test the non-wacom tablets under 2.8, correct? Well the thing is, what do I need to do other than update? Because I am still getting the same problem. (It won't work.)

However by installing with the unstable 2.9, they all work. Like no problem what-so-ever. While I am happy, I am not really a fan of messing with unstable programs cause it takes huge amount of resources from the last time I used it.

Here are the tablets that worked if you wanna check again:
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)

The new tablet support code will be in 2.8.1 (windows -- supports surface pro) and 2.8.2 (linux, supports uc-logic tablets). We still have trouble on linux with the huion tablet, which does very weird things, like sending stylus down and up events around every single move event, and huion mailed me yesterday that they have trouble with their latest beta drivers and krita on windows.

Hi,
first of all thank you guys for your hard work . I just built Krita from git. (I've got Genius Mousepen i608X) I still got the toolbox issue (I able to select more then one tool from the toolbox). And ocassionally I've got ghost lines on the top left corner of the canvas, but this bug is only appeared twice and I could not reproduce it consistently. (I heven't got a clue what condition makes this happen.)

Hey! my tablet work now on version testing of krita.

I hope that it function in next stable version.

http://sourceforge.net/apps/mediawiki/d ... et_WP8060U

thanks for good work

I just got a UC-logic based pen display and so far it's working great, except in Krita. It mostly works in Debian (my primary OS), and sort-of works in Windows 7 (mostly done for testing). Krita's my preferred graphics program (you guys have been doing an awesome job with it), so I look forward to being able to use it again with this new hardware.

In Linux, the only problem is that input is extremely slow in Krita. Short brush strokes appear quickly, but large, fast strokes have a delay up to 2+ seconds before they appear. More specifically, a slow stroke appears while the pen is down, just like in other programs, but a fast stroke won't appear at all while the pen is on the canvas, and takes multiple seconds after release to display.

This doesn't occur in GIMP or MyPaint (the gtk2 version. gtk3 one has other problems that make it unusable for testing)

In Windows, input is quick and the program is very responsive. (A great improvement over previous releases I've tested. Great job there.) However, there's a massive cursor offset that's caused by my extra displays. Does not happen in Gimp or Manga Studio 4, nor does it occur in Krita on Linux. Seems to be treating pen movement as relative to all 3 displays instead of the single display like other programs.

I'm primarily concerned with getting the Linux performance to improve. I rarely use Windows and only mention it for comparison and problem reporting. I'm providing various system information that may be relevant and will supply more if needed.

System details:
Hardware
1x Monoprice 19" interactive pen display. 1440x900, Huion-based digitiser (http://www.monoprice.com/Product/?c_id=113&cp_id=11314&cs_id=1131401&p_id=10707&seq=1&format=3)
1x 23" display (1920x1080)
1x 21.5" display (1680x1050)
Nvidia GTX 660 gpu

Linux
Distro: Debian testing
kernel: 3.14-rc7 (32bit w/PAE)
Driver: hid-huion.ko from https://github.com/DIGImend/huion-driver. The mainline kernel driver didn't work properly with this hardware. (May be the same hardware as the Huion H420. Has similar problems with the mainline driver)
Krita: krita-testing package from the Krita Lime repository (https://launchpad.net/~dimula73/+archive/krita)
Misc.: Multiple displays set using nvidia's binary driver. Pen is mapped to the correct display via xinput's coordinate transformation matrix.

Windows
Version: Windows 7, 64bit
Driver: the monoprice tablet driver from their site.
Krita: Krita 2.8.1 (64bit) from kritastudio.com
Misc.: Pen display is set as the primary display in Windows, which makes pen input lock to that display.

Hi, Marand!

We would be glad to make your tablet device work! Could you generate some logs for us?

On Linux:
https://answers.launchpad.net/krita-ru/+faq/2495

On Windows:
https://answers.launchpad.net/krita-ru/+faq/2494

Make sure that on Windows you are using the most recent driver. Huion seems to be rewriting the drivers right now so some versions might be faulty.
http://blog.huiontablet.com/forums/topi ... n#post-701

I'm providing the log for Linux here. I'll try to get what you need for Windows when I get a chance, probably before I go to sleep; I don't use it often because it's dual-boot and I use Debian for nearly everything.

Unfortunately, the log is very large (3MB) and neither pastebin nor paste.kde.org would allow me to upload it, so hopefully this link works (dropbox public file): https://db.tt/5BtgWIk2

I made a couple slow strokes at the start, then I made five quick strokes from the top of the canvas to the bottom, then finally, one extremely long stroke where I scribbled around the canvas. The five strokes had a ~1s delay each, and the last one took 9 seconds to appear after pen was released, during which tablet input was still appearing in the log.

And here's the Windows log: http://paste.kde.org/pho2hrhoj
This one was short enough that it uploaded fine

To test, I went into canvas-only mode and attempted to make six marks, in order: top left, bottom left, top right, bottom right, middle, left middle. The only strokes that appeared were top-left and left-middle, and both were slightly offset but still on canvas.

Some additional explanation about the Windows behaviour, since I had more time to test:
The cursor appears where it should relative to the 1440x900 pen display, but the strokes appear as if the input is across the entire 3-monitor spread (5040px width), resulting in most of the display's input area being unusable (since Krita acts as if most of it is mapped to the second and third display), and the limited usable area creating extremely skewed input -- circles become extremely exaggerated ovals.

I hope these both help you.

I should have thought of this before now, but I remembered I have a rubbish USB webcam, so I hooked it up and made a short video of the stroke delay problem I'm having in Linux to accompany the log file I was asked to provide. Should do a better job of illustrating the problem I was explaining.

Video link here here: https://db.tt/x0Lca5te (~7mb, dropbox again)

Interesting... This looks more like a screen update problem than an actual problem with the tablet. The strokes follow the tablet nicely, the screen just isn't refreshed until the stroke is done.

boudewijn wrote:Interesting... This looks more like a screen update problem than an actual problem with the tablet. The strokes follow the tablet nicely, the screen just isn't refreshed until the stroke is done.

Sort of. The screen is updating properly, and I can interact normally with other programs during the wait-time between the end of my brushstroke and the stroke appearing in Krita. During the wait, Krita's cpu use is identical to during the brush stroke itself, so it's like the brush stroke is still happening, just more slowly than my input. Attempting to interact with other parts of Krita's UI (such as clicking tabs, layers, etc.) also gets buffered and, after the stroke appears, all the interactions occur and animate in order as it catches up.

So, it seems I've found the cause of the input delays (and a workaround). The delay is caused by enabling "View > Show Rulers"; if I disable this setting, canvas updates during input are quick and responsive again. I can accept not having the ruler if it lets me use Krita again, so I'm happy. :)

I found this by noticing that the input delay doesn't occur with a fresh kritarc, so I started comparing the default settings against the ones I use, one by one, until I finally found the culprit. Definitely not what I expected to be the source of the problem, I have to say. No idea why this is the cause, but it still seems to be a problem specific to (some?) non-wacom hardware, since it doesn't happen when I test with an Intuos4.

Just wanted to inform you guys so that you have a better idea of where to look for the problem.