Move mouse to wrong location on multiple monitor

[vietanhtwdk]

• Robotgo version (or commit ref):
• Go version: 1.20
• Gcc version: 13.1.0
• Operating system and bit: 11 64bit
• Resolution: 2560x1600 3440x1440
• Can you reproduce the bug at Examples:
  • [x] Yes (provide example code)
  • [ ] No
  • [ ] Not relevant
• Provide example code:

package main

import (
    "fmt"

    "github.com/go-vgo/robotgo"
)

func main() {
    robotgo.Move(0, 0)
    fmt.Println(robotgo.Location())
}

• Log gist:

Description

2560x1600 on left side 3440x1440 set as main display

...

[andrewfstratton]

Possibly related/relevant:

When you get the screen width and height - this is of all the monitors (the workspace?), e.g.

        width, height := robotgo.GetScreenSize()
        fmt.Println("width = ", width, "height = ", height)

Gives - for two monitors - main being 1920x1200 and second (on right) being 1920x1080

• width = 3840 height = 1200

N.B. Beware that (for me) the main display gives incorrect X/Y values if scaling is on :(

Currently any mouse relative movement on the second display has some very strange behaviour where the mouse jumps off to the extremes of the display/s, this seems to only happen when the coordinates are out of the main display range.

Question/possible solution:

• Would it be possible to have a single display option for windows so the main display will work properly?
• If not/also can the main display resolution (width/height) be returned instead of the whole workspace? This could allow some applications to workaround the problem.

Best wishes - Andy

[andrewfstratton]

Aha - the wierd relative movement behaviour seems to be down to scaling

This can be repeated (on windows) by changing the scaling to (say) 125%. The relative movement seems to add (not verified) the difference between the actual pixel width of all the displays, and the scaled pixels which shifts the position over every time a relative move is made.

So - there's something about scaling that isn't consistent - the workspace height/width calculation ignores scaling. possibly using the primary width as unscaled pixels but then applies the new coordinates with scaling being used, so shifts across a number of pixels every time.