Fix incorrect touch point coordinates when running application on secondary screen with WM_Pointer enabled

[lindexi]

Fixes #8517

Main PR

Description

In the GetOriginOffsetsLogical method, the expected behavior is to return coordinates relative to the current screen. However, due to Windows' mechanism, when operating on a non-primary screen, the method returns coordinates relative to the primary screen. This leads to issue #8517. The fix involves subtracting the Left and Top values of displayRect during the calculation, ensuring that the resulting coordinates are relative to the current screen rather than the primary screen, thereby resolving the touch offset problem.

Customer Impact

Fix the bug.

Regression

Testing

The dotnet-campus#9 was tested for two years in many my users device. And this PR is pick from dotnet-campus#9

Risk

Low. For the vast majority of users, this has no impact. Most users have only a single touchscreen, in which case the displayRect's Left and Top values are both zero. This means that point.x - displayRect.left and point.y - displayRect.top will not alter the x and y values of the point.

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull Request Overview

This PR fixes an issue where touch point coordinates were incorrect when running a WPF application on a secondary screen with WM_Pointer enabled. The problem occurred because coordinates were being calculated relative to the primary screen instead of the current screen.

Key changes:

• Modified the GetOriginOffsetsLogical method to calculate coordinates relative to the current screen
• Replaced direct PointToScreen call with manual coordinate calculation using ClientToScreen and display rectangle offsets
• Added proper handling for multi-screen scenarios by subtracting display rectangle offsets

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}