Jump to:

HIDInput.cs, ~line 230. Mouse values seem to be coming from the hardware as deltas, which are then added to the current state to give you the current mouse position. Unfortunately, these values seem to immediately become wildly off, and then the (0,0) point of the cursor continues to move across the screen as you click.

So, http://www.opentk.com/doc/input hints that the Input class might be inappropriate for games where you need a mouse position.. but if the coordinates are so inaccurate, perhaps position should be removed from the API. Not 100% sure what the plan is on this, or how it performs on other platforms.

Solution for now is to avoid these input methods and instead use GameWindow.Mouse or one of the other mouse input methods that go through the CarbonGLNative.ProcessMouseEvent or other Carbon methods.

The MouseState.X and Y should be pulling their info from elsewhere. I don't really know what to do about this one, so I'll leave this issue open until someone more knowledgable comes by.

After going through the documentation multiple times, this is not actually a bug. The HID API returns values in the native coordinate system of the device, before the operating system has a chance to apply pointer ballistics. If a mouse sensor supports a resolution of 1600DPI, then the values reported by Mouse.GetState() will increase at this resolution even if the visible cursor operates at 96DPI. This is optimal for mouse control in games.

OpenTK 1.1.2 introduces a new API, Mouse.GetCursorState() to poll the state of the mouse cursor in the desktop coordinate system, after the application of pointer ballistics. This is optimal for mouse control in UIs.