Fix WinTab coordinates offset on some tablets
ClosedPublic

Authored by alvinhochun on Feb 20 2018, 3:46 PM.

Details

Summary

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.

Test Plan

Test with tablets that have non-zero lc.lcInOrgX or lc.lcInOrgY. Compare the behaviour before and after this patch. (I don't have one to test.)

Diff Detail

Repository
R37 Krita
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
alvinhochun requested review of this revision.Feb 20 2018, 3:46 PM
alvinhochun created this revision.
alvinhochun retitled this revision from (WIP) Attempt to fix WinTab coordinates calculation that seems to be incorrect to Fix WinTab coordinates offset on some tablets.
alvinhochun edited the summary of this revision. (Show Details)
alvinhochun edited the test plan for this revision. (Show Details)
This comment was removed by alvinhochun.

I'll try to check the logics of the patch a bit later

dkazakov accepted this revision.Mar 1 2018, 6:16 PM

Hi, @alvinhochun!

I have tested your patch on my setup and I can tell that it changes nothing for me :) It might be that we don't use these custom lcOut{Org,Ext}{X,Y} values anywhere and do the conversion manually. Though I'm not sure.

What I tested:

  1. Created a complicated setup: two displays FullHD+HiDPI extending each other
  2. When the tablet mapped to any portion of FullHD display, everything works fine.
  3. When the tablet is mapped to any portion of a HiDPI display, Krita complains that Qt's and Wintab numbers differs. Pressure doesn't work, and there is a small offset between the cursor and the tablet position (when selecting Wintab's version of numbers).
  4. Krita 3.1.x maps fine to that HiDPI display, so it is a regression in 4.0.

All the points listed apply to both versions of Krita: with and without this patch, so I guess it should be safe to push it.

This revision is now accepted and ready to land.Mar 1 2018, 6:16 PM
This revision was automatically updated to reflect the committed changes.