Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move mouse to wrong location on multiple monitor #631

Open
1 of 3 tasks
vietanhtwdk opened this issue Dec 24, 2023 · 2 comments
Open
1 of 3 tasks

Move mouse to wrong location on multiple monitor #631

vietanhtwdk opened this issue Dec 24, 2023 · 2 comments

Comments

@vietanhtwdk
Copy link

  • 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:
    • 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
...

@andrewfstratton
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants