TabletSupport

Tablet Support

Information regarding tablet support in wine

Getting your tablet working

Specs and Docs

Example Code

Active Bugs

Bugs that still have active testers and investigators.

  • 7316 Tablet Pressure Sensitivty Not Working in Flash 8

  • 11846 tablet pressure sensitivity not working in Sai and many other key graphic applications

  • 13808 Tablet behaves like mouse in Pixia 4.2a - ABANDONED

  • 14550 MS Ink demo program fails

  • 15235 After setup drivers for WizardPen-tablets (wizardpen_drv.so) in X11, Photoshop 7.0 crash at startup - ABANDONED

  • 15443 Wacom Bamboo drawing tablet lacking pressure sensitivity with Manga Studio EX 3.0

  • 15689 Microsoft Onenote 2007: no drawing; inkobj.dll needs to implement ITablet?

  • 17309 Wacom detection fails on Wacom-locked ArtRage edition

Free Test Apps

Developer chatter

Update by JeremyWhite 30 Dec 2007

After a fairly thorough review and a set of patches to restore Photoshop functionality, I believe I've come to a fair understanding of the Wintab API and the status of Wine's implementation.

And, unfortunately, at this point, that state is poor. What we have right now is an implementation that serves to make applications like Photoshop work properly most of the time mostly through luck, rather than through rigor.

First, the Wintab specification itself is difficult to find. (It went proprietary at one point, and is not longer publicly available. You have to start with wintab 1.1, and 'deduce' relevant changes in 1.2, 1.3, and so on).

Second, the Wine implementation has never really benefited from a thorough apples to apples comparison. That is, it would be useful to write a test program for the tablet API. It could easily live under a tests/ directory of wintab32, although much of the time it likely won't trigger, as most people don't have tablets.

But it would be useful to run through each of the WTInfo invocations to make sure they compare rationally between Windows and Linux. Several areas I've seen that are weak include the button mapping and button masks; Wine's implementation until recently was essentially broken. Luckily, it seems like Photoshop doesn't use that information... The whole logic around contexts seems quite shaky at best. Further, there is a whole new set of devices around pads, and 4d mice, and things like that, and I don't think we relay any of that information.

This would be a great intro project for a new programmer with moderate talent, and, of course, a tablet.

6. Accessing X11 Calls

13 Jan 2003 - 16 Jan 2003 (10 posts) Archive Link: "Help wanted: Implementing Wine dlls that need access to X11 commands."

Topics: IO

People: Robert North, Alexandre Julliard, Lionel Ulmer

Robert North wanted to know how to go about creating a DLL that needs to hook in to the current X11 display code:

I'm about to start serious implementation on the wintab32 dll. I now need some guidance as to how best to implement it's access to X11 calls.

My current thoughts on how to do this are given below. Are they reasonable??

I need to access a number of X11 calls, largely in the XInput extension. None of these are exposed by the x11drv dll.

My intention is currently to change nothing in the x11drv dll.

The only hints I can find about how to do this are from the direct draw and open gl dlls.

These dlls can do the following:

  • Get the X11 Display object of a gdi context.
  • Get the X11 window handle given a win32 window handle.
  • Synchronise with the x11_drv code for multi threading.

My wintab code will do the same.

The one difference will be that wintab will create it's own X11 Display objects. It will interrogate a gdi's X11 Display object to ensure it talks to the same screen.

The wintab code will also require multiple message queues. To implement this I intend to use one display object per queue. (Much as wine uses one display object per thread)

Alexandre didn't like the part about using different message queues and asked for more detail concerning wintab. Robert replied with a lengthy email on exactly what he's doing:

That's what I thought, and I have proof of concept patch that hack the x11drv code to insert & read XInput events from wine's X11 event loop.

Unfortunately this doesn't fit well with the way wintab works. So, here's an explanation, why I've made these decisions. It's far longer than I'd wish, but the issues involved in the design are complex.

So here goes......

Quick recap of what wintab does The wintab dll will takes messages from a graphics tablet, and provides them to the user. But isn't that what a mouse does? A mouse provides information on the X & Y screen coords, and buttons pressed. A tablet provides all the above, plus extra axes defining the tilt of a pen, the pen's pressure, rotation of a mouse, (and possibly more). All this can be provided at resoloutions much higher than screen resoloution.

The XInput side of the implementation

The official way to get tablet data for an X display is to use the XInput extension.

The XInput extension defines a specialised set of event classes to represent tablet data, which enter the normal X11 message queue. These messages are initially disabled. XInput provides a function to enable them for a given display and window.

OK, So far it looks as if the XInput messages could be injected into the wintab messaging system. But note that this would reqire some patching to the x11drv dll to do the following

  1. decode the messages.
  2. enable the messages for a given window and display.

But I'm assuming that changing the x11drv code could cause severe regressions to wine. I'm therefore assuming that it's good manners to avoid fiddling with x11drv code till the wintab driver implementation is known to be adequate.

The wintab side of the implementation

To access tablet, a "tablet context" is created that maps a window to a particular tablet device.

For each tablet context the application is given a separate tablet message queue, which provides 2 ways to access the tablet message queue.

  1. A set of functions that get or peek, or otherwise interrogate the message queue for queue size, message at index etc.
  2. Posting messages into the windows(wine) message queue.

To complicate matters, it appears that it's possible to use both methods in the same program.

At present, I will only implement method a. as this is the one used by Painter5 and Photoshop6.

Now, as it turns out, the methods to interrogate a wintab message queue are extremely similar to those to interrogate an X11 message queue. So that's +1 to giving wintab it's own X11 message queue. (Or possibly even one X11 msg queue per tablet context!). A simple X11<->wintab mapping can be implemented, and no additional queue data structs are needed in the wintab implementation. As the wintab dll implements it's own message queue, an implementation using the wine message queue would give a number of problems:

  1. All wintab messages would have to be hidden from the application's windows(wine) message queue. Could be done with one specific thread, or threads for wintab. This becomes similar, but more complicated to the X11 message queue implementation.

  2. Filtering methods would have to be implemented to only access the messages appropriate to the reqired tablet context. X11 provides all the filtering necessary. While windows provides enough filtering for ranges of messages. But this would mean 3 message mappings X11->windows(wine)->wintab.

  3. All the queue management functions, and any necessary data structs to manage the queue will have to be implemented specifically in wintab, as the windows queue doesn't give much control over the message queue, and what's more, may need to copy data into a wintab specific message queue before the application can access it.

I think after all that complexity, that's +4 or more to X11 message queue implementation, and for wintab at least, avoid the wine message queue.

Well, that's the end of my whistle stop tour of the issues I've been cosidering with this part of the design. I've omitted any reference to function names, to keep this document as breif and readable as possible. If you wish, I can annotate it with the relevant function names.

Please feel free to comment on anything.

And finally, Some references:

For the wintab spec see the following location:

For XInput see

Alexandre looked at the specs and suggested something slightly different and a little less complex:

I agree you probably don't want to store wintab events in the Windows message queue. But that doesn't mean you have to create your own X connection and event loop, you can simply retrieve the events from the normal X event loop and store them into the wintab queue.

Robert wasn't sure that was the correct approach:

[That] is initially how I was going to implement it.

The issue I came up against is how to inject the messages into the wintab queue?

In wine, messages are currently injected into the for each thread, when GetMessage() is called.

As wintab has it's own equivalent of GetMessage (named WTPacketsGet) the which seems to have direct access to the driver, it would look like wintab needs an alternative method to inject messages into it's queue.

The only one I could come up with, in wine style, was to have a worker thread whose sole purpose is to inject messages into the wintab message queue. It might call GetMessage(), but all this would do is cause the wine message loop to insert a message into the wintab loop.

The problem with this system is that it means that the queue has to be accessed by multiple threads, and therefore will lead to the usual thread synchronisation hassles.

It was the fact that I could avoid synchronisation which lead me to think about building my own message loop.

Robert also wanted everyone's thoughts on the separation of wintab - what parts needed to go into x11drv and what parts needed to go into wintab.dll. X11drv doesn't have many exposed interfaces, so Robert thought he was going to run into problems with that. The easy solution would be to just dump a lot of the new code into x11drv. He looked at how the DirectDraw code worked but Lionel Ulmer cautioned him not to use that as a guide. Ever.

3. Wintab Status and Development

22 Apr 2003 - 23 Apr 2003 (6 posts) Archive Link: "Wintab32 dll devlopment"

Topics:

People: Robert North, Aric Stewart, Mike Hearn, Jeremy White, CodeWeavers

Robert North wrote in to give a status update on the wintab32 (tablet support) implementation he's working on. The status update is in the Bugzilla database as bug #1160, but here is what he wrote:

Ok, I think it's time I give a status update on the progress of the wintab32 dll implementation:

What's been completed

  1. Investingation into how Photoshop 6 & Painter 5 use the wintab dll in Win98. I now have a dll that can replace wintab & log calls to wintab functions, with some parameters. It can also log the sending/posting of windows messages in the range used by wintab.

    • I have gathered enough data to understand what to implement for Photoshop & Painter.

  2. Design of the wine wintab implementation. I now have enough design to start implementing. The design isn't complete, but should take me through to getting enough features working for Painter & Photoshop. The design doesn't go deep enough to suit needs of CAD programs, but as I don't posess any programs of this type I can't really progress any further here.

  3. Implementation of wine wintab. I've been concentrating on the WTInfo function. This is a swiss army knife of a function, for accessing all kinds of information about wintab devices.
    • All the data structures to store info about devices, and cursors are implemented. These data structures extend the basic support for WTInfo to store private information to allow interaction of the wintab dll with XInput. Most of the code to fill these structures from XInput is completed. The WTInfo support is 90% implemented.

Immediate to dos

  1. Finish WTInfo support. (Will have gaps in some areas not required by Painter or Photoshop)

  2. Implement a wintab context, and enough functions for Painter & Photoshop to configure it. The wintab context is a handle to the communication channel between the application and the wintab device.

  3. Start reading tablet packets from the wintab context.
  4. Transform the coords in accordance with the data in the wintab context.
  5. Use some form of config file to define the mapping from XInput devices to wintab devices.

Long term to dos These are tasks I may not be able to spare the time for, or for which I don't have anything to test.

  1. Look at z-order issues for wintab contexts. Wintab contexts have a z-order that appears to be independant of window z-order. This will need further investigation, to find out how to map to XInput concepts.
  2. Look at the WTMgr functions: These manage the tablet devices. Is there any need for these? I'm assuming that the native OS has adequate tools to manage tablets for now.

Robert's post to wine-devel also included a bunch of questions including, " I heard somewhere that Crossover office had a tablet implementation. Does anyone know about this, and who to contact to find out more? If they've got an implementation of wintab, I wonder if it's worth continuing the development."

Aric Stewart replied:

I did a Wintab32 implementation for CrossOver Office 2.0. I will create a patch for winehq and submit it later today. If you want to continue to work off of that you are welcome to. It may be best not to duplicate work too much.

My development was specifically for the wacom intuos tablet. I tried hard to make it general enough to incorporate anything using wintab32.dll but if you have other devices that would be great.

About an hour later Aric posted a patch with CodeWeavers wintab32 implementation. That prompted Mike Hearn to ask:

This is a very large amount of code, it's slightly concerning to me that apparently nothing was said about this before despite the fact that Robert North said he was working on it.

Is it CodeWeavers policy not to reveal what new features are being added until the code is merged? In particular, I'm now left wondering whether or not the system tray in CX Office has XEMBED support (as this bug is highly user visible for non-kde users, so it might have been a candidate for a fix) - at some point once I've finished my current project and resolved a few ActiveX painting bugs I'm going to try and implement XEMBED support for the system tray, but I don't want to waste my time if it's already been implemented by CodeWeavers.

Jeremy White replied:

No, our policy is not to be particularly secretive; we particularly don't want to waste anyones time, ever. There is so much to do that any inefficiency is anathema to us.

We just goofed.

In fact, Alexandre often goes out of his way to spot cases where someone is working on something we're also working on, and tries to make sure that there is no wasted effort. You can use the NPTL work as one example, and there were also some critical Photoshop install bugs that were fixed in WineHQ because Alexandre noticed someone needed them.

Also, we did discuss Rob's work before Aric started on Wintab. We noted he'd said he was working on it, but we hadn't seen any patches or heard anything further (afair, his last email was November), so we assumed he hadn't had time.

The rude thing we did was failed to send an email to Rob with a heads up/gut check with him on the status. If it helps, Aric feels terrible about it.

Now, I will say, we do like to hold our development tree separate while we're working on it. This is in part just so we can stabilize around a release, but it's also in part so we can get a big 'publicity' splash around new features.

I know that Chris poked at the system tray support, but didn't get very far, and we pulled him to attacking other things in the hopes that Mike Hearn would get the XEMBED support done...

Candidly, we often see other peoples work and think 'ooooh, I hope we can get that into CrossOver X.X', but we feel that it would be rude to tell you to hurry up and get XEMBED done so we can ship 2.1 <grin>.

I do have to admit that I think we've done a pretty poor job of interacting with wine-devel, sometimes. We just had a big discussion on IRC about it.

We're reluctant to do our development 'in the open' (i.e. submit our patches as we work on them).

