For example, I often have to click on the 'brush settings' icon twice or three times before the brush settings will actually come up. Or if I click on a spinner, it will keep going forever until I click again. Possibly related: certain tools are completely insensible on-canvas. perspective/distort tool, path tool, freehand path. In the case of perspective tool, I can adjust the tool settings and the canvas updates accordingly with the distorted content.. It is just the canvas itself which ignores all clicks. Reproducible: Always Steps to Reproduce: (clicking bug I hope is self explanatory. If not, it happens for EVERYTHING that's clickable, so just.. click on something) As for distort tool 1. Create new image 2. Paint a few marks 3. Activate distort tool 4. Attempt to move any on-canvas handle. Mouseover will give an appropriate cursor, but no response to clicking occurs. Actual Results: Everything clickable frequently (75% of the time) either sticks or doesn't respond. Expected Results: .. hopefully this is obvious. The problem renders Krita fairly unusable.
Can you try removing the ~/.kde/share/apps/krita/input/kritadefault.profile and try again? I'm a bit puzzled because I cannot reproduce this behaviour either in master or in the 2.8 branch.
Hi, D Gowers! Does it happens with the tablet device only, or it is also reproducible with the mouse? If only with the tablet, could you tell the model and the driver of the tablet? Isn't it a evdev one? Could you also checkout this revision of git (0796602cca547beee0f7247f92c1) and test whether it work fine there? To checkout you need to do: git checkout 0796602cca547beee0f7247f92c1 # then build as usual To get back to master after that: git checkout master # then build as usual
Boudewijn: Yes, that's always a good thing to test. Sadly, it has no effect on Krita's behaviour in this case. Dmitry: I apologize, I allowed my frustration to tempt me to post this without as much information as was really needed. * Yes, it's a tablet running on evdev driver. lsusb reports it as 'Bus 001 Device 002: ID 5543:0042 UC-Logic Technology Corp. Tablet PF1209'; it's rebadged as a Monoprice. This is why I filed under Tablet support, because I knew you had implemented an anti-pressure-overflow workaround, which I suspected was having unexpected consequences for non-painting interaction. * Running latest xf86-input-evdev from git (http://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/commit/?id=f6fcad8b107e834e26fb3da2c89e05294ff0a74c) * Testing with a mouse, all GUI elements behave normally (one click to activate buttons, all interaction with tools on and off canvas works as expected, etc) * Results of building the commit you specify: ** Tablet interaction on canvas is UNIVERSALLY insensible (no clicks are responded to at all, although the brush outline moves). Middle click to pan and right click to popup color/brush menu do work. ** Menu/button interaction works normally (single clicks are correctly interpreted)
Hi, David! Could you tell whether this tablet has ever worked with Krita properly? We have quite a long forum thread on that topic with the work not finished yet: http://forum.kde.org/viewtopic.php?f=139&t=98347&p=299674#p299674 The biggest problem here is that neither me or any other developer can test this issue, because we have wacom devices only. Btw, does your tablet support working with Wacom driver?
The tablet has not worked with Krita properly (as a tablet), Previously Krita (2.7) saw it and insisted it was a mouse. In the limited capacity of a mouse, it behaved normally (no 'stickiness' or rejection of input) My tablet can be set to use wacom driver, but I wouldn't call it 'working' -- it disables rightclick and middleclick, only leftclick+pressure is available.
Hi, David! Did you check the Wacom driver after our refactoring to the tablet code in October? Probably, the right/middle clicks are fixed now?
I will check again, but I think perhaps I've been unclear: The right and middleclick were not working -in any application, at all-. xinput test <device>, and xev, would not report any right/middleclick events, etc.
I guess this tablet in a evdev, which are not yet supported (I don't have a device). So I just rename it for now and we will wait until we get a device :)
Git commit 6708d8d4a7a5e311c2e539c029a9613dad6385d0 by Dmitry Kazakov. Committed on 25/03/2014 at 10:03. Pushed by dkazakov into branch 'master'. Added support for the 'evdev' tablets There are two complications: 1) In each event 'evdev' reports not all the axes preset, but only recently changed ones, so we need to keep the state of all the axes internally. 2) 'aiptek' tablet reports that it is a keyboard. Well, let us not disappoit it that it is not. Now we just check whether this nice "keyboard" supports xinput motion and proximity events. Related: bug 332239, bug 331572, bug 331917 M +86 -0 krita/ui/input/wintab/kis_tablet_support.h M +66 -16 krita/ui/input/wintab/kis_tablet_support_x11.cpp http://commits.kde.org/calligra/6708d8d4a7a5e311c2e539c029a9613dad6385d0
Git commit f406313a16c16294e1f438bb2a296d4fbaf075ab by Dmitry Kazakov. Committed on 25/03/2014 at 10:03. Pushed by dkazakov into branch 'calligra/2.8'. Added support for the 'evdev' tablets There are two complications: 1) In each event 'evdev' reports not all the axes preset, but only recently changed ones, so we need to keep the state of all the axes internally. 2) 'aiptek' tablet reports that it is a keyboard. Well, let us not disappoit it that it is not. Now we just check whether this nice "keyboard" supports xinput motion and proximity events. Related: bug 332239, bug 331572, bug 331917 M +86 -0 krita/ui/input/wintab/kis_tablet_support.h M +66 -16 krita/ui/input/wintab/kis_tablet_support_x11.cpp http://commits.kde.org/calligra/f406313a16c16294e1f438bb2a296d4fbaf075ab