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

[Enhancement] USB HID Mouse should support scroll wheel and absolute moveTo() #1096

Closed
ScruffR opened this issue Aug 17, 2016 · 6 comments

Comments

@ScruffR
Copy link
Contributor

commented Aug 17, 2016

Nowadays USB mice should definetly also support the scroll wheel (z coordinate) and if possible also implement an absolute mouse movement moveTo() like Paul Stoffregen has done on his Teensy boards.

https://www.pjrc.com/teensy/td_mouse.html
https://forum.pjrc.com/attachment.php?attachmentid=942&d=1379523560

@ScruffR ScruffR changed the title [Enhaxement] USB HID Mouse should support scroll wheel and absolute moveTo() [Enhancement] USB HID Mouse should support scroll wheel and absolute moveTo() Aug 17, 2016

@ScruffR ScruffR referenced this issue Aug 17, 2016
6 of 7 tasks complete
@avtolstoy

This comment has been minimized.

Copy link
Member

commented Aug 17, 2016

@ScruffR Mouse wheel is already supported, it's the third argument to move(): https://github.com/spark/firmware/blob/develop/wiring/inc/spark_wiring_usbmouse.h#L59

In general, Mouse has the following capabilities:

  • 3 buttons
  • X, Y
  • Wheel

We could totally make a separate wheel() function to simplify the usage.

As for absolute screen coordinates support, perhaps it's a good candidate to be implemented as a library?

@technobly

This comment has been minimized.

Copy link
Member

commented Aug 17, 2016

what happens when you call Mouse.move() and just want to move the scroll wheel? Do you have to remember the last x,y and call as Mouse.move(savedX, SavedY, newWheel)? Likewise for x,y only? That would be a nice enhancement to add moveTo() and wheel(), but if added to a library, the library would have to remember the last x,y or wheel to use the existing Mouse.move(x,y,wheel) command. Is there a way in the HID implementation to just send x,y or wheel commands? That would avoid needing to know the current x,y to send wheel only, or wheel to send x,y only. What if you just want to move the mouse on x or y separately as well? moveX, moveY, moveTo, wheel?

@avtolstoy

This comment has been minimized.

Copy link
Member

commented Aug 17, 2016

@technobly No need to save anything. If you only want to move x coordinate by 100, you call Mouse.move(100, 0, 0);, if only scroll the wheel Mouse.move(0, 0, 100);

@ScruffR

This comment has been minimized.

Copy link
Contributor Author

commented Aug 17, 2016

@avtolstoy, duh' sorry, for some reason I mistook the third parameter as button click 😊
But a seperate wheel() would still be good.

And moveTo() as seperate lib would be fine too.
Would this then just hide/overload the basic HID Mouse class?

@technobly, standard mouse movement is only relative and only int8_t and hence doesn't need to remember the current position of the mouse pointer (try connecting two mice to your computer ;-) - each won't know of the others movement but will still pick up where the other one left the pointer).

But moveTo() would have to send two int16_t as X/Y pair, so the descriptor would need to be different. I guess this makes one class a bit complicated.
I'm also not sure how this would work with a multi monitor setup where some screens get negative coordinates.

@technobly

This comment has been minimized.

Copy link
Member

commented Aug 17, 2016

I see... so if moveTo() is absolute, and move() is relative, would it also have to "zero" the coords by moving -MAX_X,-MAX_Y first before moving to the desired X,Y? That's not even worth creating a library for really... just a helper function that performs those two commands. Get enough of these helper functions though like Mouse.scroll(), Mouse.moveX() Mouse.moveY() and you'll have a nice little library.

@ScruffR

This comment has been minimized.

Copy link
Contributor Author

commented Aug 18, 2016

An actual absolute mouse HID would not first move the pointer to 0/0 and then move relative.
A HID like this is more like a touch screen or digitizer where the actual position of the finger/pen on the digitizer surface is directly translated to the respective coordinate in the screen.
You just need to provide the scale how the digitizer coordinates (0..65535/0..65535) corresponds to screen coordinates (0..1920/0..1080 or -3600..+3600/-2250..+2250).
The USB HID descriptor (and/or a dedicated setup report) would carry the scale information while the regular USB HID report would only carry the raw coordinates (AFAIK).

@avtolstoy avtolstoy self-assigned this Aug 30, 2016

@avtolstoy avtolstoy referenced this issue Sep 6, 2016
6 of 7 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.