I should be clear - the developers are cheerful to do that, but Management is not comfortable. We really do live and die by our CrossOver Sales; we're just barely making enough money to keep doing what we're doing (and some months, not even that), and we worry that if WineHQ starts having all of our 'good stuff' before we can make a splash with it, it will harm us. It nearly happened to us just now; ELX Linux announced Photoshop 7 support before cxoffice 2.0 (luckily they didn't get much press).

Also, we're really not all that secretive. We've been telling pretty much anyone who wants to know that we were working on Photoshop, Access, and Office XP. Next is the Macromedia stuff... We're small, so we do change direction when a paying customer waves money at us, but we try to be pretty open. Just ask <grin>

We're debating now how to do better. And we're open to suggestions. Ideas?

In fact, I'd like to know if there are more simmering complaints out there. If there is anything else we've done that pissed someone off, but they were too polite to mention it, let us know.

I'd rather we intentionally pissed people off than did it by accident <grin>.

Robert understood where Jeremy was coming from, but felt more communication would benefit everyone:

I think the rule should be that if someone says they're working on something then anyone who wants to work on the same area should contact them. This is a rule everyone should keep in mind, not just Codeweaver employees.

Maybe you should consider approaching developers who are working on things close to you commercial interests, and see if you can work together for mutual benefit.

Now back to thinking about how to integrate what I've done with Aric's code.

4. Wintab Status

17 Jun 2003 - 19 Jun 2003 (5 posts) Archive Link: "Wintab: beginning to investigate Aric's patch from April."

Topics: Status Updates

People: Rob North, Aric Stewart, Robert North, Mike Hearn, Lionel Ulmer

Rob North decided to revisit support for tablets. We last covered this topic back in issue #167. Rob wanted to know if anyone else had worked on it recently:

Ok, I've just managed to start looking into Aric's Wintab32 patch from April 23rd.

I've been extremely busy (more so than I expected) since then, on a small Java contract. So I've missed my goal of looking into Aric's code in 3 weeks. (Apologies Aric)

But anyway, I'm starting to look into it.

The first thing I'm seeing is a crash in the WTInfo() wintab call with Painter 5. Will look into this further, and attempt to fix.

Aric: Ever had this? I'll investigate further before posting up any significant details, as I suspect the fix is trivial.

Infact, has anyone else looked into this patch?

I haven't looked any further into Aric's other problems with Painter, as this WTInfo() error prevents Painter from even starting!

More importantly, I'd like to know why it didn't make it into the CVS? Did the patch slip behind the filing cabinet (as they do ;-)? Or was there a more substantive reason to reject the patch? I think Mike Hearn mentioned something about it's size (v. large)? Aric, Alexandre: do you want me to want me to re-subimt the patch, once I've got WTInfo() working?

I've also noticed that it doesn't update Wine's autoconf file to look for the XInput X extension, as is done to support other dlls that use X extensions. I assume this should be added.

Just to touch base with Aric: Has anyone done any more work in Code Weavers on this?

Aric thought Rob should take care of submitting something:

I think we where waiting on you. :) I did not formally commit it to wine-patches because i wanted to get your input first.

If you are planing to expand on my patch, then i would say Alexandre should could commit my patch then you work from there. Whatever is easiest for you.

Rob then took a look at the code Aric had submitted a few months and noticed some problems:

Ok, I've done some preliminary testing, and fixed obvious bugs that have arisen.

What I found, and could fix:

  • Sometimes a badly configured tablet can generate X errors on the XOpenDevice method. Fixed by ensuring tablet driver was functional. I don't know if the errors need to be caught, or not, but I think they were causing crashes. This is probably related to synchonous/asynchonous X modes.

  • In Photoshop, an infinite loop in method FindOpenContext when attepting to traverse the wintab context chain.

  • In Painter, a number of methods didn't handle NULL prameters properly, resulting in various crashes. Wintab uses NULL paramters to signify a query for size of available data, or to signify a request to flush the Wintab packet queue.

Aric, I'm wondering if I should really be fixing these things, as these look like the kind of bugs Code Weavers will have fixed in the normal course of product support.

After fixing these issues, The following remain:

  1. Photoshop doesn't seem to respond to pressure.
  2. Painter receives wintab events, but coordinates are extreme: only see lines from one side of drawing to another.
  3. Maybe some further research into the errors from XOpenDevice. I'm not convinced it is a problem.

Aric, are these the kind of bugs you were seeing with Painter?

I'm suspicious of the Wintab packet building code, as it has to build a C data struct on the fly. Looking at the code though, I can't see anything that could be going wrong. It could also be a scaling issue, where the scales deduced from X are wrong (I remember being suspicious of some of the values returned by the wacom driver).

I've got tons of trace code that runs as a wrapper round wintab on win98, and will move some of this into the wine impl for more testing. I hope this will help solve the remaining bugs.

I think in the light of the crashing bugs, Aric's patch shouldn't go in as-is.

Lionel Ulmer gave a pointer to the DGA2 code as an example of catching X errors. Aric was surprised Rob had uncovered those issues. He gave a pointer to a program to make sure the tablet and X were set up properly:

The first thing you need to do is make sure that your tablet is working under X. There is a great little program called xinput, it is a utility that test the XInput module. You can see all the axis of your device and make sure they are working. I found that to get XInput to recognize pressure from my wacom tablet i needed to run the latest wacom drivers from http://linuxwacom.sourceforge.net/index.php/main.

you can download xinput from

1. Wintab Status

10 Feb 2005 (1 post) Archive Link: "The status of the wintab dll"

Topics: Status Updates

People: Robert North, Unknown

Robert North posted a bunch of patches a few weeks ago to improve Wine's tablet support. This week he wrote to give and update about what works, what doesn't, and what areas people could work on:

I think after the 10 or more patches to the Wintab dll that I submitted last month, I should say something about it's status... And of course thank Alexandre for applying those patches.

Applications: Current status

  • In Painter 5
    • o Cursor pressure works. (Therefore is usable by most) o Cursor orientation is a little odd: The orientation maths needs to be re-done. o No eraser. Haven't yet cracked what enables the eraser. o Doesn't work in desktop mode: Need to map to desktop coordinates.

      o Repeats windows bugs where cursor looses pressure/orientation info almost bug for bug (Is this a feature? ;-) o Cannot detect pressure/orientation int the "Brush Tracking" window: The tablet context is attached to the main window, so no events get to the popup, even if they overlap. This is not how windows wintab functions.

  • In Photoshop 6
    • o Can only get tablet data in desktop mode: This is because the tablet context is attached to the desktop. Which generates/receives no wine events outside desktop mode.

      o Eraser and pen pressure working. *But* to get them working, you must have 3 XInput devices listed in your XF86Config file, They need to be the last entries in the "ServerLayout" section and the following order: eraser, tablet mouse. This is a far from ideal way of specifying the devices Wintab should use :-/ I'll document this if someone can point me to a good place to put the docs.

To Do

  1. Look at X11 errors. There appear to be some errors that deny some users the ability to access Wintab enabled apps. (I think I know how to fix this)
  2. Improve orientation data. Orientation comes in as X-Y coords (Implicit Z), and has to leave as spherical coords. This calculation needs to be re-done.
  3. When tablet context is on top, let it read XInput events from all the app's top-level windows. (This simulates the fact that the context is usually designed to cover the whole screen)
  4. When tablet context is attached to desktop, read XInput events from all the app's top-level windows.
  5. Tests

    • --My current philosophy on tests is... Use Photoshop & Painter, any formal tests can be written if anyone else gets involved in patching Wintab, to avoid regressions, and conflict.

Long term to do (Anyone interested?)

There's a lot of work that could be done here, but what gets done and who does it probably depends upon whether anyone finds an app that needs these features. I'd love to implement these, but realistically, I don't foresee doing this unless someone hires me to do so ;)

  1. Improve configuration of wintab.
    • Wintab could probably do with some information entered into the config file, to avoid the user having to hack their Xfree86cfg file.
  2. Handle Z-Order of context properly. This entails
    • sharing Z-Order between apps.
    • Working out exactly what role windows have in determining tablet context z-orders.
    • Allow tablet contexts that don't cover the whole screen/tablet.
    • Handle inter-application clipping of tablet contexts
    • Allow all application's windows to receive tablet events when tablet context is on top
  3. Implement non-system tablet contexts (Where system cursor not moved by pen or mouse)
  4. Unicodify
  5. Implement various wintab extensions.
  6. Implement wintab manager functions.
  7. Tests.

Unknowns

  1. How are wintab contexts are raised lowered? Contexts have their own z-order independent of windows, and their own viewport concept, based upon the tablet's coordinate system, not that of the OS. It appears that entering, or clicking on the window the tablet context is attached to will raise/lower the context. But I haven't done much testing on this. In particular, what happens if more than one app request their tablet context is attached to the desktop?
  2. How Painter detects the eraser. Have 3 possibilities
    1. Windows can detect an eraser, and sends specific messages. (I'm sure I've seen this, but can't work out where!)
    2. Only works if tablet and cursors are named correctly. (Probably linked to wacom tablets only).
    3. I've missed something
  3. Requirements of other applications

TabletSupport (last edited 2011-06-20 22:27:53 by AndreHentschel)