Krita + non-wacom tablets
Tags:
None
Registered Member 
|
The monoprice pen display does something similar with xinput. In my experience, the first one listed (lowest id) is the one that matters. The other one may be intended for an eraser that doesn't exist, but that's just speculation on my part. When using the xorg wacom driver instead of evdev, the device reports two extra devices instead of just one and claims they're pad/eraser, but they still do nothing, just like with evdev. As for xinput getting events but the pointer not being affected...never ran into that. Could try checking if the digimend project has a better driver than whatever the linux kernel provides (this is the case with the huion driver, which has more models supported), or see if it behaves better by using xorg's wacom driver, which actually works for some uc-logic type devices and was mentioned in this thread before, I believe. |
KDE Developer
|
Right, it might be worth trying the digimend driver then.
|
|
Registered Member
|
Hello, I've been using Krita for a few weeks now, and I've been extremely happy with it. I have encountered one small issue regarding the use of my Huion H58L tablet about which I would like to ask for some advice. Perhaps someone else who has encountered the same issue might shed some light.
I'm using: Windows 8.1 Pro 64-bit Krita 2.8.3 x64 Huion H58L tablet Logitech MX518 mouse Pressure sensitivity within Krita is excellent. But, I'm having difficulty getting Krita to respond to the stylus rocker buttons when they are mapped to mouse buttons (they do seem to work fine as long as they are mapped to keyboard strokes). For example I would like to use the rocker as both middle click as well as right click (to bring up the quick palette). But when the cursor is over the canvas, these button presses are simply not registered. However, they work fine if I move the cursor over any of the dockers such as the layers, where I am able to issue right clicks from the stylus. Outside of Krita, the tablet and its stylus buttons behave as expected in most applications (like Firefox) or the Desktop. At first I thought it was just Krita which had this issue, but it seems like it may be a driver problem or perhaps something within Windows itself, because the same issue also occurs for other applications which depends on tablet sensitivity (GIMP, and FireAlpaca). One exception is ArtRage which works as expected (it is both responsive to pressure as well as the stylus buttons). Furthermore I have noticed an interesting phenomenon where if I open Krita by clicking its shortcut with my stylus (and avoid touching my mouse), the stylus buttons actually do work, but I lose the pressure sensitivity. I have captured some debug information (per the instructions earlier in this thread) for three different situations.
2. Krita is opened by tapping the shortcut with the stylus. In this case, it responds to the stylus rocker buttons but there is no pressure sensitivity until I move the mouse. Then the tablet behaves as previously explained with full pressure sensitivity but no stylus buttons presses are registered. 3. Krita is minimized and then I use my stylus to tap back into it, the stylus rocker buttons work fine, but once I tap my stylus on the canvas, they no longer work. I regret that I don't know more about the inner workings of software and development, but I did notice two interesting things within the debug logs generated: that Krita is logging both mouse and tablet QEvents (whatever that is) when I'm simply using my tablet stylus, as well as the fact that [BLOCKED] appears on many QEvents, including the stylus button presses which Krita doesn't respond to. I've tried an earlier version of drivers for my tablet which didn't produce any different results. As I said, I'm happy using Krita, even without the full use of the stylus buttons. If that issue can't be helped then I do wonder whether it might be possible to assign the quick palette function to a keyboard shortcut rather than the right mouse click so then I could assign that keystroke to my stylus button? From what I can tell it does not appear in the shortcuts configuration. Also I sincerely apologize if this was not an appropriate place to raise this issue. I have nothing but respect and gratitude for the developers and their hard work on this software. Thank you. |
|
KDE Developer
|
Hi,
It's perfectly fine to post a question like this here  . Especially if you've made such an effort to pin down the issue! As for the tablet logs, it certainly looks like the Huion driver is doing some weird stuff! I'm not sure we can work around the issue, but it would be good if you could report the bug at bugs.kde.org and attach the logs. You can configure the settings for the popup palette in Settings/Configure Krita/Canvas input settings. We want to unify the two dialogs -- shortcts and input settings -- for 2.9, but whether we'll manage to achieve that isn't certain yet. |
|
Registered Member
|
Thank you so much. I'm quite embarrassed to have missed the significance of this Canvas Input Settings before you were kind enough to point it out to me. I have posted this issue to bugs.kde.org as you have suggested. And I'm also happy to report that using a separate keystroke ("y") I am able to use my stylus to bring up the popup palette.
|
|
Registered Member
|
I have found that there are drivers recently developed for Yiynova tablets. I thought I should spread the news. I hope that it would be beneficial to the Krita developers or anybody else with a Yiynova tablet.
http://libregraphicsworld.org/blog/entr ... digitizers |
|
Registered Member
|
would it be feasible to make the new tablet system in Krita to work with tablets supported by Aiptek driver?
I have an Aiptek HyperPen 12000U using Aiptek kernel driver, and my input devices are recognized as this in Ubuntu 14.04: found input device Virtual core XTEST keyboard type 0 found input device Power Button type 98 KEYBOARD found input device Aiptek type 263 Stylus found input device Eee PC WMI hotkeys type 98 KEYBOARD found input device AT Translated Set 2 keyboard type 98 KEYBOARD found input device ImExPS/2 Logitech Explorer Mouse type 99 MOUSE Tablet seems to be listed as 263 type, and at time being it has no pressure recognized in Krita, I tried both backport 2.8 and 2.9dev from Dmitry ppa. It works perfectly with pressure in Gimp and Mypaint (in Inkscape it has an offset issue with gtk2 and works well on a gtk3 experimental build) best to all, francesco |
|
KDE Developer
|
It would be easier with some hardware, but with enough information it should be possible. Please add a bug to bugs.kde.org about it.
|
|
Registered Member
|
I've just built a customized version of Qt4 libraries on Ubuntu Trusty, "hardcoding" my tablet type in tablet recognition routine, something like:
if (devs->type == 263 || .....) and now I have perfect tablet behavior in Krita 2.9pre-alpha, with pressure and a good, smooth response. That solves my particular problem I guess, but I must say I'm very disappointed about non-wacom poor tablet support in Qt4. I hope things would be better in Qt5, but I suspect it doesn't sound too good for what I've read about this topic. |
|
KDE Developer
|
That's a bit weird though, since as far as I know, we don't use Qt's tablet support in Krita, so you'd need to change that in Krita's code as well...
|
|
Registered Member
|
I will look a bit in krita code too, can you point me to the name of the files where the relevant part of code is supposed to be?
|
|
Registered Member
|
Hi, hvfrancesco!
We forked Qt's tablet support inside Krita (because there are no major releases of Qt4 are planned) so you can patch the files inside Krita itself. Newer Krita supports Aiptek tablets, but they work quite unpredictable, e.g. they might report they are a "Keyboard" device (the workaround for that is already in Krita). I cannot explicitly add your check for "type 263", because this value is generated dynamically basing on some string. So could you please provide me with some information: 1) The patch you used to patch Qt 2) Full output of 'xinput list-props <id-of-your-tablet-device>' 3) Generate tablet event log https://answers.launchpad.net/krita-ru/+faq/2495 If we find out what atom string is used by this very tablet, we will include the code into Krita codebase. |
|
Registered Member
|
thanks for your help Boudewijn and Dmitry,
the patch applied to Qt code is really a bad workaround: in src/gui/kernel/qapplication_x11.cpp I just changed this line if (devs->type == ATOM(XWacomStylus) || devs->type == ATOM(XTabletStylus) || devs->type == ATOM(XTablet)) to this if (devs->type == 263 || devs->type == ATOM(XWacomStylus) || devs->type == ATOM(XTabletStylus) || devs->type == ATOM(XTablet)) This makes Krita use the pressure info from the tablet, but it seems that it gets blocked quite easily (is it maybe a sort of a buffer issue?) this is xinput list output about my tablet
and this is xinput list-props
A part of the tablet log in Krita is this:
Is the atom string simply "Stylus" or I must look for something else? this debug instruction
gives me following output:
thanks again for any help. I have Krita git code already downloaded and a build environment set, and I've successfully just built the last 2.9pre-alpha version, so I can easily test possible solutions on the real hardware if it can be useful. |
|
Registered Member
|
Hi, hvfrancesco!
Could you check whether this patch fixes the problem for you? http://paste.kde.org/pcbvgq2gc How to test: a) if your Qt is still patched: Check whether tablet works and the log contains [BLOCKED] events. b) if you Qt is clean Just check it started working |
|
Registered Member
|
I think I have a working patch, It seems to work as expected on master git branch.
The tablet, I forgot to mention, is Aiptek Hyperpen 12000U (old but still nice and reliable)
|
Bookmarks
Who is online
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan, sandyvee, Sogou [Bot]
