Implement proper Impulse Triggers for Xbox controllers.

[Giovani1906]

Version of xpadneo

v0.9.4

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series X|S controller
• Other:

Connection mode

• Bluetooth connection
• USB cable (not yet supported)
• Xbox Dongle connection (not yet supported)

Describe your feature request

• I'd like to see support for a specific model
• I'd like to see support for a specific hardware feature
• I'd like to see support for a specific software feature

Is your feature request related to a problem? Please describe.
I'd like Xbox controllers to have proper Impulse Triggers rather than what currently is done which just a synthesis of the effect.
The current synthesized effect is inaccurate and the vibrations seem too strong at times.

Describe the solution you'd like
I would like that Impulse Triggers would be implemented using the following kernel patches:

• https://lore.kernel.org/lkml/20220410220449.5071-1-dbdaniel42@gmail.com/
• https://lore.kernel.org/lkml/20220410220633.5235-1-dbdaniel42@gmail.com/
• https://lore.kernel.org/lkml/20220410220649.5258-1-dbdaniel42@gmail.com/
• https://lore.kernel.org/lkml/20220410220701.5279-1-dbdaniel42@gmail.com/
• https://lore.kernel.org/lkml/20220410220713.5303-1-dbdaniel42@gmail.com/

Describe alternatives you've considered
Currently there are no alternatives that I have heard of.

Additional context
The maintainer kakra has asked me to make an issue in other for them to keep track of it.

[kakra]

The current synthesized effect is inaccurate and the vibrations seem too strong at times.

You can reduce the amount of vibration effect using rumble_attenuation=0,50 as a module parameter to reduce the rumble effect for the main rumble by 0% and for the trigger rumble by 50%. This is not a solution to the problem but it may improve your experience until proper support is in place.

The Arch wiki has information on how to use module parameters and set them on boot:
https://wiki.archlinux.org/title/Kernel_module

[adamdmoss]

Is the trigger rumble strength supposed to be proportional to the body rumble strength? I have an issue(?) where I can scale the rumble strength in a game's settings (Saints Row in this case) and that appears to work for the body rumble, but the trigger rumble appears to remain full strength.

[kakra]

The trigger rumble adjusts to the strength of the main rumble. But the trigger rumble motors are pretty intense, you can scale them down with the example from #374 (comment).

So yes, the trigger rumble strength is proportional to the main rumble.

The formula goes like this:

The game sends rumble strength for the weak (W) and strong (S) motor - if you made it weaker within the game, these values will be lower. We take the maximum of both values for our main (M) rumble strength: M = max(W,S).

Now we attenuate the W value by the parameter given to the module (a0), and we do the same for the S value. Both new values will be send to the rumble motors: (Wa,Sa) = (W,S) * (100-a0)%.

Now we use the M value to calculate the trigger motor strength by multiplying the trigger pressure with value M, and additionally attenuate by either a0, or attenuate by a0%*a1%, if the second parameter value is given.

So attenuation 0,50 lowers the main motors by 0%, and the trigger motors by 50%. If you'd use 50,50, it would effectively lower the main motors by 50%, and the trigger motors by an additional 50% (thus 75% effectively).

I hope this explains it well enough. I've double-checked the code, it should work correctly. But feel free to check yourself, the code starts here:

• xpadneo/hid-xpadneo/src/hid-xpadneo.c

  Line 300 in 73be2eb

  /* copy data from effect structure at the very beginning */

[adamdmoss]

Thanks for the explanation! So it sounds like it's just a lot stronger than I'd expect by default even when the app thinks it's scaled way down, but this is expected. :)

[kakra]

Thanks for the explanation! So it sounds like it's just a lot stronger than I'd expect by default even when the app thinks it's scaled way down, but this is expected. :)

The problem is: The app doesn't know anything about the trigger rumble - we synthesize the effect from existing main rumble effects. Maybe we should attenuate it down a whole lot by default. The trigger rumble motors can be really really pronounced, especially at some different pressures you apply to them while they rumble: There's kind of some resonance effect then.

