-
Notifications
You must be signed in to change notification settings - Fork 950
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
Gamepad device events 2 #1969
Gamepad device events 2 #1969
Conversation
…indowing#804) * Initial implementation * Corrected RAWINPUT buffer sizing * Mostly complete XInput implementation * XInput triggers * Add preliminary CHANGELOG entry. * match unix common API to evl 2.0 * wayland: eventloop2.0 * make EventLoopProxy require T: 'static * Revamp device event API, as well as several misc. fixes on Windows: * When you have multiple windows, you no longer receive duplicate device events * Mouse Device Events now send X-button input * Mouse Device Events now send horizontal scroll wheel input * Add MouseEvent documentation and Device ID debug passthrough * Improve type safety on get_raw_input_data * Remove button_id field from MouseEvent::Button in favor of �utton * Remove regex dependency on Windows * Remove axis filtering in XInput * Make gamepads not use lazy_static * Publicly expose gamepad rumble * Unstack DeviceEvent and fix examples/tests * Add HANDLE retrieval method to DeviceExtWindows * Add distinction between non-joystick axes and joystick axes. This helps with properly calculating the deadzone for controller joysticks. One potential issue is that the `Stick` variant isn't used for *all* joysticks, which could be potentially confusing - for example, raw input joysticks will never use the `Stick` variant because we don't understand the semantic meaning of raw input joystick axes. * Add ability to get gamepad port * Fix xinput controller hot swapping * Add functions for enumerating attached devices * Clamp input to [0.0, 1.0] on gamepad rumble * Expose gamepad rumble errors * Add method to check if device is still connected * Add docs * Rename AxisHint and ButtonHint to GamepadAxis and GamepadButton * Add CHANGELOG entry * Update CHANGELOG.md * Add HidId and MovedAbsolute * Fix xinput deprecation warnings * Add ability to retrieve gamepad battery level * Fix weird imports in gamepad example * Update CHANGELOG.md * Resolve francesca64 comments
Add gamepad support for stdweb and web-sys, as well as web-specific gamepad examples. * [web] Fix compilation error from device api * [wasm] Apply device api changes * [wasm] Format and cleanup * [wasm32] Implement gamepad connections * [wasm] Harmonize * [Test] Made some tests with wasm-pack * Quick fix instant non supporting Hash trait * Fix on_received_character * [web_sys] Split add_event and add_window_event * [web] split device implementations * Update tests/web...still does not work * [tests/web] do not ignore index.html * [web/web_sys] split canvas and window * [tests/web] enable stack trace * [web] fix borrowmut * [web_sys] fix gamepad registration * [web] harmonize naming * [web_sys] create global emitter * [web] implement gamepad buttons * [web] implement gamepad axis * [web] cleanup * [web] update test * [web] move tests/web to examples/web * [web] axis does produce stick event * [web] Support Stick event * [web] implement gamepad to stdweb * [web] rename examples/web to examples/wasm * [web/web-sys] Move gamepad_manager from backend * [web/web_sys] implement EventLoop::gamepads * [web/web_sys] Drain gamepad events * [web/stdweb] apply web_sys changes * [web] update web/examples * [web] move gamepads code to gamepad_manager * [web] simplify and optimise * [web] replace EventCode to GamepadAxis and GamepadButton structs * [web] reuse gamepad events due to chrome issue * [web] rumble does not work * [web/stdweb] try debugging * [web] fix Chrome gamepad not updated * [web/stdweb] created an example * [examples] fix paths * fix warnings * [web/examples] update comments * [web/stdweb] add experimental support to vibrate() * [web] add CR
Co-authored-by: Marnix Kuijs <Marnix.Kuijs@embark-studios.com>
This reverts commit e004bd2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, the API looks sensible to me and the implementation as well, thanks alot! - a few nits from my side.
device_id, | ||
event: Motion { axis: 1, value: y }, | ||
}); | ||
if x != 0.0 || y != 0.0 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think 0.0
would be valid for absolute position.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it should indeed be a valid position.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It turns out that my Wacom tablet will seemingly emit spurious events where the x
and y
position are both 0.0
, even thought the pen is far from the upper left corner. I suspect this is in part due to winit not recognizing the digitizer as a separate "device", as the mouse ID in these events is 0x0
.
if x != 0.0 || y != 0.0 { | ||
subclass_input.send_event(Event::MouseEvent( | ||
mouse_handle, | ||
MouseEvent::MovedAbsolute(PhysicalPosition { x, y }), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The returned positions are effectivley 16bit unorms iirc. This would require to map it to the current screen dimensions. Do you know in what coordinate system other platforms report absolute position? (0..screen | 0..1 | .. )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know in what coordinate system other platforms report absolute position?
I have no idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I tested this with my Wacom tablet, since it's the only device I have that can report absolute position, and the coordinates it spits out are not normalized at all. It just gives me regular "pixel coordinates".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I plugged my old Wacom tablet as well and it reports values in the range of [0; 64k] following the Windows docs.
I had to disable Ink as it otherwise broke Raw Input for me (not reporting values at all only on entering/exiting a Window)
[src\platform_impl\windows\event_loop.rs:2226] (x, y, raw_mouse.usFlags) = (
61224.0,
62378.0,
MOUSE_MOVE_ABSOLUTE | MOUSE_VIRTUAL_DESKTOP,
)
[src\platform_impl\windows\event_loop.rs:2226] (x, y, raw_mouse.usFlags) = (
60098.0,
61524.0,
MOUSE_MOVE_ABSOLUTE | MOUSE_VIRTUAL_DESKTOP,
)
Hype! Thank you for the hardwork. 🚀 |
Co-authored-by: Markus Siglreithmaier <m.siglreith@gmail.com>
Any update? |
I'm a bit busy right now IRL. I'll try to get some progress on the keyboard event rework this month, and then I'll have another look at this PR. |
Hey! Do you require some additional help working on this? I can help out if you'd like. We are interested in using this! |
It would be great to get some more data points on tablet/digitizer behaviour, as that's what got me stumped the last time I worked on this (see the unresolved review comments above for context). |
👍 I'll find some devices to test on. |
I'd be willing to test a bit, too, running on Wayland/X11 with both a normal touchscreen and a stylus. |
Any update on gamepad support? |
Sorry, I closed this accidentally while cleaning up old branches, and GitHub doesn't allow me to re-open it... In any case, no, no update on gamepad support. |
cargo fmt
has been run on this branchcargo doc
builds successfullyCHANGELOG.md
if knowledge of this change could be valuable to usersI have now done as I suggested previously, and merged only the Windows implementation of #944 with
master
(ignore the bungled git history, lol). I have also made sure to set up the PR such that the only changes that need review are the ones specific to thegamepad-device-events-2
branch. Due to these decisions, this PR should be far easier to review than #1856.I probably wouldn't have gotten as far as I have as quickly as I have without cross-referencing the work that @MarnixKuijs did in #1856, so thanks a lot for that :).