Mouse.MoveTo()

Status
Not open for further replies.

rfresh737

Well-known member
I'm getting some unreliable behavior using Mouse.MoveTo().

I have two monitors on my Win10 PC. I have two encoders wired up to increment/decrement mouseX and mouseY vars. The encoders are working to ++ and -- the vars as designed. Serial output also verifies that mouseX and mouseY vars contain valid values.

But as I turn the encoder to move in the X axis, the mouse pointer doesn't always move.

Sometimes the pointer ends up on the primary monitor and other times it ends up on the secondary monitor.

I'm starting with mouseX=0 and mouseY=0 and the mouse pointer does go to that position to start on monitor two.

Can I force Mouse.MoveTo() to use the primary monitor only?
 
check your monitor settings in desktop, often times primary/secondary doesnt mean right and left. your primary could be the second monitor in windows, check your display settings page for info
 
I checked and my right side monitor is #1 and the left side is #2.

I've got it working now but I am not sure what I did is a real fix.

I was setting the mouseX and mouseY to 0,0 in Setup. I saw that Y actually starts at point 124 which puts the mouse cursor at the very top of the screen (I have it light BG color so I can see where the edge is).

mouseX = 0 starts at the left edge as you would expect. But to actually position it to 0,0 I have to use 0, 124. Why would that be necessary for the Y axis?

I added a var called mouseYBias = 124 and so now I am using this to position to where I want:

Code:
Mouse.moveTo(mouseX, mouseY + mouseYBias);

The last question I have is this: when I run the mouse cursor all the way to the right edge, the mouseX counter ends up with a value of 954 but the screen resolution is 1920 wide (by 1080 high). So there is not a one-to-one for pixel mouse move to screen pixel?
 
my theory is the mouse in teensy MoveTo uses absolute positioning in single monitor use. To assign the pointer accross a field of 2+ monitors you can't really assign absolute positions

a regular mouse doesnt use absolute positioning, rather it goes where its currently from up down left or right

You would have to calibrate the positions to your setup i would imagine, find the min/max corrdinated of both monitors, and use that position data in your code
Note that re-adjusting the monitor setup in windows would require you to recalibrate again
 
I'm developing on two monitors but the sketch will run on a 10 inch win10 tablet. I switched to one monitor on my development PC and the mouse is working better...so I guess it is not designed to work with more than monitor.

Thank you everyone.
 
my theory is the mouse in teensy MoveTo uses absolute positioning in single monitor use.

That's pretty close. But HID protocol doesn't have any distinction between single vs multiple montors. Or at least it doesn't as far as I know.

Technically speaking, the HID mouse is a top level collection of "generic desktop" usage page (1) and "mouse" usage (2). Within the application collection, the movement data is transmitted as "generic desktop" (1) usage page and "X" and "Y" usage (48 and 49). The mouse is implemented with 2 different report IDs. When you use Mouse.move(), the movement data is sent with a report using "Input relative" (0x06). When you use Mouse.moveTo(), the position data is send using "Input absolute" (0x02).

The reality of HID protocol is we get a huge number of defined usage page & usage numbers. They're defined in this document.

http://www.usb.org/developers/hidpage/Hut1_12v2.pdf

Everything we send to the USB host using HID has to be within a "collection" identified by a usage page & usage number. Within that collection, we can send any number of data items, which also have to be identified by a usage page & usage number. We also get to use 9 different single-bit flags to say what type of format the actual data uses. The 9 bits are defined on pages 30-31 (40th page in the PDF) of the HID spec:

http://www.usb.org/developers/hidpage/HID1_11.pdf

Those 4 usage page & usage numbers and 9 bit flags in the report descriptor determine how the PC (or Mac or Andriod or whatever the USB host is) will intepret the data.

If you read these specs, you'll see stuff about physical descriptors and collections within collections. As far as I know, no operating system uses the physical descriptors. I believe they all look at only the top level collection info and ignore sub-collections. At least that's what Microsoft does, and I'm pretty sure the others do too.

Then again, I could be wrong. Maybe there is some way to structure HID reports with intended screen info? If so, I'd serious consider supporting it in future Teensyduino versions. But this really depends on how Windows and other systems interpret the HID usage numbers and those 9 bits....
 
Status
Not open for further replies.
Back
Top