bugMyPaint - Bugs: bug #15476, Some of the color changers are...

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #15476: Some of the color changers are nonresponsive to tablet input

Submitted by:  David Gowers <ion9>
Submitted on:  Thu 25 Feb 2010 01:40:53 AM UTC  
 
Severity: 3 - NormalPriority: 5 - Normal
Status: Works For MePrivacy: Public
Assigned to: NoneOpen/Closed: Open
Release: 0.8.1+Planned Release: None
Operating System: Arch Linux

(Jump to the original submission Jump to the original submission)

Thu 26 Jun 2014 01:44:51 PM UTC, comment #17:

Hi - does anyone know if this bug is still happening with the current git master? There have been huge numbers of changes since 2011, both within MyPaint and externally, which may affect this bug. Also to my eye it looks heavily configuration-dependent.

I've not been able to reproduce it myself, even with a Bamboo tablet. You should probably be using the vanilla wacom xfree86 input packages these days for most Wacom tablets.

We're moving the tracker to Github, and that means being more assertive about closing down old stale bugs. If there's no feedback within a couple of weeks, let's close this one down and say it went away all by itself ☺

Alternatively, if it's still happening the best way to let us no might be to open an issue on Github about it. There seem to be more eyeballs and testers over there at the moment.

-------------------

This bug tracker will shortly be moving to github. As part of this
process, we're reviewing old bug reports on gna.org. Please
respond so that we know this bug is still live.

https://github.com/mypaint/mypaint/issues for the mypaint app, or
https://github.com/mypaint/libmypaint/issues for its brushlib

Andrew Chadwick <achadwick>
Project Administrator
Wed 11 May 2011 05:57:38 AM UTC, comment #16:

I spoke too soon.
It seems that if I activate the selectors using a hotkey, they are now okay; but if I activate them using the menu, the cursor becomes a crosshair and I cannot get any response.

David Gowers <ion9>
Project Member
Wed 11 May 2011 05:54:22 AM UTC, comment #15:

As of today, after recently switching to from the 'vanilla' xf86-input-wacom package, to use the
linuxwacom-bamboo-cth-ctl* (and probably, recent Xorg upgrades),
the HUD color choosers both work for me! WOOOHOOO! :D

  • I do not have a Bamboo tablet. But this driver works good ! ;)

It's not yet clear to me what is going on; but I'm currently considering a bug in the previous driver as most likely;
So for now, if anyone else has this problem, I suggest upgrading X and installing whatever the equiv. of ArchLinux "linuxwacom-bamboo-cth-ctl" is.

David Gowers <ion9>
Project Member
Wed 12 May 2010 12:44:00 PM UTC, comment #14:

Yes, this issue still exists with latest GIT version, exactly the same as before.

http://pastebin.com/BSZg6ZVK

## WITH COMMENTS LIKE THIS (hopefully the autoformatting here will not mangle the preceding text :)

Multiple uses of the color selectors does not cause any additional console output.

David Gowers <ion9>
Project Member
Wed 12 May 2010 09:39:09 AM UTC, comment #13:

Does this issue still exist?
Could you please pastebin the entire output from the terminal when running MyPaint? Preferably after first do some things that do work; draw, use eraser, etc.c. And then in the terminal, hit Return a couple of times to insert some newlines. Then try using the color changers that don't work a couple of times.

If we're lucky that can give us enough info to get an idea of the source of the issue.

Jon Nordby <jonnor>
Project Administrator
Fri 19 Mar 2010 08:55:25 AM UTC, comment #12:

That appears to spew a bunch of messages like the following

device change: Wacom Graphire3 6x8 eraser <enum GDK_SOURCE_ERASER of type GdkInputSource>
Traceback (most recent call last):
File "/usr/share/mypaint/gui/tileddrawwidget.py", line 115, in motion_notify_cb
f(self.last_event_device, event.device)
File "/usr/share/mypaint/gui/drawwindow.py", line 575, in device_changed_cb
if old_device.source == gdk.SOURCE_MOUSE and self.last_pen_device:
AttributeError: 'NoneType' object has no attribute 'source'

about 20 or so, every time I click (whether it is using the stylus nib or eraser)

David Gowers <ion9>
Project Member
Tue 16 Mar 2010 09:15:53 PM UTC, comment #11:

[unrelated to the main bug report] The Details button is supposed to pop up a dialog. The backtrace is always printed to stdout before showing any dialog. The bugfix to the dialog committed to git 2010-01-31 so there might be a different bug with the exception dialog :-\ Please fill a different bugreport if you can reproduce, eg with "git checkout 0dc0aa9ec9abfb9" (the commit just before fixing the eraser tip exception).

Martin Renold <martinxyz>
Project Administrator
Sun 14 Mar 2010 11:39:31 AM UTC, comment #10:

Re: version: Yes, I would have been using a git version no older than two weeks (relative to the time of this bug report being submitted). More likely only 1 or 2 days.

Admittedly I don't know whether the Details button is supposed to pop up a dialog or print out something on the console. Either way, when I click it, it looks like nothing happens. Some indication that 'backtrace has been printed on console' or the like would go a long way to making this dialog more user friendly
(assuming that it actually is functioning correctly, just in a way that I find confusing.)

