robotgo icon indicating copy to clipboard operation
robotgo copied to clipboard

Move mouse to wrong location on multiple monitor

Open vietanhtwdk opened this issue 1 year ago • 3 comments

  • 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

image ...

vietanhtwdk avatar Dec 24 '23 11:12 vietanhtwdk

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 avatar Jan 09 '24 16:01 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.

andrewfstratton avatar Jan 09 '24 16:01 andrewfstratton