Wintab dll: Status report.
7ownq0k402 at sneakemail.com
Fri Jun 20 10:51:42 CDT 2003
Aric Stewart aric-at-codeweavers.com |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
>> 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 http://linuxwacom.sourceforge.net/index.php/main.
> 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
> 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