[Giovani1906]

I've managed to make trigger rumble/impulse triggers work by using the patch below and having SDL patched for support as well.

diff --git a/hid-xpadneo/src/hid-xpadneo.c b/hid-xpadneo/src/hid-xpadneo.c
index 1a25631..8660864 100644
--- a/hid-xpadneo/src/hid-xpadneo.c
+++ b/hid-xpadneo/src/hid-xpadneo.c
@@ -290,7 +290,7 @@ static int xpadneo_ff_play(struct input_dev *dev, void *data, struct ff_effect *
 	unsigned long flags, ff_run_at, ff_throttle_until;
 	long delay_work;
 	int fraction_TL, fraction_TR, fraction_MAIN, percent_TRIGGERS, percent_MAIN;
-	s32 weak, strong, direction, max_main;
+	s32 weak, strong, trigger_left, trigger_right, direction;
 
 	struct hid_device *hdev = input_get_drvdata(dev);
 	struct xpadneo_devdata *xdata = hid_get_drvdata(hdev);
@@ -301,6 +301,8 @@ static int xpadneo_ff_play(struct input_dev *dev, void *data, struct ff_effect *
 	/* copy data from effect structure at the very beginning */
 	weak = effect->u.rumble.weak_magnitude;
 	strong = effect->u.rumble.strong_magnitude;
+	trigger_left = effect->u.rumble.trigger_left;
+	trigger_right = effect->u.rumble.trigger_right;
 
 	/* calculate the rumble attenuation */
 	percent_MAIN = 100 - param_rumble_attenuation[0];
@@ -308,7 +310,6 @@ static int xpadneo_ff_play(struct input_dev *dev, void *data, struct ff_effect *
 
 	percent_TRIGGERS = 100 - param_rumble_attenuation[1];
 	percent_TRIGGERS = clamp(percent_TRIGGERS, 0, 100);
-	percent_TRIGGERS = percent_TRIGGERS * percent_MAIN / 100;
 
 	switch (param_trigger_rumble_mode) {
 	case PARAM_TRIGGER_RUMBLE_DIRECTIONAL:
@@ -378,12 +379,6 @@ static int xpadneo_ff_play(struct input_dev *dev, void *data, struct ff_effect *
 		break;
 	}
 
-	/*
-	 * we want to keep the rumbling at the triggers at the maximum
-	 * of the weak and strong main rumble
-	 */
-	max_main = max(weak, strong);
-
 	spin_lock_irqsave(&xdata->ff_lock, flags);
 
 	/* calculate the physical magnitudes, scale from 16 bit to 0..100 */
@@ -394,9 +389,9 @@ static int xpadneo_ff_play(struct input_dev *dev, void *data, struct ff_effect *
 
 	/* calculate the physical magnitudes, scale from 16 bit to 0..100 */
 	update_magnitude(xdata->ff.magnitude_left,
-			 (u8)((max_main * fraction_TL + S16_MAX) / U16_MAX));
+			 (u8)((trigger_left * fraction_TL + S16_MAX) / U16_MAX));
 	update_magnitude(xdata->ff.magnitude_right,
-			 (u8)((max_main * fraction_TR + S16_MAX) / U16_MAX));
+			 (u8)((trigger_right * fraction_TR + S16_MAX) / U16_MAX));
 
 	/* synchronize: is our worker still scheduled? */
 	if (xdata->ff_scheduled) {

The SDL2 patch can be found at CachyOS/CachyOS-PKGBUILDS#247.
It contains a Linux headers patch as well, otherwise SDL2 won't compile properly.
I've also made a usable kernel patch file at CachyOS/kernel-patches#64.

[kakra]

Please create a PR for this patch: It will have some issues we need to address.

[peterix]

@Giovani1906 hello, I'm trying to get the trigger rumble feature working in a game and I'm wonderign what happened to those patches?

It looks like you never got any response from lkml, and the code definitely isn't upstream.

[kakra]

After v0.10 dropped, I'm going to rework the trigger rumble to become adaptive so it automatically switches modes depending on whether a game has native support or doesn't. Not sure about the implementation details yet but that's the plan.

[peterix]

Right ... I started to look into this in greater detail and it needs more work.

I have built the custom kernel, patched SDL3, and will try this out later today (with the drivers included in the kernel).

The kernel patches don't cover the device reporting if it supports trigger rumble or not. Code like this should be able to find out:
https://github.com/libsdl-org/SDL/blob/main/src/joystick/linux/SDL_sysjoystick.c#L1440-L1447

The functionality seems kinda just 'slapped on' in the kernel. Even the original is quite limited.
If I was making a device with an arbitrary number of force feedback supporting 'parts', I would be stuck with an interface that doesn't fit.

Looking at what Microsoft is doing with this:
https://learn.microsoft.com/en-us/gaming/gdk/docs/reference/input/gameinput-v1/structs/gameinputforcefeedbackmotorinfo-v1
They have moved past what linux has copied here and are doing the 'arbitrary number of motors' thing.

So we have an issue here that probably needs a bit of feedback (hah!) from the kernel maintainers about extending/replacing the public interface of the kernel. Ideally, a device would report an array of motors with their properties that userspace can look at and figure out what they are instead of a single hardcoded 'ff' property set.

[kakra]

Well, SDL could use the controllers in hidraw mode, and then the kernel driver doesn't really matter. xpadneo has no saying in software that uses hidraw. We currently disable hidraw permissions due to various issues with the SDL controllerdb but that may be fixed by now and should have found its way into all major distributions.

Whatever we do in xpadneo, we are limited to what the kernel provides. Currently, xpadneo features a synthesized trigger rumble. If the kernel interface is stable, I could add something that switches off the synthesizing if it detects values on the trigger rumble code path from user-space.

So if you want to try SDL with hidraw, just change the permissions which our udev rule sets (however, xpadneo fixes and swaps some bits in the HID report which can make some older SDL versions not reporting input correctly: we provide HID reports mostly in the same format that Steam Input does which is why we use the Xbox360 ID which protonized wine internally uses to detect Steam Input virtual controllers).

The kernel interface is very old, and it wasn't even made for rumble, it was made for force-feedback. Rumble doesn't apply force or counter force. It just rumbles. That's also why I want to move away from ff-memless: Its low frequency of emulation creates aliasing effects with modern effects from games.

The kernel should probably add a new interface for rumble motors, and let the old force feedback system alone. I'm starting to think that ff-memless even should not exist: I don't see where it could be useful to real force-feedback devices, and for rumble devices, it's too slow to respond and its emulation cannot really deal with the slow inertia of some rumble motors.

There are controllers (e.g. the newer DualShocks) which support force feedback on the triggers. But Xbox controllers don't, they can just rumble and thus provide tactile feedback.

[kakra]

The kernel patches don't cover the device reporting if it supports trigger rumble or not. Code like this should be able to find out:
https://github.com/libsdl-org/SDL/blob/main/src/joystick/linux/SDL_sysjoystick.c#L1440-L1447

This is nothing we could use in the kernel, because this queries the features of the driver. In this case, it should enable rumble and sine for xpadneo because we use ff-memless, and ff-memless provides both features.

If I drop ff-memless, we would only provide rumble because that's what the hardware can do. Genuine Xbox controllers can also do square wave rumble (by using the timing parameters) but most cheap China clones ignore the timing completely and thus can only do plain rumble. The mentioned code looks like SDL completely ignores square wave rumble, and I don't know why it even checks for sine... It probably checks for sine because some controllers (like Steam Deck) use linear rumble motors instead of rotating rumble motors. Such rumble motors work more like a sine wave, and are similar to a sound speaker. Actually, I think, the rumble of Steam Decks is routed through an audio chip and thus also provides tactile bass feedback for audio.