Successfully sending out the extra buttons

[ahungry]

No description provided.

[ahungry]

Is it possible to incorporate this third party controller? It's identification crosses over into the domain of first party controllers, however it ships with 8 additional buttons, which, while mapped via a special app, still seem to send the distinct button data - I was going to make a thin driver for it (I just did for bluetooth, and wanted to make one for dongle, which this PR works with) - however xpad makes it difficult to have my driver take precedence due to the colliding vendor id/product ids.

I think I might be able to form a workaround using something like:

cat /etc/depmod.d/xpad.conf
override xpad * updates

but I'm not entirely sure of the syntax (I found this snippet for having a source installed dkms xpad take greater precedence than the built in one, but in this case, I would want a module named something like "vader3d" to take precedence over xpad).

[ahungry]

Actually, I don't think depmod can allow differently named modules to supersede each other (only same name ones).

What's interesting is this works perfect (extra buttons + rumble) if the module name is "xpad" - if I change the module name to something like "vader3d" the rumble stops working ("Function not implemented" in fftest) - does anyone know if "fftest" has some hard coded exceptions to force rumble data if the driver is xpad?

I've diffed the files, and they are identical (other than the .name in the driver data) - and it only reliably rumbles if the name is "xpad", despite everything else being the same.

[RondoRevolution]

Currently the best way this PR works as it is inside Steam is by downloading controller configurations made by other users for controllers with pads, like Xbox Elite or Steam Deck configs. This way the paddles work correctly, but you can't remap it yourself in the UI.

Maybe mocking a Xbox Elite controller in xpad could enable the back buttons to be remapped in Steam? Since it seems to work according to this issue on your Bluetooth driver for the controller: ahungry/vader3#2

It would probably need to match the paddles to the same BTN_TRIGGER_HAPPY used by the Elite controller. Also, if it ends up being a good option, wouldn't it be better to do this in xone instead of xpad?

[matoro]

Hey, I took a copy of this PR and applied it to the in-tree xpad driver just out of curiosity and it indeed surprisingly works. For the back paddles M1-M4, I also changed them to map to the same BTN_TRIGGER_HAPPY values that the Elite controller uses, as recommended.

However, it seems that the custom buttons submit both their custom codes AND the standard buttons they are mapped to, e.g. pressing C submits both C and L3. Did you clear the custom mappings in the proprietary software before using this patch?

I was scratching my head about how to work around this in the code, but couldn't come up with anything that doesn't assume specific mappings. For example, if I modified it to ignore all other keypresses when pressing a custom button, then I believe that would prevent e.g. walking forward while pressing C.

[ahungry]

Yes, I believe I cleared my Flydigi Space Station mappings before using it as you note (due to the duplicate key presses) - though it's been awhile since I used the dongle 😆

[matoro]

Yes, I believe I cleared my Flydigi Space Station mappings before using it as you note (due to the duplicate key presses) - though it's been awhile since I used the dongle 😆

Thank you, I installed Space Station in a VM and passed my controller through to it, cleared the mappings, and double presses are gone now.

First I found a very old patch from 2007 that appears not to have made it in confirming that all valid packets have a length of 20 bytes, so it is always safe to access byte 19. I rebased this patch and added it in as an additional validity check.

Then I tweaked the patch a little bit to use some more modern kernel functions, mainly BIT() macro and input_set_capability().

Next I changed the addition of the extra buttons to be an opt-in module paramater called extra_buttons. This way the new behavior is strictly non-default. Possibly this might make it more amenable to upstream kernel maintainers.

Lastly I limited the additional button count to 3 (C, Z, and circle). The second circle button seems to overlap with the Guide button and this does not seem to be configurable in Space Station, so I left it out.

Here is my overall patch, which applies to upstream 6.10. I'm not sure if this is suitable for upstreaming, but if you'd like to submit it to the mailing list, it can't hurt.

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 2b8370ecf42a..21fb1c5ffddc 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -120,6 +120,10 @@ static bool auto_poweroff = true;
 module_param(auto_poweroff, bool, S_IWUSR | S_IRUGO);
 MODULE_PARM_DESC(auto_poweroff, "Power off wireless controllers on suspend");
 
