I think my gateway is using the new "finepoint" technology not the wacom. Just incase that helps.

Tablet support is in GTK+. Reassigning.

PLease fill in the GTK+ version you are using.

I was using gtkmm-runtime-2.4.8cvs-2 but just updated to:
gtk+-2.8.9-setup-1

I restarted windows xp after installing the update and there's still no pressure sensitivity. When I open preferences in gimp and open the configure extended input devices is says there are no extended input devices.

Is there another version of GTK I need? Or is there something else that I need to do to get it working?

Thank you

GTK+ on Windows currently only support the Wintab API for talking to tablets. I suggest you check with Gateway if there are Wintab compatibility drivers for your computer.

Anybody have any idea what API Paint.net uses to access this tablet? 

The source code for paint.net is available at:

http://www.eecs.wsu.edu/paint.net/download.html#src

I'm not much of a programmer or I'd download it and try to figure out the API. I searched their forum and website for API documents and all I found was:
The code is the documentation. We don't spoon feed noobys. Or something like that.
The forum does mention some things about people requesting wintab compatibility. So maybe paint.net doesn't work with all tablets.

Sorry I couldn't be more help.

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

FYI, Paint.NET seems to be open-source (MIT license) and src/readme.txt says it depends on Microsoft Windows XP Tablet PC Edition Software Development Kit 1.7 (http://www.microsoft.com/downloads/details.aspx?FamilyID=b46d4b83-a821-40bc-aa85-c9ee3d6e9699&DisplayLang=en).

To make this more interesting, the WinTab API has been tangled into a patent mess. Apparently only a few (only Wacom?) tablet manufacturers bothers to pay license fee to some company that claims a patent on WinTab API, or something like that. See http://www.pointing.com/Wintab.html and http://www.geigges.de/f_support_d.htm for instance, and google for more information...

Note: when the bug reporter says "a tablet" he means "a Tablet PC". For its tablet functionality to work in gdk/win32, one probably would need Tablet PC support in GTK+. For "real" external tablets other than Wacom, Microsoft's Tablet PC API presumably is not involved at all, but to get at these tablets one needs to use something else. (Manufacturer-specific APIs? gack...)

the api in question is the ms tablet pc ink api (don't know what the correct official name is).
as comment 9 says there's an sdk by ms that contains the resources needed for development on (every, not only tpc) xp.
docs are available on msdn: http://msdn2.microsoft.com/en-us/library/ms819534.aspx (Pen Overwiev).

see bug 145430 comment 18 and 19, including my offer (affecting this bug even more).

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

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

The documentation for the Windows Tablet PC API can be found at http://msdn.microsoft.com/en-us/library/ms704849%28VS.85%29.aspx, with the core reference at http://msdn.microsoft.com/en-us/library/ms703485%28VS.85%29.aspx, the real-time reference at http://msdn.microsoft.com/en-us/library/ms701683%28VS.85%29.aspx, the environment setup explanation at http://msdn.microsoft.com/en-us/library/ms700652%28VS.85%29.aspx, and a primer to programming with it at http://msdn.microsoft.com/en-us/library/ms704172%28VS.85%29.aspx.

Now, can we please move forward on this 4-year-old bug? The state of Tablet PC programming on Windows has advanced by leaps and bounds since this bug was first issued (namely with the inclusion of Ink Services in all distributions of Windows from Vista onward, and its integration into the base Windows SDK). I imagine any GTK Win32 programmer already has all the necessary software for development on this, and I'd be able to provide testing on the hardware (for cases like pressure sensitivity that can't be emulated with a mouse).

> Now, can we please move forward on this 4-year-old bug

Yes, thanks for the offer, welcome!

> I imagine any GTK Win32 programmer already has all the necessary software

Hmm, you think there is a great bunch of them, with nothing else to do?

I've very recently resurrected an old Wacom GD by buying an USB adapter.

It works fine in Windows 7 32bit in general (after fiddling a bit with drivers and register hacks)

It does not however fine in GIMP or InkScape. I have experimented after reading around, and I'll try and explain my findings.

First, let's start with what happens without altering any settings in GIMP/InkScape or Windows.

When clicking on either of the program, the tablet to screen mapping is changed for the mouse cursor. Effectively, the screen is halfed and placing the stylus on the bottom edge on the tablet moves the cursor to somewhere near the middle of the screen.

However, and this is the interesting part, the actual brush input is where it should be. The cursor and the brush position are in an obvious conflict - I can't use the brush unless the offset cursor points on the canvas.

The pressure sensivity however works just fine and there is no freezing going on.

The second test was done with the --no-wintab argument.

Now the cursor and brush align, but I get the reported freezing every second or so when painting.

Third test was without  --no-wintab argument but with the Tablet PC service disabled in windows. Disabling this service renders the wacom non functional in windows. But it still works in GIMP/InkScape. The behaviour is excactly the same as in my first attempt.

So something fishy is going on with the CURSOR position. The actual input of the wacom seems to be aligned and proper!

Note: in all cases I've made sure that I have the "screen" option selected in the preferences for external devices.

I forgot to mention that --no-wintab obviously removed the pressure sensitivity.

I also tried the --no-wintab AND disabling the Tablet PC service - that didn't turn out to work at all. (why should it) However, I can get some kind of respons when pressing one of the stylus buttons and then moving the stylus around - however it seems to only sample one or two points on my movement and all I get is straight lines and an increasingly erratic behaviour. In the end, I couldn't even use my normal mouse to access the menus.

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

Just offering my services for testing, with an interest as MyPaint maintainer. We have a number of tablet-related Windows issues piling up at the moment, and all look very upstreamish.

Open Source software stack support in Windows has improved dramatically in the past few years (my current favourite toy is MSYS2 <https://msys2.github.io/>), to the extent that debugging recent GDK on Windows isn't too horrible an experience even for a Linux-based weenie like me.

GTK+ still only supports Wintab, right?
Nowadays I seem to see quite a bit of messages about tablets/pens using Windows Ink drivers. Would be nice to have support for this so that GIMP gets it as well when we will go for GIMP 3. :-)

Relevant (it seems) link about the API implementation: https://docs.microsoft.com/en-us/windows/uwp/input-and-devices/pen-and-stylus-interactions

Jehan: I believe that GTK is still Wintab-dependent.

Surprisingly, GTK 3.22.[15-19] does not support the Cintiq 13HD (DTK-1301) in 64-bit Win7 with the latest (6.3.24-2) drivers: no pressure, no identification of device.  However the same stack supports the older Intuos 5 (PTH-650) just fine!

That's an omission, since the Cintiq is otherwise a Very Nice Tablet.

Chasing something that looks very like this bug with a responsive end user downstream (Yiynova tablet monitor of some kind): https://github.com/mypaint/mypaint/issues/857

Quick uninformed question: as a class, can tablets that are also monitors support the Wintab API *at all*?  Because that would be another reason to make the leap to Windows Ink ☺

Offer still stands: I can build, I can test (with a small stable of tablets), I can work with end users to gather reports.

> Because that would be another reason to make the leap to Windows Ink ☺

Maybe that's what you meant, but just to be sure: GTK+ should be able to support both Wintab and Windows Ink. It seems that Windows Ink is not perfect and some people who have a tablet with both drivers available seem to prefer Wintab (apparently Photoshop now uses Ink by default and I could find various blog posts on the web where people explains the configuration settings to revert to using Wintab on the Adobe software because they had accuracy issues or something similar).

So we should similarly be able to use both drivers.

(In reply to Jehan from comment #23)

> So we should similarly be able to use both drivers.

The issue is not "we should support another driver"; the issue is: who's going to write the code to support Windows Ink.

I may have been confusing Windows Ink (Win 10 and later) with the Tablet PC SDK API (Windows XP tablet edition, Windows Vista and later). The latter should be driveable from C code via its COM interface, not sure about the former.

The Tablet PC SDK *may* support all of the axes we need. It looks extensible enough beyond X and Y, looking at the "::Packets" sample code below. So if it has widespread driver support, then it might be a better fit for GTK due to its maturity.

Tablet PC SDK API references:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms696350(v=vs.85).aspx

https://msdn.microsoft.com/zh-cn/library/ms698100(v=vs.85).aspx (handier guide to its architectural and data flow details, English language body)

Somebody still needs to find the time to write this, ofc. ☹

> The issue is not "we should support another driver"; the issue is: who's going to write the code to support Windows Ink.

I know how Free Software works, thanks. ;-)

I was only stating a note, for self and for whoever is the one who would write this code, that some tablets apparently work with one type of driver and not the other, and reciprocally, and also that apparently some work with both but better with one (according to various forums and blog posts which would advise one over the other). So I reminded that we could have both implementation (and not make a replacement); and by *we*, I include myself (I could end up being the one implementing this, who knows!). I was in no way making a support request. :-)