David Gowers <ion9>
Project Member
Sat 13 Mar 2010 08:42:56 AM UTC, comment #9:

[unrelated to the main bug report] I have fixed the exception when using the eraser as the first device. However the "Details..." button in the exception dialog did work fine for this bug, are you sure you were using 0.8.1+ when trying it?

Martin Renold <martinxyz>
Project Administrator
Mon 08 Mar 2010 04:45:52 AM UTC, comment #8:

Just to clarify: changing to autoconfigured devices fixed the GIMP ruler issue, which is why that bug is now closed. However, this behaviour is still present in MyPaint, which leads me to believe there is a bug either in MyPaint itself, or in PyGTK, which only triggers in rare conditions.

Xf86-input-wacom-git seems to make no difference one way or the other VS linuxwacom.

David Gowers <ion9>
Project Member
Fri 05 Mar 2010 12:55:58 AM UTC, comment #7:

Am now using full HAL hotplugging for the tablet[1] (it's a mystery why X hung before; maybe HAL just wasn't configuring the appropriate devices).
Makes no difference to this bug; I still cannot get any response from the offending dialogs.

[1] at least, I think so. I didn't comment out the Inputdevice sections, just the references to them in ServerLayout. Will try that next time I reboot -- X always hangs when it tries to exit, so it's basically impossible to simply restart X, I have to 'sudo reboot -n' from inside X and restart the entire system.

