Skip to content

[HID] Added option to turn off vibration #1820

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Gliniak
Copy link
Member

@Gliniak Gliniak commented May 24, 2021

Some games in x360 lib doesn't allow to turn off vibrations directly from the game. That option is for these cases.
I tried it in two more ways.

  1. To set profile setting related to vibration to 0
  2. Tell that controller doesn't support vibrations

But they didn't worked 😢

if (!cvars::enable_vibration) {
vibration->left_motor_speed = 0;
vibration->right_motor_speed = 0;
}
auto input_system = kernel_state()->emulator()->input_system();
return input_system->SetState(user_index, vibration);
Copy link
Member

@Triang3l Triang3l May 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally this should probably be handled by a proxy function in the HID subsystem, I think, also with the possibility of toggling it at runtime, zeroing the current speed when vibration is disabled mid-game from the UI, and remembering the speeds from the latest XamInputSetState call and applying them when vibration is re-enabled.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unsure if it is necessary to have the rumble speed remembered. What guest do you now that has active rumble (at the same level) for more than a second? (while there is active user input)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Environmental effects such as thunder possibly, big explosions in scripted scenes.

Copy link
Member

@Triang3l Triang3l Jan 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, statically, in the XInput API, there are no requirements of how frequently the function needs to be called so that we can treat a specific maximum length as "negligible". By only dropping calls, we're introducing arbitrary behavior not present in the API specification, as well as unspecified constraints on arbitrarily chosen dynamic state (when the game performs the XInputSetState calls, and the point in time when the user has toggled vibration). A properly isolated implementation should store the desired vibration level, and perform the toggling with the event flow similar to that of a new keystroke somewhat arriving from the UI thread in the winkey HID backend (with the difference that it should be applied immediately once no race condition between the toggling and a new SetState is possible, not cached until the next SetState).

Copy link
Member

@JoelLinn JoelLinn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think kernel is the right place to do this. hid sub-system makes more sense to me (see comments)

if (!cvars::enable_vibration) {
vibration->left_motor_speed = 0;
vibration->right_motor_speed = 0;
}
auto input_system = kernel_state()->emulator()->input_system();
return input_system->SetState(user_index, vibration);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am unsure if it is necessary to have the rumble speed remembered. What guest do you now that has active rumble (at the same level) for more than a second? (while there is active user input)

@Gliniak Gliniak force-pushed the disablePositiveVibes branch 2 times, most recently from 2d5a50b to 9bd635e Compare May 24, 2021 19:00
@@ -62,10 +64,14 @@ X_RESULT InputSystem::GetState(uint32_t user_index, X_INPUT_STATE* out_state) {
X_RESULT InputSystem::SetState(uint32_t user_index,
X_INPUT_VIBRATION* vibration) {
SCOPE_profile_cpu_f("hid");

X_INPUT_VIBRATION* modified_vibration = new X_INPUT_VIBRATION();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a memory leak 🥲
Just do X_INPUT_VIBRATION modified_vibration; to allocate it on the stack and pass &modified_vibration

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you're already adding the scale for the vibration, you can just return immediately from the function, by the way — you don't need to set vibration to 0 if you never set it to anything other than 0 anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Smack me with a hammer for my stupidity... I dunno what I was thinking and why I thought it will be fine

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, if this var can someday be changed from gui and controller is currently rumbling, itll never stop iIrc

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The GUI button can explicitly stop the current vibration.

@Gliniak Gliniak force-pushed the disablePositiveVibes branch from 9bd635e to 409bb6a Compare May 24, 2021 19:25
@Margen67 Margen67 added the input label Jan 29, 2022
@Gliniak Gliniak force-pushed the disablePositiveVibes branch from 409bb6a to 2868489 Compare February 3, 2022 07:32
@Gliniak Gliniak requested a review from Triang3l February 3, 2022 08:11
@Gliniak Gliniak force-pushed the disablePositiveVibes branch from 2868489 to 613f5eb Compare February 3, 2022 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants