This is probably an upstream issue with GDK(The library MyPaint relies on for input devices), but we should keep track and push support for Windows Ink. This will allow us to use N-Trig hardware as well. For example, 3rd generation and beyond Surface Tablets/Laptops use it, and also any laptop made in 2016 and up that has pen support use windows ink.
Here more infro from Microsofts Devloper page:
And here’s the decade-old bug report with more background:
https://bugzilla.gnome.org/show_bug.cgi?id=343773
Surprisingly there are only 29 comments. Maybe we just need to make more noise? On the other hand, as @Jehan noted it seems to be common (at least from googling) for people to disable Windows Ink to avoid laggy brushes. SO, even if GDK supported Windows Ink, would it even work well? It’s 2017 and many native Windows Apps recommend disabling Windows Ink? It seems strange, doesn’t it? edit Krita just released experimental support for Windows Ink so maybe we can see how that goes 
Surprisingly there are only 29 comments. Maybe we just need to make more noise?
As Emmanuele Bassi noted, “making noise” is not useful, quite the contrary. One of us (the people who care about the topic; it could be someone from MyPaint, from GIMP, maybe Carlos who manages Wacom tablets on GNOME… or someone else) will have to implement it at some point if we really want it.
Personally I can’t make the time for this right now since Windows is not my platform of choice, though I still care (so maybe one day if I get very bored or if I get funded for this).
On the other hand, as @Jehan noted it seems to be common (at least from googling) for people to disable Windows Ink to avoid laggy brushes. SO, even if GDK supported Windows Ink, would it even work well? It’s 2017 and many native Windows Apps recommend disabling Windows Ink? It seems strange, doesn’t it?
This must be one of these cases where you will have tablets working better with a driver while others will work better with the other driver. So it likely means we should just have both implementations and appropriate settings to allow people to test and choose (better would be some kind of detection of what will work better for which tablet/pen, but I doubt such a test can be automatized, can it?).
You’re right, the only helpful noise is requests from actual users that have devices without any wintab drivers, I suppose. After all, there’s no reason to work on something that practically no one needs. It sounds like a bit of a pain to install wintab drivers sometimes, but is there really a crisis brewing for support for N-Trig, etc?
A few of our issue tickets have been mainly from Surface owner which the 3rd and 4th gen use N-trig hardware. And since Microsoft is the trends setter for similar devices, the number of N-trig users are going to grow. Plus I do own a tablet which uses N-trig as well, so I can do some testing on windows. I just need to get a copy of windows 10 installed on a drive.
I guess for the time being we might put together a guide for installing wintab drivers. It sounds like the Microsoft driver is missing some shared library which needs to be installed as well. This thread has some good information:
I set my thread as a wiki so you can also add any info that is related to this as well.
If we were to write some custom windows code (either using window.add_Filter in GTK, or just by hooking the main thread to get the messages), It would be possible to capture the underlying WM_POINTERUPDATE messages from which one can get the pressure, tilt values, and just set those into the appropriate place where pressure is got from GTK if GTK isn’t reporting pressure.
This isn’t the nice way to do it, and it means putting in windows specific code, but given the GTK feature request has been open some years, it clearly isn’t high priority for general GTK development. Many devices don’t come with wintab drivers as default, and some (e.g. hp laptops) don’t appear to have working wintab drivers any more, so I can see it being worth doing.
I might try and hack it together if I have time.