(In reply to Jehan from comment #23)
> > Because that would be another reason to make the leap to Windows Ink ☺
> 
> Maybe that's what you meant, but just to be sure: GTK+ should be able to
> support both Wintab and Windows Ink. It seems that Windows Ink is not
> perfect and some people who have a tablet with both drivers available seem
> to prefer Wintab (apparently Photoshop now uses Ink by default and I could
> find various blog posts on the web where people explains the configuration
> settings to revert to using Wintab on the Adobe software because they had
> accuracy issues or something similar).
> 
> So we should similarly be able to use both drivers.

Please provide some links to help form an opinion if you have them handy :), given all the windows/photoshop stack is a giant black box the issue could lie about anywhere. I personally would find it too strange that the Windows API were subpar in terms of axis ranges or event delivery rate.

I guess it will come down to experimentation...

> Please provide some links to help form an opinion if you have them handy

I didn't save links, but they are easy enough to find with the first page of a "Wintab Windows Ink" web search (which is how I first found them, when I just wanted to know a bit more about these). :P

For instance here a complaint (2016) about getting annoying lag on the pen with Windows Ink: https://forums.adobe.com/thread/2134092
Here some blog post (2014) about basically the same issue with unresponsive buttons: http://framedbythomas.com/get-wacom-pressure-sensitivity-working-windows-8-1-photoshop-cc-2014/
You get a bunch of these in a web search and the various comments suggest that it's a common issue.

Now I don't know, maybe these are just youth bugs of Windows Ink which are meant to disappear with time. I hope so. But just in case, I'd prefer to avoid any regression on GTK+/GIMP/MyPaint. :-)

Obviously Photoshop kept both implementation itself since it's possible to revert to using Wintab (even though it's a bit hidden, not in preferences dialog, but by editing a config file).

P.S.: also there is simply the problem that if I understand well, "Windows Ink" is indeed an alternative driver and tablet constructors need to provide support for these. Old deprecated tablets therefore probably won't have any new driver, hence any support for these and we don't want to lose supports on tablets which used to work.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/262.