+static bool extra_buttons = false;
+module_param(extra_buttons, bool, S_IRUGO);
+MODULE_PARM_DESC(extra_buttons, "Enable 3 extra buttons for Flydigi Vader Pro 3");
+
 static const struct xpad_device {
 	u16 idVendor;
 	u16 idProduct;
@@ -444,6 +448,13 @@ static const signed short xpad_btn_paddles[] = {
 	-1						/* terminating entry */
 };
 
+/* used for extra buttons in addition to paddles on Flydigi Vader Pro 3*/
+static const signed short xpad_btn_extra[] = {
+	BTN_TRIGGER_HAPPY9, BTN_TRIGGER_HAPPY10, /* C, Z face buttons */
+	BTN_TRIGGER_HAPPY11,			/* circle */
+	-1						/* terminating entry */
+};
+
 /*
  * Xbox 360 has a vendor-specific class, so we cannot match it with only
  * USB_INTERFACE_INFO (also specifically refused by USB subsystem), so we
@@ -826,6 +837,7 @@ static void xpad_process_packet(struct usb_xpad *xpad, u16 cmd, unsigned char *d
  *
  *	The used report descriptor was taken from:
  *		http://www.free60.org/wiki/Gamepad
+ *	Packet length for valid data is 20 bytes.
  */
 
 static void xpad360_process_packet(struct usb_xpad *xpad, struct input_dev *dev,
@@ -834,6 +846,8 @@ static void xpad360_process_packet(struct usb_xpad *xpad, struct input_dev *dev,
 	/* valid pad data */
 	if (data[0] != 0x00)
 		return;
+	if (data[1] < 20)
+		return;
 
 	/* digital pad */
 	if (xpad->mapping & MAP_DPAD_TO_BUTTONS) {
@@ -898,6 +912,17 @@ static void xpad360_process_packet(struct usb_xpad *xpad, struct input_dev *dev,
 		input_report_abs(dev, ABS_RZ, data[5]);
 	}
 
+	/* Additional buttons for Flydigi Vader Pro 3 presenting as 360 pad. */
+	if (extra_buttons) {
+		input_report_key(dev, BTN_TRIGGER_HAPPY9, data[19] & BIT(0));   // C
+		input_report_key(dev, BTN_TRIGGER_HAPPY10, data[19] & BIT(1));  // Z
+		input_report_key(dev, BTN_TRIGGER_HAPPY5, data[19] & BIT(3));   // Leftmost paddle (M2)
+		input_report_key(dev, BTN_TRIGGER_HAPPY6, data[19] & BIT(5));   // Second to leftmost (M4)
+		input_report_key(dev, BTN_TRIGGER_HAPPY7, data[19] & BIT(4));   // Second to rightmost (M3)
+		input_report_key(dev, BTN_TRIGGER_HAPPY8, data[19] & BIT(2));   // Rightmost paddle (M1)
+		input_report_key(dev, BTN_TRIGGER_HAPPY11, data[20] & BIT(0));  // Circle
+	}
+
 	input_sync(dev);
 
 	/* XBOX360W controllers can't be turned off without driver assistance */
@@ -1953,11 +1978,18 @@ static int xpad_init_input(struct usb_xpad *xpad)
 	}
 
 	/* set up paddles if the controller has them */
-	if (xpad->mapping & MAP_PADDLES) {
+	if ((xpad->mapping & MAP_PADDLES) || extra_buttons) {
 		for (i = 0; xpad_btn_paddles[i] >= 0; i++)
 			input_set_capability(input_dev, EV_KEY, xpad_btn_paddles[i]);
 	}
 
+	/* set up extra buttons when enabled as module param */
+	if (extra_buttons) {
+		for (i = 0; xpad_btn_extra[i] >= 0; i++) {
+			input_set_capability(input_dev, EV_KEY, xpad_btn_extra[i]);
+		}
+	}
+
 	/*
 	 * This should be a simple else block. However historically
 	 * xbox360w has mapped DPAD to buttons while xbox360 did not. This

[rharish101]

Would this also work with the Vader 4 Pro? I'm considering buying one, and if I do, I'm willing to test it on this branch/patchset.

[matoro]

Would this also work with the Vader 4 Pro? I'm considering buying one, and if I do, I'm willing to test it on this branch/patchset.

No idea, I also considered it but went with the 3 specifically because of this PR. If it does that would be great; let me know and I will update the comments.

It's very annoying that they decided to steal the official X360 USB ID instead of creating their own, so there is no way to autodetect the difference easily. I do still have an old official controller, so I might dig into it later to see if I can identify any subtle differences that might distinguish them.

Overall I'm very happy with this. I've already written up a small script using python-evdev to add macros for Elden Ring and it works great!

[rharish101]

Sounds great! I don't plan on getting the Vader 3 (because it looks ugly IMO), so it'll probably be the Vader 4. I also have an official Xbox 360 wireless controller (with the USB dongle), so I could also help with distinguishing them. I'll post here once I buy it (or decide not to).

[matoro]

Upstream has taken bit 6 for other purposes, so here's a rebased version against current kernel 6.14. This diverges it more from this out-of-tree dkms xpad unfortunately.

commit 870317dfe598114eddb39386cc87781f3dbb3df6
Author: matoro <[email protected]>
Date:   2025-06-01 21:36:40 -0400

    Input: xpad - enable & autodetect Flydigi extra buttons
    
    This adds a framework for supporting additional features on devices
    piggybacking an existing USB vendor/product ID but distinguishing
    themselves via the idProduct field.  This is necessary because the
    Flydigi Vader Pro series controllers reuse the same vendor/product ID as
    orginal Microsoft Xbox 360 controllers.
    
    The MAP_FLYDIGI_BUTTONS is a new mapping for the C, Z, and Circle face
    buttons on Flydigi 360-compatible controllers.  It has been tested on
    the Vader 3 Pro and Vader 4 Pro.
    
    These controllers additionally have 4 back paddles, same as the Xbox
    Elite controller, so it is included in the extra feature list.
    
    Thanks-to: Matthew Carter <[email protected]>
    See: https://github.com/paroj/xpad/pull/268
    Signed-off-by: Matoro Mahri <[email protected]>

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 400e7aac6aaf..155e1ff3e832 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -84,6 +84,7 @@
 #define MAP_PADDLES			BIT(4)
 #define MAP_PROFILE_BUTTON		BIT(5)
 #define MAP_SHARE_OFFSET		BIT(6)
+#define MAP_FLYDIGI_BUTTONS             BIT(7)
 
 #define DANCEPAD_MAP_CONFIG	(MAP_DPAD_TO_BUTTONS |			\
 				MAP_TRIGGERS_TO_BUTTONS | MAP_STICKS_TO_NULL)
@@ -417,6 +418,20 @@ static const struct xpad_device {
 	{ 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
 };
 
+
+// A "flavor" is an aftermarket variant of an existing model supporting
+// additional features.
+static const struct xpad_flavor {
+	u16 idVendor;
+	u16 idProduct;
+	char *product;
+	u8 mapping;
+} xpad_flavor[] = {
+	{ 0x045e, 0x028e, "Flydigi VADER3", MAP_PADDLES | MAP_FLYDIGI_BUTTONS },
+	{ 0x045e, 0x028e, "Flydigi VADER4", MAP_PADDLES | MAP_FLYDIGI_BUTTONS },
+	{ 0x0000, 0x0000, NULL, 0 }
+};
+
 /* buttons shared with xbox and xbox360 */
 static const signed short xpad_common_btn[] = {
 	BTN_A, BTN_B, BTN_X, BTN_Y,			/* "analog" buttons */
@@ -474,6 +489,14 @@ static const signed short xpad_btn_paddles[] = {
 	-1						/* terminating entry */
 };
 
+
+/* used for extra buttons in addition to paddles on Flydigi Vader Pro series*/
+static const signed short xpad_btn_extra[] = {
+	BTN_TRIGGER_HAPPY9, BTN_TRIGGER_HAPPY10, /* C, Z face buttons */
+	BTN_TRIGGER_HAPPY11,			 /* circle */
+	-1						/* terminating entry */
+};
+
 /*
  * Xbox 360 has a vendor-specific class, so we cannot match it with only
  * USB_INTERFACE_INFO (also specifically refused by USB subsystem), so we
@@ -938,6 +961,18 @@ static void xpad360_process_packet(struct usb_xpad *xpad, struct input_dev *dev,
 		input_report_abs(dev, ABS_RZ, data[5]);
 	}
 
+
+	/* Additional buttons for Flydigi Vader Pro series presenting as 360 pad. */
+	if (xpad->mapping & MAP_FLYDIGI_BUTTONS) {
+		input_report_key(dev, BTN_TRIGGER_HAPPY9, data[19] & BIT(0));   // C
+		input_report_key(dev, BTN_TRIGGER_HAPPY10, data[19] & BIT(1));  // Z
+		input_report_key(dev, BTN_TRIGGER_HAPPY5, data[19] & BIT(3));   // Leftmost paddle (M2)
+		input_report_key(dev, BTN_TRIGGER_HAPPY6, data[19] & BIT(5));   // Second to leftmost (M4)
+		input_report_key(dev, BTN_TRIGGER_HAPPY7, data[19] & BIT(4));   // Second to rightmost (M3)
+		input_report_key(dev, BTN_TRIGGER_HAPPY8, data[19] & BIT(2));   // Rightmost paddle (M1)
+		input_report_key(dev, BTN_TRIGGER_HAPPY11, data[20] & BIT(0));  // Circle
+	}
+
 	input_sync(dev);
 
 	/* XBOX360W controllers can't be turned off without driver assistance */
@@ -1972,6 +2007,14 @@ static int xpad_init_input(struct usb_xpad *xpad)
 			input_set_capability(input_dev, EV_KEY, xpad_btn_paddles[i]);
 	}
 
+
+	/* set up extra face buttons if the controller has them */
+	if (xpad->mapping & MAP_FLYDIGI_BUTTONS) {
+		for (i = 0; xpad_btn_extra[i] >= 0; i++) {
+			input_set_capability(input_dev, EV_KEY, xpad_btn_extra[i]);
+		}
+	}
+
 	/*
 	 * This should be a simple else block. However historically
 	 * xbox360w has mapped DPAD to buttons while xbox360 did not. This
@@ -2026,7 +2069,7 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct usb_xpad *xpad;
 	struct usb_endpoint_descriptor *ep_irq_in, *ep_irq_out;
-	int i, error;
+	int i, j, error;
 
 	if (intf->cur_altsetting->desc.bNumEndpoints != 2)
 		return -ENODEV;
@@ -2060,6 +2103,18 @@ static int xpad_probe(struct usb_interface *intf, const struct usb_device_id *id
 	xpad->udev = udev;
 	xpad->intf = intf;
 	xpad->mapping = xpad_device[i].mapping;
+
+	if (udev->product) {	// Only worry about extra flavors if a product string is present
+		for(j = 0; xpad_flavor[j].idVendor; j++) {
+			if (le16_to_cpu(udev->descriptor.idVendor) == xpad_flavor[j].idVendor &&
+			    le16_to_cpu(udev->descriptor.idProduct) == xpad_flavor[j].idProduct &&
+			    !strcmp(udev->product, xpad_flavor[j].product)) {
+				xpad->mapping |= xpad_flavor[j].mapping;
+				break;
+			}
+		}
+	}
+
 	xpad->xtype = xpad_device[i].xtype;
 	xpad->name = xpad_device[i].name;
 	xpad->packet_type = PKT_XB;

[italoghost]

Hi! It seems that Steam has added support for Flydigi Vader and Apex controllers:

https://steamcommunity.com/app/1675200/eventcomments/597403179793030836

Jun 9, 2025
Steam Deck Beta Client Update: June 9th

We have just shipped an updated Steam Deck Client to the Preview/Beta channel.

Steam Input

Added the ability to bind the paddles and L4/R4 buttons on the 8BitDo Ultimate 2 Wireless Controller when connected via Bluetooth

Added the ability to bind the paddles on the 8BitDo Pro 2 Controller when in DirectInput mode

Added the ability to bind the paddles and C/Z buttons on the FlyDigi Vader series controllers

Added the ability to bind the paddles on the FlyDigi Apex series controllers

Fixed input when using the latest firmware for the Mayflash GameCube adapter

[italoghost]

I've tested in my PC but without success. I removed the patched xpad package, disabled inputplumber, reboot the PC and launched Steam with the -steamdeck parameter.

It probably is an implementation on SteamOS itself. Does anyone know where to look?

[belozer]

I've tested in my PC but without success. I removed the patched xpad package, disabled inputplumber, reboot the PC and launched Steam with the -steamdeck parameter.

It probably is an implementation on SteamOS itself. Does anyone know where to look?

Gamepad: Flydigi Apex 4.

I have it working fine on Windows in D-Input mode, but it refuses on Linux. After disabling InputPlumber, the gamepad is detected as Vader 3 (Like in windows), but the additional M1, M2, M3, M4, C, Z buttons are not displayed on Steam (as on Windows).

In addition, no pressing of any of the keys is recognized by the steam.

If I turn on InputPlumber, the gamepad starts working in DInput mode, but it is detected as a SteamOS Handled Device. All the buttons start working, but Steamdeck is displayed in the Steam UI of the gamepad. This is the first problem. The second is that the vibrations don't work... On Windows, everything is fine with this.

[italoghost]

@belozer are you testing through bluetooth or through the dongle? I didn't test in dinput mode. I will try it later!

[belozer]

@belozer are you testing through bluetooth or through the dongle? I didn't test in dinput mode. I will try it later!

On Windows it works only in D-Input mode. When I use X-Input then gamepad detects as XBox 360.

Before I tested only via Dongle. Now I tested via BT + D-Input. Gamepads detects as Vader 3, but UI is not show additional buttons. Main buttons works.

Maybe this Steam update only applies to Windows so far? Otherwise, I think these additional buttons would be visible in the UI.

Linux Steam version: 1749507822
Linux Steam build date: 9 june 2025

Example how it looks in Windows

D-Input

X-Input

Windows Steam version: 1749507822
Windows Steam build date: 9 june 2025

[belozer]

I think this commits added Flydigi support.

First libsdl-org/SDL@354895d
Second libsdl-org/SDL@c9cf4c4

[italoghost]

I could reproduce the exactly same behaviors as you did. This must be an incomplete implementation. I tried with another controller (8BitDo Pro 2) and Steam recognized it as a 8BitDo Pro 2, but couldn't recognize the paddles.

[RondoRevolution]

I just tested on Steam's Controller configuration and my Vader 3 Pro is properly recognized in D-Input mode with working paddles, C/Z buttons and vibration on Bazzite.

I haven't tested if Gyro works nor if it is working properly in a game to see if I can change the configuration tho.

[italoghost]

@RondoRevolution did you have the patched xpad package or/and inputplumber installed?

[RondoRevolution]

@italoghost Nope. I'm on Bazzite which is atomic, so I can't patch xpad and while I'm aware of inputplumber, I never used it.

[RondoRevolution]

Just tested it further. I can successfully remap the back buttons by opening the overlay in-game and it works immediately. Gyro doesn't seem to be available, but I can activate it in mouse mode gyro by pressing the circle button to the left of the home button on the controller.

[italoghost]

Just tested again and couldn't make it work. Maybe I am missing some packages, as I am running CachyOS.

[belozer]

Just tested it further. I can successfully remap the back buttons by opening the overlay in-game and it works immediately. Gyro doesn't seem to be available, but I can activate it in mouse mode gyro by pressing the circle button to the left of the home button on the controller.

gyro works same on Windows (via FN button)

[zer0exia]

@RondoRevolution Is vibration/rumble working for you when the controller is in d-input mode? Just want to double check since you mentioned it, because I thought rumble doesn't work with d-input mode controllers on Linux.

On my end in d-input mode, everything else other than rumble/vibration works as described above (Vader 3 Pro, currently on Steam Beta Channel).

[belozer]

@RondoRevolution did you test via dongle?

@zer0exia you also have bazzite or other distro?

[zer0exia]

@belozer I'm on EndeavourOS, running kernel 6.15.1-zen1-2-zen. Default xpad (non-patched).

[belozer]

I tried 6.15.1-zen1-2-zen, and clear xpad installation (without patches) on CachyOS

❯ dkms status
xpad/0.4.126.902ffab, 6.15.1-zen1-2-zen, x86_64: installed (Original modules exist)
xpad/0.4.126.902ffab, 6.15.2-2-cachyos, x86_64: installed (Original modules exist)

Flydigi Apex 4 recognized by Steam as Vader 3 (via dongle + d-input), but main buttons not work and extra buttons not showed.

@zer0exia @RondoRevolution can you show your output dkms status?

[RondoRevolution]

@belozer I tested with the dongle yes, haven't tried with Bluetooth. Bazzite doesn't use dkms, so I can't do that.

@zer0exia it worked on the controller config page on Steam when pressing the Vibration button on the gui. I'll test it in a game to be sure it's actually working.

[RondoRevolution]

@zer0exia Just tested it on Katana Zero and vibration/rumble works!

[zer0exia]

@belozer Not sure about your problem or the differences between Apex 4 and Vader 3, but does it work properly (the extra buttons) if you use the patch above and custom SDL entry with x-input mode?

❯ dkms status
hid-xpadneo/0.9.r222.gcd25680, 6.15.1-arch1-2, x86_64: installed
hid-xpadneo/0.9.r222.gcd25680, 6.15.1-zen1-2-zen, x86_64: installed

my dkms only contains xpadneo, which is another driver project that handles gamepads using bluetooth connection. Shouldn't be required if you use dongle/wired connection.

@RondoRevolution Yeah I've also got it working. The main gamepad rumble works, but trigger rumble doesn't. I guess that's explicitly only enabled on x-input or do you also got that working as well?

However, it seems like it only works properly with games utilizing SteamInput. Outside of Steam, like Lutris or Heroic the buttons are mismatched, extra buttons not detected and all rumble/vibration doesn't work.

[RondoRevolution]

@zer0exia I haven't tested the trigger rumble yet, but I believe it's only available on X-Input. I'll test it on Heroic later, tho I don't know if the current SDL3 version on Bazzite is new enough to have the Flydigi support.

Would be cool if there was a way to change the gyro mode to joystick and change the sensitivity too, when I try to use it in D-Input, it's too sensitive to be actually useful. Actually it works ok, tried on Risk of Rain 2, but the glyphs in-game then change to keyboard.

[RondoRevolution]

@zer0exia Just tested on Risk of Rain 2 and trigger rumble doesn't work. Also tested on Heroic, unfortunately Bazzite's SDL version is from 3.2.12 which would be before the commits mentioned earlier in here, so it didn't work.

I created an issue on the SDL GitHub page for gyro and trigger rumble support.

[belozer]

After a few hours, I discovered a solution on CachyOS.

echo 'KERNEL=="hidraw*", ATTRS{idVendor}=="04b4", ATTRS{idProduct}=="2412", MODE="0666"' | sudo tee /etc/udev/rules.d/99-hidraw.rules
sudo udevadm control --reload
sudo udevadm trigger

Also I added user to input group (maybe dont need)

sudo usermod -aG input $USER

Now all buttons is working (Flydigi Apex 4). Rumble effects works too

[italoghost]

@belozer have you uninstalled the patched xpad package and inputpumbler? And could you explain what have you done? Why was this udev rule necessary?

[italoghost]

I had to add my user to the input group. Otherwise, it wouldn't work!

[belozer]

@belozer have you uninstalled the patched xpad package and inputpumbler? And could you explain what have you done? Why was this udev rule necessary?

Yes. I deleted xpad, disabled inputplumber. I've tried the Bazzite kernel, I've tried the Zen kernel, I've tried the pure kernel. None of this worked. As a result, I found a solution using DeepSeek, which suggested that udev prescribe the rule. After that, everything worked.

idProduct and idVendor may differ for 8Bitdo.

The main symptom of the problem was that evtest saw all the buttons of the gamepad, but did not register events. After udev's adjustments, events responded correctly.

@italoghost did everything work with udev rule too?

[italoghost]

@belozer yes! I had the exactly same issue that you described: evtest saw the buttons, but didn't register any events.

I have tried a different approach that you took by replacing the MODE="0666" by MODE="0660", TAG+="uaccess" and creating /etc/modules-load.d/uinput.conf with uinput in it, so it wouldn't allow to all users to have access to the input, but it didn't work.

It only worked when I added the user to the input group.

I will try to configure a different rule to my 8BitDo Pro 2! It is recognized by Steam, the paddles are registered in evtest, but Steam can`t register then.