Thanks for the bug report!

(In reply to comment #0)
> I've been trying to use the newer MyPaint builds on my Surface Pro 3 (Windows
> 8.1). However, there are a couple of issues which seem they might be Gtk
> related:
> 
> 1- I don't see any pen pressure when running a my own build. A little debug
> script a MyPaint developer gave me, Gtk reports the stylus is a mouse, and so
> it doesn't report any pressure. I have the WinTab drivers installed, but it
> seems that GDK/Gtk doesn't recognize the stylus. It is reported as a mouse.

What version of GTK+ are you running in your build? is it GTK+3?

One thing to investigate on your side. GTK+ opens the wintab dll at runtime, rather than depending on it at build time, is perhaps your MyPaint build not finding the dll properly?

> 2- A pre-built version of MyPaint has pressure sensitivity, but as soon as I
> touch the screen, MyPaint goes haywire. I'm a little confused why, because as
> far as I know, the Surface hardware is supposed to disable touch input when the
> pen is on the surface; but it does.

I fear this has something to do with lower layers than GTK+'s, all we do here is translating the events. If you get that, it's probably because wintab tells this so.

Hi guys. I'm the MyPaint dev responsible for the build _documentation_ referred to in 1- above. It's a procedure intended for testers only initially,
https://github.com/mypaint/mypaint/blob/8ae1fed2/README_WINDOWS.md ,
and it's very new.

This procedure uses the MSYS2 GTK3 build, currently at version 3.14.6: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gtk3
Compiler is MinGW32-w64, target is MINGW32 (or however GNU spell it), a.k.a. native Win32 binaries.


The pre-built binary referred to in 2- above is by @tumagonx, and I'm afraid I don't know fully how it's made.


How can we investigate whether wintab.dll is linked at runtime when a process is running? Not a Windows geek here, but if you tell me how I can take a look.

Incidentally, the code seems to be failing at https://git.gnome.org/browse/gtk+/tree/gdk/win32/gdkdevicemanager-win32.c?h=gtk-3-14#n464 according to the warnings emitted. According to the code that's after a successful LoadLibrary() return.

Thanks for the quick response Carlos, and thanks Andrew for answering those questions!

Carlos, is there something I can test to verify if wintab.dll is getting linked properly, or something else that could confirm whether the problem lies with Gtk or something else?

I too am not much of a Windows guru, but I'll do what I can! Thanks!

My test system: Windows 7 64-bit guest OS; Wacom Intuos 5 tablet with the most recent 64-bit Windows drivers; VirtualBox PUEL with full USB support via extensions tested out with other kit; Debian testing/unstable host.

We're targeting Win32 mainly to suppress some warnings from NumPy under MinGW and 64bit. This could be changed. However it looks like the appropriate lib is being loaded, so those Wacom drivers should be talking to it, right?

And to echo Chris: thanks for the quick response, Carlos. I'd be happy to try out anything you recommend.

hey,

can you try to get a backtrace from this? To do so you will need to build gtk3 with debug. To do so clone the repository https://github.com/Alexpux/MINGW-packages and change the file:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gtk3/PKGBUILD#L27

changing that line to: options=('debug')

You can also follow the instructions here:
http://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/

in order to get the package built and installed. Then reproduce the issue and get the bt by running the app with G_DEBUG=fatal-warnings or passing --g-fatal-warnings.

