I don't think getting both monitors with touch is possible. At least this code base appears to be a ways off from handling it. I had this funny scaing problem as well.... and I just made a fix that got touch to work on my primary monitor while the
secondary was enabled. You are close to the point where I had to make the fix. I changed that code to
ushort MaxSize = 32767;
double fontSize = 1.25;
double XRatio = (SystemParameters.PrimaryScreenWidth
* fontSize) / MaxSize;
double YRatio = (SystemParameters.
PrimaryScreenHeight * fontSize) / MaxSize;
This fixed the scale problem due to the fact that the VirtualScreenSize is the width of both monitors... but the driver (Win7) seems to be limited to providing touch coordinates onto a single monitor so I figured it should only be scaling to the width of
the primary monitor. The other problem I hit was that I run with 'large fonts'... or more accurately the default zoom level to 125%. I have not figured out how to programmatically obtain thius setting so I just hardcoded it for now.
Set this back to 1.0 if you run with small fonts. I'll try to figure out how to set this programatically.
Note that the MultiMouse input provider has some improper constraining for multi-monitor as well. In the RawDevicesManager.cs UpdateMouse... it incorrectly constrains the limits. The code as is would constrain the touch point to the primary monitor
located on the right. It would allow touch points (red dots) to go onto the secondary monitory if it was on the right (primary on left). By checking for virtualScreen.Left/Top rather than zero you can get it so that touch points get generated across
the whole VirtualScreen (all monitors). But even after doing this the Win7 side of things contstrains the touch points it generates to the primary monitor. The proper thing is probably to constrain the points in MultiMouse to the primary
screen so it needs a fix for the case where the primary monitor is on the left.
Note that I'm using the 29484 build. On the later builds I was having a problem where the offsets within child windows were off... but it could be that I was in a bad state while searching for a fix to the scaling issue. I'll update to the latest
build, apply my patch... and report if I find any problems.