Project

General

Profile

Bug #10144

Mask brush stop responding to the mouse if a graphics tablet is used.

Added by Matthew Harrison over 5 years ago. Updated about 4 years ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
Darkroom
Start date:
10/09/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
1.4.2
System:
Ubuntu
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I'm using a Wacom Intuos CTH-680 on Kubuntu 14.04. This generally works fine, but when trying to add a mask I have some problems.

In darkroom, using the mask manager I select "Add brush". The brush initially responds to the mouse as expected. As soon as the tablet is used, the brush and the whole area with the picture stops responding to the mouse. The mouse still works in the rest of DT UI.

I seem to be able to get the mouse working again by right clicking the pen when hovered over the picture a few times to zoom cycle the picture. It doesn't seem to be fixed by the first click every time, but a few seems to do it.

After this workaround the brush will respond happly when switching between pen and mouse for the life of the brush, but if a new brush is created it is created in the pen only state.

This may be related to Bug #9668.


Related issues

Related to darktable - Bug #10367: no tablet support in development versionFixed03/14/2015

Has duplicate darktable - Bug #10766: No possibility to draw masks with new computer on Fedora/RHELFixed12/09/2015

History

#1 Updated by Ulrich Pegelow over 5 years ago

Hi,

I fear we can help much about this. All that darktable does is reading the according pen state:

static gboolean
mouse_moved (GtkWidget *w, GdkEventMotion *event, gpointer user_data)
{
  double pressure = 1.0;
  if(gdk_device_get_source(event->device) == GDK_SOURCE_PEN)
  {
    gdouble axes[gdk_device_get_n_axes(event->device)];
    gdk_device_get_state(event->device, gtk_widget_get_window(w), axes, NULL);
    gdk_device_get_axis(event->device, axes, GDK_AXIS_PRESSURE, &pressure);
  }
  dt_control_mouse_moved(event->x, event->y, pressure, event->state & 0xf);
  gint x, y;
  gdk_window_get_pointer(event->window, &x, &y, NULL);
  return FALSE;
}

Most likely it's your driver that has issues.

Ulrich

#2 Updated by Matthew Harrison over 5 years ago

Ulrich Pegelow wrote:

Hi,

I fear we can help much about this. All that darktable does is reading the according pen state:

[...]

Most likely it's your driver that has issues.

Ulrich

That looks like the pen code, but it's the mouse that plays up. The mouse only plays up in the one window, not anywhere else.

#3 Updated by Ulrich Pegelow over 5 years ago

What does darktable tell you when you start it with '-d input'?

#4 Updated by Roman Lebedev almost 5 years ago

  • Related to Bug #10367: no tablet support in development version added

#5 Updated by Guillaume Subiron over 4 years ago

I can confirm the bug as I have the same problem on my darktable 1.6.8 on Debian testing with a Wacom Intuos Point & Touch S.

This is very annoying because it forbids me to set the brush size, hardness and opacity when I use the tablet. Indeed, when I select the brush with the stylus, the mouse doesn't react in the image area, so I can't use the scrolling.

I also have mapped the tablet buttons and the tablet touchpad to scroll, but I have the same problem with them. I suspect that "Wacom Pad" is not the same device as "Wacom Stylus", so this is the same bug as jumping from stylus to mouse…

And if I may add, are you sure this bug is related to #10367 ? This seems strange to me.

Thanks.

# darktable -d input                                
X server found. dri2 connection failed! 
/dev/dri/card0 not authenticated
X server found. dri2 connection failed! 
/dev/dri/card0 not authenticated
beignet-opencl-icd: no supported GPU found, this is probably the wrong 
(If you have multiple ICDs installed and OpenCL works, you can ignore t
[input device] Input devices found:

Virtual core XTEST pointer (no cursor), source: GDK_SOURCE_MOUSE, mode:
  GDK_AXIS_X
  GDK_AXIS_Y

Razer Razer Lycosa (no cursor), source: GDK_SOURCE_MOUSE, mode: GDK_MOD
  GDK_AXIS_X
  GDK_AXIS_Y
  GDK_AXIS_PRESSURE

Wacom Intuos PT S Pen stylus (no cursor), source: GDK_SOURCE_PEN, mode:
  GDK_AXIS_X
  GDK_AXIS_Y
  GDK_AXIS_PRESSURE
  GDK_AXIS_XTILT
  GDK_AXIS_YTILT
  GDK_AXIS_WHEEL

Wacom Intuos PT S Finger touch (no cursor), source: GDK_SOURCE_PEN, mod
  GDK_AXIS_X
  GDK_AXIS_Y
  GDK_AXIS_PRESSURE
  GDK_AXIS_XTILT
  GDK_AXIS_YTILT
  GDK_AXIS_WHEEL

Wacom Intuos PT S Pad pad (no cursor), source: GDK_SOURCE_PEN, mode: GD
  GDK_AXIS_X
  GDK_AXIS_Y
  GDK_AXIS_PRESSURE
  GDK_AXIS_XTILT
  GDK_AXIS_YTILT
  GDK_AXIS_WHEEL

Wacom Intuos PT S Pen eraser (no cursor), source: GDK_SOURCE_ERASER, mo
  GDK_AXIS_X
  GDK_AXIS_Y
  GDK_AXIS_PRESSURE
  GDK_AXIS_XTILT
  GDK_AXIS_YTILT
  GDK_AXIS_WHEEL

Razer Razer Copperhead Laser Mouse (no cursor), source: GDK_SOURCE_MOUS
  GDK_AXIS_X
  GDK_AXIS_Y
  GDK_AXIS_PRESSURE

Core Pointer (with cursor), source: GDK_SOURCE_MOUSE, mode: GDK_MODE_SC
  GDK_AXIS_X
  GDK_AXIS_Y

#6 Updated by Guillaume Subiron over 4 years ago

This bug is fixed on the master branch.

#7 Updated by Roman Lebedev about 4 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Fixed

As per Guillaume Subiron comment.

#8 Updated by Roman Lebedev about 4 years ago

  • Has duplicate Bug #10766: No possibility to draw masks with new computer on Fedora/RHEL added

Also available in: Atom PDF

Go to top