Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: Mouse.MoveTo()

  1. #1
    Senior Member
    Join Date
    Oct 2015
    Posts
    227

    Mouse.MoveTo()

    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?

  2. #2
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,766
    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

  3. #3
    Senior Member
    Join Date
    Oct 2015
    Posts
    227
    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?

  4. #4
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    2,766
    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

  5. #5
    Senior Member
    Join Date
    Oct 2015
    Posts
    227
    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.

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,511
    Quote Originally Posted by tonton81 View Post
    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....

  7. #7
    Senior Member
    Join Date
    Oct 2015
    Posts
    227
    Wow, I had no idea implementing the Mouse was so complex!!

    Thanks for sharing that Paul.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •