Wintab dll: Status report.

Robert North 7ownq0k402 at
Fri Jun 20 10:51:42 CDT 2003

Aric Stewart |Wine Mailing Lists| wrote:
> Interesting. Since I had myself as well as at lest 3 other organizations 
> of testers testing this code at each step with Photoshop6 and 7 and 
> Painter 7 as well as a number of test applications. None of us saw these 
> problems.
>> 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.
> Was XOpenDevice returning a device but also creating errors? That seems 
> really counter intuitive since it is only suppose to return the device 
> if it succeeds. However I am not much of a x11 programmer.
> When this error occurred where was the crash? probably at some point 
> where I am gathering the tablet information. It would be good to find 
> that line and fix it there also.

I will have to re-produce the error first.
That could be difficult: hardware in linux tends to work very well, or
very badly. My tablet is currently working very well.
I could have confused the crash from one of the null pointer errors,
so I'm beginning to suspect this could have been a red herring.

>>     In Photoshop, an infinite loop in method FindOpenContext
>>     when attepting to traverse the wintab context chain.
> Something is going seriously wrong here if there is an infinite loop. 
> The contexts should be a linked list so someone's next is pointing to 
> something previous in the list. WHen i did photoshop it created only 2 
> contexts (and only did anything with 1 of them) both where contexts to 
> the root window.
> Where is this loop being created?

It's actually pretty clear from the code:
The following referes to the "context.c" file....

in fuction TABLET_FindOpenContext, line 129 is:
         ptr = ptr->next;

in function FindOpenContext there should be an equivalent
line, after line 175.

If you still want more information about then this occurs, I can provide it.

>>     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.
> Which methods? I thought that i had handled all the cases i had seen 
> used this way.

WTInfoA, fails for standard wCategory, or nIndex values if
lpOutput == NULL.
Fixed by modifying CopyTabletData to suppress memcpy if
target == NULL.

WTPacketsGet,WTPacket,WTPacketsPeek,WTDataGet will all fail when passed
a NULL lpPkts.
I've only really fixed this for WTPacketsGet,as this was the only one
where it caused crashes/
Also another bug I neglected to mention what that many of these
functions flush the buffer using memcpy, to copy overlaping

>> 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.
> Like I said, We saw none of these problems. It was working wonderfully 
> for me, and all our tester and customers. So if you need to fix things 
> for your tablet then you should fix them because I cannot reproduce it 
> here at all.

In that case, I wonder if it could be due to different compiler/library 
versions, and static vs. dynamic linking?

> 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
> you can download xinput from 

My tablet works fine with Gimp.
I'll have a look at the latest wacom drivers, and at the XInput
I'll run the test program as a sanity check.
Infact.... the XInput extension could be what's causing the
scaling to go funny. When I said I was suspicous of the scaling
data from the wacom driver, I really meant XInput. I've been
avoiding patching XInput dll so far.

>> Aric, are these the kind of bugs you were seeing with Painter?
> no actually, the problem I was seeing was a race condition inside 
> painter with the button/pressure testing code. Such that after you 
> lifted the stylus painter would still think that the stylus was in 
> contact with the pad and keep drawing.

Ok, So not there yet :-(

>> 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).
> This i tested alot with my own test programs and it seemed to be working 
> quite well.
>> I think in the light of the crashing bugs, Aric's patch shouldn't
>> go in as-is.
>> If people want, I could post up a patch with the fixes I've added so
>> far.
> I would like to see more details about where you are having these 
> problems and how you fix them as I may be able to continue to help out.

I think it might be easist for me to post a patch that includes the fixes.
The fixes are pretty simple, really. V.easy to spot with a diff against
you original patch.


More information about the wine-devel mailing list