After a slow build, I've reproduced with a debugging build of GTK+GDK,

  $ ls -l /tmp/MINGW-packages/mingw-w64-gtk3/*pkg.tar.xz
  -rw-r--r-- 1 testuser None 8764332 Jan 23 22:40 /tmp/MINGW-packages/mingw-w64-gtk3/mingw-w64-i686-gtk3-3.14.6-1-any.pkg.tar.xz
  -rw-r--r-- 1 testuser None 4647416 Jan 23 22:41 /tmp/MINGW-packages/mingw-w64-gtk3/mingw-w64-i686-gtk3-debug-3.14.6-1-any.pkg.tar.xz
  -rw-r--r-- 1 testuser None 8720428 Jan 23 21:51 /tmp/MINGW-packages/mingw-w64-gtk3/mingw-w64-x86_64-gtk3-3.14.6-1-any.pkg.tar.xz
  -rw-r--r-- 1 testuser None 5136424 Jan 23 21:51 /tmp/MINGW-packages/mingw-w64-gtk3/mingw-w64-x86_64-gtk3-debug-3.14.6-1-any.pkg.tar.xz


and I can reproduce the problem from MSYS2's MINGW64 environment, using that Python and the above gtk3.


However, I've tried with

  $ G_DEBUG=fatal-warnings python axischart.py

and

  $ G_DEBUG=fatal-warnings gdb -ex r --args python axischart.py

and in both cases all I get is a dialog, no backtrace.


I'm assuming you want me to to use gdb here, although you didn't say, but all I get from the latter is

-------------------8<-----------------
testuser@win7test MINGW64 /e/axischart_gist
$ which gdb
/mingw64/bin/gdb

testuser@win7test MINGW64 /e/axischart_gist
$ G_DEBUG=fatal-warnings gdb -ex r --args python axischart.py
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\msys64\mingw64\bin\python.exe...(no debugging symbols found)...done.
Starting program: c:\msys64\mingw64\bin/python.exe axischart.py
[New Thread 3608.0x1218]
[New Thread 3608.0x970]
[New Thread 3608.0x103c]

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000685f8004 in ?? () from c:\msys64\mingw64\bin\libglib-2.0-0.dll
(gdb) bt

+ Trace 234578

A debugging session is active.

        Inferior 1 [process 3608] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]

testuser@win7test MINGW64 /e/axischart_gist
$ 
------------------------->8-----------------------------

What should I try next?

Suggest retitling to: "[GDK] WinTab fails to init for Ntrig & Wacom" and marking it for 3.14.6.

I can reproduce the Gdk-CRITICAL and Gdk-WARNING messages with a really simple C binary, in the presence of the Wacom-supplied drivers:

-------------------------------------8<-----------------------------------
#include <gtk/gtk.h>

int
main (int argc, char **argv)
{
    GtkWindow *win;
    GtkDrawingArea *area;

    gtk_init(&argc, &argv);

    win = GTK_WINDOW(gtk_window_new(GTK_WINDOW_TOPLEVEL));
    g_signal_connect(win, "destroy", gtk_main_quit, NULL);

    area = GTK_DRAWING_AREA(gtk_drawing_area_new());
    gtk_widget_set_size_request(GTK_WIDGET(area), 300, 300);
    gtk_container_add(GTK_CONTAINER(win), GTK_WIDGET(area));

    gtk_widget_show_all(GTK_WIDGET(win));
    gtk_main();

    return 0;
}
-------------------------------------8<-----------------------------------
$ gcc testwintabinit.c -o testwintabinit.exe `pkg-config --libs --cflags gtk+-3.0` -g -O0 -Wall
------------------------------------->8-----------------------------------

But even with a debug build of gtk3, the backtrace after the first error is less than helpful and merely points off somewhere in glib.

-------------------------------------8<-----------------------------------
$ G_DEBUG=fatal-warnings gdb -ex r --args ./testwintabinit.exe
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\MyPaint\testwintabinit\testwintabinit.exe...done.
Starting program: E:\MyPaint\testwintabinit/./testwintabinit.exe
[New Thread 2616.0xd84]
[New Thread 2616.0xfb0]
[New Thread 2616.0x12e0]

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000685f8004 in ?? () from c:\msys64\mingw64\bin\libglib-2.0-0.dll
(gdb) bt

+ Trace 234580

A debugging session is active.

        Inferior 1 [process 2616] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]
------------------------------------->8-----------------------------------



I have tried to make a debugging build to get you more symbols using


-------------------------------------8<-----------------------------------
$ git diff
diff --git a/mingw-w64-glib2/PKGBUILD b/mingw-w64-glib2/PKGBUILD
index b571fad..570c282 100644
--- a/mingw-w64-glib2/PKGBUILD
+++ b/mingw-w64-glib2/PKGBUILD
@@ -8,7 +8,7 @@ url="http://www.gtk.org/"
 arch=('any')
 pkgdesc="Common C routines used by GTK+ 2.4 and other libs (mingw-w64)"
 license=('LGPL')
-options=('!debug' 'strip' 'staticlibs')
+options=('debug' 'staticlibs')
 install=glib2-${CARCH}.install
 depends=("${MINGW_PACKAGE_PREFIX}-gcc-libs"
         "${MINGW_PACKAGE_PREFIX}-gettext"
------------------------------------->8-----------------------------------

and compiling it using `makepkg-mingw -sL`, but it's refusing to build for me with those flags: http://paste.debian.net/142116/

I'm stuck.

Just to confirm, in the *ABSENCE* of the Wacom drivers, the Gdk-CRITICAL and Gdk-WARNING messages


---------------------------8<-----------------------------
(python.exe:3968): Gdk-CRITICAL **: gdk_screen_get_root_window: assertion 'GDK_IS_SCREEN (screen)' failed
(python.exe:3968): Gdk-CRITICAL **: gdk_window_new: assertion 'GDK_IS_WINDOW (parent)' failed
(python.exe:3968): Gdk-WARNING **: gdk_input_wintab_init: gdk_window_new failed
--------------------------->8-----------------------------


are *NOT* seen from either the Python test code at https://gist.github.com/achadwick/54e5b111e5ac908becf1 or from the C test code in comment 9. Our Windows expert is of the opinion that it's the first Gdk-CRITICAL that's hinting at something serious amiss on this platform that's later screwing up the WinTab init code.

No longer stuck! I've managed to get a debug build of glib2 up and working as well, with Alexei's help on #msys2. Backtrace for the C tester from comment 9 below:

testuser@win7test MINGW64 /e/MyPaint/testwintabinit
$ G_DEBUG=fatal-warnings gdb -ex r --args ./testwintabinit.exe
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\MyPaint\testwintabinit\testwintabinit.exe...done.
Starting program: E:\MyPaint\testwintabinit/./testwintabinit.exe
[New Thread 4604.0x13f0]
[New Thread 4604.0x1150]
[New Thread 4604.0xd08]

It then bombs out with a dialog containing the first Gdk-CRITICAL: asserion, namely "gdk_screen_get_root_window: assertion
'GDK_IS_SCREEN (screen)' failed". Clicking OK produces further output

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000685f8183 in _g_log_abort (breakpoint=1)
    at ../../glib-2.42.1/glib/gmessages.c:315
315         G_BREAKPOINT ();
(gdb) warning: Source file is more recent than executable.
(gdb)

And the backtrace you want, I think:

(gdb) bt

+ Trace 234581

A debugging session is active.

        Inferior 1 [process 4604] will be killed.

Quit anyway? (y or n) [answered Y; input not from terminal]






Is that of any use?

I can patch and rebuild this version as necessary to test this out, and also have WinTab-requiring hardware to hand which I can use to ensure pressure's getting through.

In gdk 3.9 there is gdk initialization refactor (for win32 that is in gdkdisplaymanager-win32.c) that start this issue i wonder why no gimp users report this up to now... we should on the same boat.

So the problem is why new window (without parent) fail at this stage? note that moving this chunk of code before other wintab init code still trigger failed assertion so it's not about loadlibrary (though this was once cause haywire effect in gtk2 iirc) or the rest of the wintab code.

gdkwindow.c
...
  if (!parent)
    {
      screen = gdk_screen_get_default ();
      parent = gdk_screen_get_root_window (screen);
    }
  else
    screen = gdk_window_get_screen (parent);
...

moving backward of the trace

gdkdisplay-win32.c
...
  _gdk_monitor_init ();
  _gdk_visual_init (_gdk_screen);
  _gdk_windowing_window_init (_gdk_screen);
  _gdk_events_init ();
  _gdk_input_init (_gdk_display);
  _gdk_dnd_init ();
...
this order hasn't changed at all till 3.14

*** Bug 715046 has been marked as a duplicate of this bug. ***

Created attachment 295454 [details] [review]
win32: Ensure we can create a window for wintab

The window used NULL as a parent window, which defaults internally to
using the root window of the default screen. But at the time wintab is
initialized, there is no default display/screen yet.

Fix this by retrieving this information from the given GdkDeviceManager,
so we don't have to wait for the display to be in place before
initialization.

This patch should fix the problem, but is completely untested, please give it a try.

Tested with simple testcode, no more errors. Thanks!
Will test it more on mypaint

Tested with the C test code in comment 9, and the gtk_init()-time errors go away for 64-bit. Not tested 32-bit yet.

Thanks for the patch, clearly part of the solution.

However I get new errors with the current MSYS2 GTK3, whose regular PKGBUILD and patches can be found at https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gtk3 - all I did was add the one at comment 15 into the mix.


On the first attempt to sent tablet pen events from an Intuos 5 (with correctly installed and current Wacom drivers), the output below is produced:

---------------------8<---------------------
$ ./testwintabinit.exe
[...]
(testwintabinit.exe:3484): Gdk-CRITICAL **: gdk_device_get_window_at_position_double: assertion 'GDK_IS_DEVICE (device)' failed

(testwintabinit.exe:3484): Gdk-CRITICAL **: gdk_device_get_window_at_position_double: assertion 'GDK_IS_DEVICE (device)' failed

(testwintabinit.exe:3484): Gdk-CRITICAL **: gdk_device_get_window_at_position_double: assertion 'GDK_IS_DEVICE (device)' failed
[...]
--------------------->8---------------------

Note that this code has no event handling of any sort.
I'm guessing this is one message per event.

The Python test code at https://gist.github.com/achadwick/54e5b111e5ac908becf1 does the same, and it does not recognise the tablet device as a new device.

Backtrace from the C code below.

---------------------8<---------------------
$ G_DEBUG=fatal-warnings gdb -ex r --args ./testwintabinit.exe
GNU gdb (GDB) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from E:\MyPaint\testwintabinit\testwintabinit.exe...done.
Starting program: E:\MyPaint\testwintabinit/./testwintabinit.exe
[New Thread 2752.0x8e8]
[New Thread 2752.0xe54]
[New Thread 2752.0x7f0]
[New Thread 2752.0x10b8]
[New Thread 2752.0x49c]
[New Thread 2752.0xd60]
[New Thread 2752.0xb20]

Program received signal SIGSEGV, Segmentation fault.
g_private_get (key=key@entry=0x6866dae0 <private_thread_memory>)
    at ../../glib-2.42.1/glib/gthread-posix.c:1058
1058      return pthread_getspecific (*g_private_get_impl (key));
(gdb) warning: Source file is more recent than executable.

(gdb) bt

+ Trace 234594

--------------------->8---------------------

Nearly there, I hope!

uhh yeah, just try it with mypaint, while msgs gone it can't detect tablet still..
gtk 3.14.7+patch

Bakhtiar: same big sequence of "gdk_device_get_window_at_position_double: assertion 'GDK_IS_DEVICE (device)'" messages?

yup same as you said

Created attachment 295520 [details] [review]
win32: Don't check the position of a NULL device

This function is given a barely setup GdkEvent, so the GdkDevice field
is still unset, causing warnings and misbehaviors when the position
is queried for it.

Given that the wintab GTK+ code seems to rely somewhat hard on the wintab
device managing the pointer cursor, query the pointer position from the
pointer itself.

Same than the previous patch, coding blindly here, so testing appreciated.

carlos: I'd be happy to test it out later on today. Many thanks for the patches and the retitling.

carlos: it works with mypaint now. thanks

Success with the Python test script, and nice smooth pressure coming through! No tilt or wheel input though :D

testuser@win7test MINGW64 /e/axischart_gist
$ python2 axischart.py
INFO:Axischart:New device class='gtk.gdk.DeviceWin32' name='System Aggregated Pointer' (src='mouse')
INFO:Axischart:New device class='gtk.gdk.DeviceWintab' name='WACOM Tablet Pressure Stylus' (src='pen')
INFO:Axischart:New device class='gtk.gdk.DeviceWintab' name='WACOM Tablet Eraser  ' (src='pen')

Minor wrinkle on the last device: it should be flagged as an eraser. It's not a killer for MyPaint though. Other than that though, this is looking pretty healthy I think.

This is with the patches in comment 15 and comment 22. Could these be pushed to master and to stable please?

And to confirm: pressure is working acceptably in MyPaint too, on a 64-bit build. Thanks, Carlos!

Attachment 295454 [details] pushed as 1543890 - win32: Ensure we can create a window for wintab
Attachment 295520 [details] pushed as ea98340 - win32: Don't check the position of a NULL device

Just wanted to chime in and say thank you for jumping on this so quickly! Really impressed, and grateful.

Cheers!