The status of the wintab dll

[Jeremy White]

Hi Folks,

Okay, I've now spent some time putting some love into wintab.dll,
and I've now gotten to the point where Photoshop 7 works properly,
no matter what order your X devices are in.

I've also improved behavior of a number of other test programs
I worked with as I struggled with Photoshop.

But now I'm done, because Photoshop tilt + pressure work again.  (Yay!)

I thought I'd reprise my current understanding for future posterity.

First, there are 2 immediate changes that are clearly appropriate to make:

  1.  We should strip out devices like mice and such.

      Otherwise, anyone with more than 1 mouse is going to appear to
      have a tablet with 1 cursor.  A simple exclusion of devices without
      'Wacom' or stylus/cursor/eraser in either their name or type should suffice.


  2.  The following commit, I believe, is wrong:

      commit ee2db299deb19c76a5ff9a5338b3640b490494e4
      Author: Mikolaj Zalewski <mikolajz at google.com>
      Date:   Thu Aug 30 12:41:37 2007 -0700

          winex11.drv: wintab: Copy also the button #0 state.

      That is, in X, our devices come out as 1 based (not 0 based), and
      on Windows, they report as 0 based.  iow, with this patch, pkButtons is always 2;
      on Windows, it's always 1.

      But no app I've seen so far really cares, and I don't feel that
      I know enough to really assert what the 'right' implementation is.

      The truth is, the whole logic around pkButtons and BUTTONMAP and so on is
      clearly not fully implemented; we don't do the weird magical thing with
      relative positioning reports, for example.


Finally, from a 'big picture' perspective, wintab.dll could really use some
serious love.  Further, it's a fairly straight forward process.  This would
make a really good beginner project.  You just need a tablet, mostly.

I think the appropriate next step is for someone to write a comprehensive
tablet test utility, to run both on Windows and to compare under Wine.

That's the next step imho.

I'm going into Robert's status to note what I think has changed.

> 
> ***In Painter 5
> *Cursor pressure works. (Therefore is usable by most)
> *Cursor orientation is a little odd: The orientation maths needs to be
> re-done.

  Unchanged.

> *No eraser. Haven't yet cracked what enables the eraser.

  Should be fixed.

> *Doesn't work in desktop mode: Need to map to desktop coordinates.
> *Repeats windows bugs where cursor looses pressure/orientation info
> almost bug for bug (Is this a feature? ;-)
> *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.
> *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.
> * 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.

  This should be fixed.
> 
> *******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.

  I disagree; I think a test application is the clear next step.
Too much is done by trial + error, and some rigor is the next step imho.

> 
> **********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

  Done, I think.

> 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
>     i. Windows can detect an eraser, and sends specific messages.
>         (I'm sure I've seen this, but can't work out where!)
>     ii. Only works if tablet and cursors are named correctly.
>         (Probably linked to wacom tablets only).
>     iii. I've missed something

   It's all the cursor number; 0 is 'puck', 1 is 'stylus', and 2 is 'eraser'.
> 
> 3. Requirements of other applications


Cheers,

Jeremy