I haven't installed xf86-input-wacom-git yet since it was just a fork of linuxwacom with cleaned up property names AFAICS. But I am doing so now.
(xf86-input-wacom AURpackage (not -git) is arguably misleading... it's unrelated to xf86-input-wacom project, and is just linuxwacom with a patch applied.)

David Gowers <ion9>
Project Member
Thu 04 Mar 2010 09:21:41 AM UTC, comment #6:

There is no problem with using hal input hotplugging in combination with custom xorg.conf video device configuration.
Custom input device configuration is also possible, but happens in /etc/hal/fdi/policy/*.fdi instead of in xorg.conf
By default I mean to use the driver provided .fdi, typically in /usr/share/hal/fdi/policy/20thirdparty/* and not do any explicit configuration yourself.
That X seems to freeze when you use it is likely because hal is not running and thus input does not work.

Are you using the xf86-input-wacom package for your driver? Or anything else?

Jon Nordby <jonnor>
Project Administrator
Thu 04 Mar 2010 05:26:48 AM UTC, comment #5:

I've tested with the eraser. It shows up correctly as "device change: eraser <enum GDK_SOURCE_ERASER of type GdkInputSource>"*
, but still cannot click on the offending color selectors.
So that GDK_SOURCE_MOUSE issue may have nothing to do with

  • after first triggering a 'programming error' in mypaint;

as usual, the Details button doesn't seem to do anything.

"device change: eraser <enum GDK_SOURCE_ERASER of type GdkInputSource>
Traceback (most recent call last):
File "/usr/share/mypaint/gui/tileddrawwidget.py", line 115, in motion_notify_cb
f(self.last_event_device, event.device)
File "/usr/share/mypaint/gui/drawwindow.py", line 575, in device_changed_cb
if old_device.source == gdk.SOURCE_MOUSE and self.last_pen_device:
AttributeError: 'NoneType' object has no attribute 'source'
Error in sys.excepthook:
Traceback (most recent call last):
File "/usr/share/mypaint/gui/gtkexcepthook.py", line 168, in _info
trace = analyse (exctyp, value, tb)
File "/usr/share/mypaint/gui/gtkexcepthook.py", line 94, in analyse
inspect.formatargvalues (args, varargs, varkw, lcls, formatvalue=lambda v: '=' + pydoc.text.repr (v)) + '\n')
File "/usr/lib/python2.6/inspect.py", line 875, in formatargvalues
specs.append(strseq(args[i], convert, join))
File "/usr/lib/python2.6/inspect.py", line 830, in strseq
return convert(object)
File "/usr/lib/python2.6/inspect.py", line 872, in convert
return formatarg(name) + formatvalue(locals[name])
KeyError: 'self'

Original exception was:
Traceback (most recent call last):
File "/usr/share/mypaint/gui/tileddrawwidget.py", line 115, in motion_notify_cb
f(self.last_event_device, event.device)
File "/usr/share/mypaint/gui/drawwindow.py", line 575, in device_changed_cb
if old_device.source == gdk.SOURCE_MOUSE and self.last_pen_device:
AttributeError: 'NoneType' object has no attribute 'source'
"

It looks like old_device does not get initialized in some circumstances (eg when the first device sending input is of type gdk.SOURCE_ERASER)

I'm using a Graphire3, BTW.

David Gowers <ion9>
Project Member
Thu 04 Mar 2010 04:37:17 AM UTC, comment #4:

correction: I am using evdev.. but not using X input hotplugging
(it seems to cause X to immediately hang).

A longer quote looks like:

"
Setting screen mode for "stylus"
Setting screen mode for "eraser"
Ignoring "cursor" (probably wacom mouse device)
Ignoring keybinding for <Actions>/WindowActions/OpenRecent
Ignoring keybinding for <Actions>/WindowActions/OpenRecent
Ignoring keybinding for <Actions>/WindowActions/SaveScrap
Ignoring keybinding for <Actions>/WindowActions/SaveScrap
Ignoring keybinding for <Actions>/FileActions/OpenRecent
Ignoring keybinding for <Actions>/FileActions/OpenRecent
Ignoring keybinding for <Actions>/WindowActions/Open
Ignoring keybinding for <Actions>/WindowActions/Open
Ignoring keybinding for <Actions>/WindowActions/Save
Ignoring keybinding for <Actions>/WindowActions/Save
Ignoring keybinding for <Actions>/WindowActions/New
Ignoring keybinding for <Actions>/WindowActions/New
Ignoring keybinding for <Actions>/WindowActions/ColorWheelPopup
Ignoring keybinding for <Actions>/WindowActions/ColorWheelPopup
Ignoring keybinding for <Actions>/WindowActions/SaveAs
Ignoring keybinding for <Actions>/WindowActions/SaveAs
/usr/share/mypaint/lib/pixbufsurface.py:22: DeprecationWarning: PyArray_FromDimsAndDataAndDescr: use PyArray_NewFromDescr.
def _init_(self, x, y, w, h, alpha=False, data=None):
device change: Core Pointer <enum GDK_SOURCE_MOUSE of type GdkInputSource>
device change: stylus <enum GDK_SOURCE_MOUSE of type GdkInputSource>
/usr/share/mypaint/gui/tileddrawwidget.py:106: DeprecationWarning: PyArray_FromDimsAndDataAndDescr: use PyArray_NewFromDescr.
def motion_notify_cb(self, widget, event):
"

I start drawing with the tablet, then switch to the mouse.
That 'Core Pointer' message then appears.
I go back to drawing with the mouse and get that 'stylus' message.

David Gowers <ion9>
Project Member
Thu 04 Mar 2010 03:53:55 AM UTC, comment #3:

"Could you try with the default configuration for your tablet?"
Do you mean with the exact configuration shown on Arch Linux Wiki?
sure, I'll do that.

Evdev? I'm using udev as the wiki page says.
I'm trying to use HAL but not sure if I can get that, since I'm obligated to do some manual configuration of the X video driver in xorg.conf.

"device change: stylus <enum GDK_SOURCE_MOUSE of type GdkInputSource> "

That is an exact quote. I could quote more, but it didn't seem relevant.

I'm currently trying to vanilla-ize my wacom setup and will post
a longer quote next time my X seems reasonably operable.

GIMP bug: https://bugzilla.gnome.org/show_bug.cgi?id=611668

David Gowers <ion9>
Project Member
Wed 03 Mar 2010 11:07:53 AM UTC, comment #2:

I'm also on Arch Linux, same package versions, using a wacom tablet, and I cannot reproduce the issue.
Are you using hal+evdev based or legacy style input? Could you try with the default configuration for your tablet?

And can you verify that you are getting GDK_SOURCE_MOUSE for the tablet? Best if you just paste the exact output.

Also, it would be nice if you put a link to the gimp bugreport here.

Jon Nordby <jonnor>
Project Administrator
Wed 03 Mar 2010 05:03:40 AM UTC, comment #1:

Correction: some things in GIMP exhibit the same behaviour. The rulers, for instance, you cannot drag a guide out from using the tablet, but can using the mouse. (I'll report a bug there, too)

I've looked up 'man wacom' and various guides, which all seem to indicate I've configured my Wacom correctly with XOrg, telling it to send core events etc.

Package versions:

X.org 1.7.5
GTK 2.18.7
PyGTK 2.16

David Gowers <ion9>
Project Member
Thu 25 Feb 2010 01:40:53 AM UTC, original submission:

The following 'dialogs' do not accept tablet clicks etc:

  • Color Ring
  • Color Changer

All other MyPaint dialogs (eg color sampler, GTK color selector) do accept tablet input.

All other applications are 100% operable using only the tablet, including tablet-aware apps like GIMP and Inkscape; pressure-sensitivity etc work normally there too.

If I change the preferences setting for the tablet from "screen" to "disabled", then they suddenly work.

I inserted some debugging messages in gui/colorselectionwindow.py:button_(press|release)_cb
. From these, it's clear that the callbacks are never being called when a tablet click occurs, only when a mouse click occurs.

I've already eliminated input mask as a possibility; using ALL_EVENTS_MASK instead makes no difference.

When changing to the tablet, it says:

device change: stylus <enum GDK_SOURCE_MOUSE of type GdkInputSource>

Is that normal? I thought it should be GDK_SOURCE_PEN, according to http://library.gnome.org/devel/gdk/stable/gdk-Input-Devices.html#GdkInputSource

David Gowers <ion9>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by achadwick (Posted a comment)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by jonnor (Posted a comment)
  • -unavailable- added by ion9 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 26 Jun 2014 01:44:51 PM UTCachadwickStatusNeed Info=>Works For Me
    Wed 12 May 2010 09:39:09 AM UTCjonnorStatusNone=>Need Info
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup