Change Details

When I read part of the WinTab docs (http://www.wacomeng.com/windows/docs/Wintab_v140.htm) and tried some Wacom demo source codes, it looks like there might be something wrong with the current WinTab coordinates calculation code. I'm not sure though. It's a bit confusing. I'll have to leave it alone for a day or two before checking again. Please ignore the messy commented code, I'll tidy it up later.

When I read part of the WinTab docs (http://www.wacomeng.com/windows/docs/Wintab_v140.htm) and tried some Wacom demo source codes, it looks like there might be something wrong with the current WinTab coordinates calculation code. In `QWindowsTabletSupport::create`, it opens the default tablet context `WTI_DEFSYSCTX` with `lcOut**` set to the optimal dimension with origin at (0, 0). With these options set, WinTab will transform the tablet input coordinates into the area specified. Then in `QWindowsTabletSupport::tabletInit`, it obtains the existing context options in `lc`. For some reason, the original code gets another default context `WTI_DEFCONTEXT` and assigns `result` using the input dimensions. This seems incorrect. If the input dimensions does not have an origin of (0, 0), it will cause an offset in the transformed tablet coordinates. This patch should fix the coordinates offset.

When I read part of the WinTab docs (http://www.wacomeng.com/windows/docs/Wintab_v140.htm) and tried some Wacom demo source codes, it looks like there might be something wrong with the current WinTab coordinates calculation code. I'm not sure though.n `QWindowsTabletSupport::create`, it opens the default tablet context `WTI_DEFSYSCTX` with `lcOut**` set to the optimal dimension with origin at (0, 0). With these options set, WinTab will transform the tablet input coordinates into the area specified. Then in `QWindowsTabletSupport::tabletInit`, it obtains the existing context options in `lc`. For some reason, the original code gets another default context `WTI_DEFCONTEXT` and assigns `result` using the input dimensions. This seems incorrect. If the input dimensions does not have an origin of (0, It's a bit confusing.0), I'll have to leave it alone for a day or two before checking againit will cause an offset in the transformed tablet coordinates. Please ignore the messy commented code, I'll tidy it up laterThis patch should fix the coordinates offset.