Version: svn trunk (using KDE 4.7.1) OS: Linux This bug only happens in Ubuntu 11.10, probably because of the patched qt tablet support… But it happens only in the brush preset editor while it works fine for anything else (Dockers, menus, canvas…) so I think it probably can be fixed in Krita. The bug is: use a wacom stylus, open the preset editor with it: click with stylus on the brush settings categories (brush tip, opacity, size …) or the checkbox on some of those, doesn't work, more precisely it switches to mouse for a second; Some workaround is to click on it using side-button of the stylus (the MiddleMouseButton one), or better do "detach from toolbar" and then stylus click on it works correctly. Same thing happens in curve editors there(stylus click doesn't work unless I detach from toolbar). Same thing for predefined brushes selection (doesn't work with stylus unless detached from toolbar) Almost same thing for "Default/Soft brush" and "circle/square" brush tip settings, except that here detach from toolbar doesn't help. Reproducible: Always Steps to Reproduce: See details description Expected Results: See details description
Damn... I think this can be fixed in Krita, but only by completely reworking the way we handle input devices. I.e., no longer one tool per input device, but one active tool for all input devices and then some intelligence for making a difference between eraser and stylus. Apart from that possible workaround, it's still a bug in *buntu.
Bug report forwarded on launchpad: https://bugs.launchpad.net/ubuntu/+source/koffice/+bug/864014 Let's hope they'll can fix it so we can keep tool-per-input support.
boud: I understand your interest in seeing it fixed in Ubuntu specifically, but is that a hope that it is an Ubuntu-specific bug? Or is it something where you believe there are specific reasons it is a bug in Ubuntus Krita or Qt? The reason I ask is that you mention this can be viewed as an issue in the Krita implementation. I don't want to put the burden on Ubuntu just because Ubuntu is the only distro that sees the issue. If you believe it really is an issue with Krita or Qt in Ubuntu, please help us by giving some guidance on where the bug may lie. Thanks!
Well, we could work around it by removing functionality in Krita. Krita keeps track of different input devices (mouse, stylus, airbrush, puck...) and can assign different tools and different settings to those input devices. If we didn't try to do that, Krita wouldn't switch to a different tool when clicking with a stylus on a popup. Qt Popups are always tricky since they temporarily take focus. If, for instance, krita crashes when a popup is shown, all of X11 will hang until you kill Krita from a text terminal. That's something shared by all Qt apps, btw. I think that the click on the popup is somehow seen as a mouseclick, propagates and then switches the tool. This doesn't happen in other distributions or with a vanilla Qt, as far as I can tell -- but then, Ubuntu apparently patches Qt, and I suspect those patches. I can try to get Ubuntu running in a virtualbox and check whether the bug still happens if I replace Qt with Vanilla, but I won't have time until the weekend for that. Is there a url where I can see the list of patches Ubuntu applies to Qt?
Here's a link to the patches in Ubuntu for Qt: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/qt4-x11/oneiric/files/head:/debian/patches/ I'm not terribly familiar with how Kubuntu manages the package (they essentially own development of it is my understanding). I'm guessing that the patches prefixed with "kubuntu" are special sauce, and the other patches may be general patches that many distros apply but upstream won't take for various reasons. The patches related to input handling that have caused issues in Ubuntu are: kubuntu_28_xi2.1.patch kubuntu_94_xinput_valuators_fix.diff kubuntu_95_qt_disable_bounce.diff The first enables multitouch in Qt through the prototype XInput multitouch implementation in Ubuntu. We are working with X.org upstream to get an official multitouch implementation, and then we will work to get this patch into Qt upstream. The second patch is on its way upstream: https://qt.gitorious.org/qt/qt/merge_requests/1397. It fixes an implementation issue in upstream Qt where it doesn't handle XInput 1.x valuators properly. This was cobbled together with global vars due to time, and it's not out of the realm of possibility that moving the vars into the device class would fix things. This code is also only used for tablet devices, so it's a prime candidate to look for issues. To be clear, this is a bug that is seen when using the X.org server 1.10 or later. It is not due to anything specific with Ubuntu. The third patch fixes an issue that cropped up when multitouch was enabled. We weren't aware that Qt scroll views listen to gestures from touch events where available. The gestures are used for smooth scrolling. Unfortunately, the X scroll events were still being acted on, and this caused very odd scroll behavior on multitouch touchpads. The patch simply disables listening to gestures from touch events on scroll views.
I'm setting up Ubuntu now, but I've seen something similar in OpenSUSE today, but it's not quite the same. In the popup, I cannot switch the main categories, like size, etc. But it doesn't matter whether the popup is detached or not, and I cannot check those boxes with the mouse either.
still compiling in my ubuntu vm...
Oops... This turns out to be a bug in Krita after all! Even though the outward appearances were different from the issue we saw on Fedora and OpenSUSE, Animtim reports that after Silvio's patch everything works on Ubuntu: 13:26:51 < Animtim> Hey preset panel checkboxes are fixed, cool (works fine now in ubuntu 10.10 and 11.10) My apologies for all the noise and inconvenience, and thanks so much for working with us!
Sorry, actually I meant only the checkboxes are fixed. Still remains the issue with clicking on preset editor with stylus on the brush settings categories (brush tip, opacity, size …) doesn't work, more precisely it switches to mouse for a second; Some workaround is to click on it using side-button of the stylus (the MiddleMouseButton one), or better do "detach from toolbar" and then stylus click on it works correctly. Same thing happens in curve editors there (stylus click doesn't work unless I detach from toolbar). Same thing for predefined brushes selection (doesn't work with stylus unless detached from toolbar) Almost same thing for "Default/Soft brush" and "circle/square" brush tip settings, except that here detach from toolbar doesn't help. For this a "workaround" now is to click with stylus side button to activate the box and use keyboard arrows to switch setting.
Also note: when I say "click with middle-mouse-click from stylus side button", I mean hover the stylus above the setting and click on it, without touching the tablet. If such detail can help…
Hm... I actually compiled krita on my ideapad netbook where i installed a real ubuntu 11.10, instead of using a vm, and I cannot reproduce the problem with the brush editor popup :-(. I do have a very similar problem with the blending mode combobox, but that might also be a krita bug.
With a Wacom Bamboo Pen & Touch the behaviour is pretty much the same, except that the pen side button does not work. Quickly tapping on the checkboxes/drop down lists sometimes makes them work, which would seem to indicate a timing/race issue. The reason this is Ubuntu-specific is that AFAIK, no other distro ships with XInput 2 (as it is not finalised yet). But once they will this bug will probably manifest in them as well. Looking at Qt code for XInput shows that sometimes it does synthesize mouse events out of touches etc. This could well explain the dual delivery of events.
A workaround for touch-enabled Wacoms: finger taps work.
Maybe I should get a cheap touch-enabled wacom to see whether that helps me reproduce... I cannot reproduce on my ideapad with touch-screen, not with my intuos tablet.
Hm... Can someone who can reproduce the bug check whether it's still possible to select patterns, gradients and presets using the respective popups?
Checked: no problem to click/select patterns, gradients and presets with stylus in their respective popups.
Some more research done: If we return immediately from KoToolManager::switchInputDevice, there is no problem on Ubuntu anymore. However, printing the information about the input device shows an interesting issue. I applied the following patch: index b3a9120..7cc5371 100644 --- a/libs/flake/KoToolManager.cpp +++ b/libs/flake/KoToolManager.cpp @@ -655,13 +655,14 @@ void KoToolManager::Private::switchInputDevice(const KoInputDevice &device) tabletEventTimer.start(MSECS_TO_IGNORE_SWITCH_TO_MOUSE_AFTER_TABLET_EVENT_RECEIVED); } if (inputDevice == device) return; - if (device.isMouse() && tabletEventTimer.isActive()) { + if (device.isMouse() && !inputDevice.isMouse()) { // tabletEventTimertisActive()) { // Ignore switch to mouse for a short time after a tablet event // is received, as this is likely to be either the mouse event sent // to a widget that doesn't accept the tablet event, or, on X11, // a core event sent after the tablet event. return; } + qDebug() << "going to do switcheroo from" << inputDevice << "to" << device; inputDevice = device; QList<CanvasData*> items = canvasses[canvasData->canvas]; On opensuse, we get: going to do switcheroo from mouse to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to eraser stylus (id: 0 ) going to do switcheroo from eraser stylus (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to eraser stylus (id: 0 ) On Ubuntu, we get: going to do switcheroo from to going to do switcheroo from to going to do switcheroo from to going to do switcheroo from to Cyrille concludes: We are either facing a but in xinput2, in qt/xinput2 or in the wacom driver. If it were not for the report of a problem in gimp/painter, I would have blamed qt/xinput2... It might be tricky to know exactly where it is. There is a utility called "xinput" (in the xinput package on ubuntu/debian, not sure for opensuse), if you run "xinput list" you should get something like: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ SynPS/2 Synaptics TouchPad id=10 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet eraser id=13 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet touch id=14 [slave pointer (2)] ⎜ ↳ Serial Wacom Tablet stylus id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)] ↳ ACPI Virtual Keyboard Device id=16 [slave keyboard (3)] If it does not, then it is either a bug xinput or the driver. Then to know if the problem is in Qt/xinput2, an other possibility is to compile a clean/unpatched qt, and check if it works or not.
On a fresh Ubuntu, I get: boud@talnus:~$ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 stylus id=9 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 eraser id=13 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 cursor id=14 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 pad id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=12 [slave keyboard (3)]
I get the following output on ubuntu: going to do switcheroo from mouse to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 ) going to do switcheroo from pen stylus (id: 0 ) to unknown pointer no device (id: 0 ) going to do switcheroo from unknown pointer no device (id: 0 ) to pen stylus (id: 0 )
On opensuse: boud@talnus:~> xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 eraser id=9 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 cursor id=10 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 pad id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos3 6x8 stylus id=12 [slave pointer (2)] ⎜ ↳ TPPS/2 IBM TrackPoint id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ ThinkPad Extra Buttons id=15 [slave keyboard (3)]
This patch fixes the issue on Ubuntu for me: diff --git a/libs/flake/KoInputDevice.cpp b/libs/flake/KoInputDevice.cpp index bd1b235..a38eb04 100644 --- a/libs/flake/KoInputDevice.cpp +++ b/libs/flake/KoInputDevice.cpp @@ -72,9 +72,9 @@ qint64 KoInputDevice::uniqueTabletId() const bool KoInputDevice::isMouse() const { - return d->mouse; + return d->mouse || d->device == QTabletEvent::NoDevice || d->pointer == QTabletEvent::UnknownPointer; } - + bool KoInputDevice::operator==(const KoInputDevice &other) const { diff --git a/libs/flake/KoToolManager.cpp b/libs/flake/KoToolManager.cpp index b3a9120..7cc5371 100644 --- a/libs/flake/KoToolManager.cpp +++ b/libs/flake/KoToolManager.cpp @@ -655,13 +655,14 @@ void KoToolManager::Private::switchInputDevice(const KoInputDevice &device) tabletEventTimer.start(MSECS_TO_IGNORE_SWITCH_TO_MOUSE_AFTER_TABLET_EVENT_RECEIVED); } if (inputDevice == device) return; - if (device.isMouse() && tabletEventTimer.isActive()) { + if (device.isMouse() && !inputDevice.isMouse()) { // tabletEventTimertisActive()) { // Ignore switch to mouse for a short time after a tablet event // is received, as this is likely to be either the mouse event sent // to a widget that doesn't accept the tablet event, or, on X11, // a core event sent after the tablet event. return; } + qDebug() << "going to do switcheroo from" << inputDevice << "to" << device; inputDevice = device; QList<CanvasData*> items = canvasses[canvasData->canvas]; lines 1-36/36 (END) It basically assumes that any unknown device that nonetheless generates a tablet even is, actually, a mouse. In my opinion, it just papers over a bug lower in the stack, but it's the best I can do.
Git commit eab5746f9f94b48f67ec20cc6d28e9221c53fef1 by Boudewijn Rempt. Committed on 09/11/2011 at 14:25. Pushed by rempt into branch 'master'. KoToolManager: only switch tools between tablet devices This solves two bugs: * On Ubuntu, the xinput system seems to be broken. We are getting tablet events with unknown device/unknown pointer. If we assume that this means that we're actually getting mouse events, everything works fine. * Users prefer to be able to use the mouse sometimes to set the values for the tools and options, and then use the stylus again to paint. So do not switch back to mouse from tablet device, ever. We now also save on activating a single-shot timer a lot of times. BUG:285501 BUG:283130 M +5 -2 libs/flake/KoInputDevice.cpp M +5 -11 libs/flake/KoToolManager.cpp M +0 -2 libs/flake/KoToolManager_p.h http://commits.kde.org/calligra/eab5746f9f94b48f67ec20cc6d28e9221c53fef1