xpad
xpad copied to clipboard
paroj
Successfully sending out the extra buttons
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).
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.
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: https://github.com/ahungry/vader3/issues/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?
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.
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 :laughing:
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
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.
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!
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).
I ordered a Vader4 from an overseas site about a month ago - for the last 3 weeks it's been in USPS shipping state - if I ever receive it, I'll update here letting everyone know if the buttons remain the same :laughing:
Just got the vader 4 - it's nice - same hardware ID and buttons as vader 3, so everything that works with vader3 driver wise should "just work" with 4 I believe.
I finally got the Flydigi Vader 4 Pro! I also installed the latest xpad master branch from the AUR (https://aur.archlinux.org/packages/xpad-dkms-git) with the patch from @matoro. First question... how do I test this? 😅
I tried both jstest /dev/input/js1 and evtest, but neither of them responded to the M1-4 back buttons. This is after connecting with the USB dongle over XInput mode.
I've also not updated the firmware or connected it to a Windows machine with the Flydigi software either. Would I have to update the firmware first?
I finally got the Flydigi Vader 4 Pro! I also installed the latest xpad master branch from the AUR (https://aur.archlinux.org/packages/xpad-dkms-git) with the patch from @matoro. First question... how do I test this? 😅
I tried both
jstest /dev/input/js1andevtest, but neither of them responded to the M1-4 back buttons. This is after connecting with the USB dongle over XInput mode.I've also not updated the firmware or connected it to a Windows machine with the Flydigi software either. Would I have to update the firmware first?
Hey, in the patch I implemented it as disabled-by-default as kernel maintainers will almost certainly request that if we ever submit it, so you have to load it with the new extra_buttons option enabled. If it's enabled you should see:
$ cat /sys/module/xpad/parameters/extra_buttons
Y
To manually load it:
$ sudo rmmod xpad
$ sudo modprobe xpad extra_buttons=1
To make it permanent, put this in any new or existing .conf file in /etc/modprobe.d/:
options xpad extra_buttons=1
Thanks for the clarification! I enabled the extra_buttons option and tested it with evtest. I can confirm that all back buttons, the extra face buttons (C & Z), and all accessory buttons (Select, Start, the circle and the home) are detected!
Initially, C & Z also send out the thumb button presses, but after clearing them in the Flydigi software (on a Windows laptop), it just sends over their TRIGGER_HAPPY codes. I also updated the firmware to the current latest version.
Let me know if you need me to test something else for this controller, or for comparing it with the Xbox 360 wireless controller.
Thanks for the clarification! I enabled the
extra_buttonsoption and tested it withevtest. I can confirm that all back buttons, the extra face buttons (C & Z), and all accessory buttons (Select, Start, the circle and the home) are detected!Initially, C & Z also send out the thumb button presses, but after clearing them in the Flydigi software (on a Windows laptop), it just sends over their TRIGGER_HAPPY codes. I also updated the firmware to the current latest version.
Let me know if you need me to test something else for this controller, or for comparing it with the Xbox 360 wireless controller.
Probably not gonna bother unless any upstream kernel maintainer is interested in picking this. As a bonus, here's the little python snippet I wrote to use all the extra buttons in Elden Ring; hope it is useful as example code to write your own macros if you don't have a tool for it already: https://gist.github.com/matoro/f741bca73b7a9ff94abc0c4af5065d58
Hi, everyone! I am thinking about using this PR and I would like to know which is the best approach: install xpad with the patches from this PR or install the xpad-dkms-git from the AUR and patch the Kernel with @matoro's code. What would you suggest?
Hi, everyone! I am thinking about using this PR and I would like to know which is the best approach: install xpad with the patches from this PR or install the
xpad-dkms-gitfrom the AUR and patch the Kernel with @matoro's code. What would you suggest?
I tried a third option: patching the xpad-dkms-git package from the AUR and installing this patched version. It works great for me.
Here is the diff for the xpad-dkms-git PKGBUILD:
diff --git a/PKGBUILD b/PKGBUILD
index 8fc9745..f0b51b1 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -14,14 +14,20 @@ makedepends=('git')
conflicts=("${_pkgname}-dkms")
source=("${pkgname}::git+https://github.com/paroj/xpad.git"
"xpad.conf"
- "${pkgname}.install")
+ "${pkgname}.install"
+ "flydigi-vader-3.patch")
md5sums=('SKIP'
'4218c9543d551377825392295544c3c2'
- '75cad51dc48d8fa879f926432beabf66')
+ '75cad51dc48d8fa879f926432beabf66'
+ '23a93f59392380d10c9dd2f258830acd')
pkgver() {
cd "$pkgname"
printf "0.4.%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short=7 HEAD)"
}
+prepare() {
+ cd "$pkgname"
+ patch -p1 -i flydigi-vader-3.patch
+}
package() {
# install depmod config file so our driver gets higher priority than the intree module
install -dm 755 "$pkgdir/etc/depmod.d"
And here is the flydigi-vader-3.patch file (which is basically @matoro's latest patch):
diff '--color=auto' -ura package.orig/xpad.c package.new/xpad.c
--- package.orig/xpad.c 2024-08-15 12:55:11.936022696 +0200
+++ package.new/xpad.c 2024-08-15 12:56:29.137025131 +0200
@@ -130,6 +130,10 @@
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;
@@ -456,6 +460,13 @@
{0, 0}
};
+/* 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
@@ -893,6 +904,7 @@
*
* 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,
@@ -901,6 +913,8 @@
/* valid pad data */
if (data[0] != 0x00)
return;
+ if (data[1] < 20)
+ return;
/* digital pad */
if (xpad->mapping & MAP_DPAD_TO_BUTTONS) {
@@ -965,6 +979,17 @@
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 */
@@ -2150,11 +2175,18 @@
}
/* 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
Don't forget to set the extra_buttons=1 option! I did it using a file in /etc/modprobe.d.
Thank you, @rharish101! I tested with evtest and all buttons are recognized! I now have another question: is it possible to make Steam recognize the buttons, so I can remap them? Or I will need to use Qjoypad or AntiMicroX, for example?
I couldn't manage to get Steam to recognize the additional buttons. I ended up modifying the Elden Ring script for my own purposes (also for Elden Ring 😛). I set up Lutris to run it as a pre-launch script for Elden Ring, and kill it in a post-exit script.
Hi, everyone! I am thinking about using this PR and I would like to know which is the best approach: install xpad with the patches from this PR or install the
xpad-dkms-gitfrom the AUR and patch the Kernel with @matoro's code. What would you suggest?
FWIW, I know that both approaches work. I do the former on my Gentoo desktop and the latter on my Arch laptop, and they both work.
Also, I used https://github.com/ava1ar/customizepkg for automatically applying the patch to xpad-dkms-git on rebuild on Arch. Gentoo supports applying patches natively.
I couldn't manage to get Steam to recognize the additional buttons. I ended up modifying the Elden Ring script for my own purposes (also for Elden Ring 😛). I set up Lutris to run it as a pre-launch script for Elden Ring, and kill it in a post-exit script.
That is unfortunate. It would be nice to be able to remap it on Steam. I wanted to map one of the face buttons to open the "game menu" - the one opened with Xbox Button + A - on the Gamescope Session.
Is there any other alternative instead of creating a script?
Hi, everyone! I am thinking about using this PR and I would like to know which is the best approach: install xpad with the patches from this PR or install the
xpad-dkms-gitfrom the AUR and patch the Kernel with @matoro's code. What would you suggest?FWIW, I know that both approaches work. I do the former on my Gentoo desktop and the latter on my Arch laptop, and they both work.
Also, I used https://github.com/ava1ar/customizepkg for automatically applying the patch to
xpad-dkms-giton rebuild on Arch. Gentoo supports applying patches natively.
Thanks! I took the approach taken by @rharish101 and it worked flawlessly! I just wanted to be able to remap the buttons in a easier way. Isn't there a option to make Steam recognize it as a Elite Controller?
I was using this for a while and I know for a fact that steam was detecting the back buttons, but I had to remap them manually by going through the controller config files as the configurator wasn't recognizing them. Now, however, steam doesn't detect the buttons at all... I know the driver is still working as the buttons show up in HTML gamepad tester, so i don't know what happened. Maybe a steam update borked it?
FWIW I had forked @ahungry kernel module some time ago for vader 3 pro and got it to show up in steam as an xbox elite controller so the paddles can be remapped there
https://github.com/martindmtrv/vader3/tree/steamdeck
This does work for me I'm still using it today with my vader 3 pro on my steam deck
Still it's not the cleanest solution, I think we would need to map it into xpadneo to get all the features that they have there (like vibration and such)
The maintainer there gave some idea of how we can effectively do this,
https://github.com/ahungry/vader3/issues/2#issuecomment-1938592952
We need to map the rawhid output from the controller to match what is expected for an xbox controller, then it could be supported in xpadneo
Though, there are some weird things with this controller that don't work exactly. Getting the paddles to appear under linux involves using the controller in android mode, and android mode supposedly does not support vibration according to the discussion here from @kakra (xpadneo maintainer):
Yes, there is no rumble function in the descriptor. Report 1 is a report that sends data from the device to the computer. You cannot use it in the other direction. As you can see, the other docs have Output in the description, which describes data being sent from the computer to the device. Rumble reports could be detected by looking at the description of output values 0..100 repeated at least 2 times (main motor, weak motor, but left and right trigger motor is also supported) and 3 timings (attack, sustain, release in units of 10^-2 seconds). Also, it's defined in another usage page.
Is there anything that can be done (doing some offset in this report_id to the right area?) - or is this output indicative of a lack of support at the hardware level for rumble over bluetooth?
There's no such thing as a fantasy offset into the report. The report clearly defines report sizes (in bits) and report counts for different usages (buttons, axes, ...) and a communication direction (input to the host, output from the host). Each of those report usage definitions (sizes, counts) accounts for the offset into the report.
And yes, this means: no rumble for this controller in Bluetooth mode...
https://github.com/atar-axis/xpadneo/pull/451#issuecomment-1889800998
FWIW I had forked @ahungry kernel module some time ago for vader 3 pro and got it to show up in steam as an xbox elite controller so the paddles can be remapped there
https://github.com/martindmtrv/vader3/tree/steamdeck
This does work for me I'm still using it today with my vader 3 pro on my steam deck
Still it's not the cleanest solution, I think we would need to map it into xpadneo to get all the features that they have there (like vibration and such)
The maintainer there gave some idea of how we can effectively do this,
We need to map the rawhid output from the controller to match what is expected for an xbox controller, then it could be supported in xpadneo
All of this is for dinput mode right? The point of this PR is to get the extra buttons under xinput mode, so that we don't have to worry about losing vibration etc.
At least under xinput mode it looks like there is no way to distinguish the Vader from a wired 360 controller as it presents identically.
I was testing some things with this PR and after searching I came across with this discussion on reddit which one of the participants probably is @ahungry.
They managed to make Steam recognize the buttons by forcefully setting a SDL_GAMECONTROLLERCONFIG after installing the drivers from this PR.
I tested myself, by putting the following environment variable on /etc/environment:
SDL_GAMECONTROLLERCONFIG="030081b85e0400008e02000004010000,Flydigi Vader 3 Pro,crcb881,platform:Linux,a:b0,b:b1,x:b2,y:b3,dpleft:h0.8,dpright:h0.2,dpup:h0.1,dpdown:h.4,leftx:a0,lefty:a1,leftstick:b9,rightx:a3,righty:a4,rightstick:b10,leftshoulder:b,lefttrigger:a2,rightshoulder:b5,righttrigger:a5,back:b6,start:b7,guide:b8,misc1:b1,touchpad:b16,paddle1:b14,paddle2:b11,paddle3:b13,paddle4:b12,"
It worked for the paddles! Steam recognized them, but didn't let me remap them per game, so it wasn't the solution that I was expecting.
Then I found this tool called input-remapper. With it, I was able to remap all the additional buttons, even making combination of buttons!
Maybe it can be of some help for you!
It might be worth adding an evemu-describe record to the SDL project issues so this device can be properly detected. Then after it has been integrated into SDL, SDL_GAMECONTROLLERCONFIG may not be needed any longer.
It might be worth adding an evemu-describe record to the SDL project issues so this device can be properly detected. Then after it has been integrated into SDL,
SDL_GAMECONTROLLERCONFIGmay not be needed any longer.
This was actually a good clue. I thought that if it was identical to a 360 controller then that SDL_GAMECONTROLLERCONFIG GUID string would be the same, but it's not. Looking in the SDL source code, it seems they pull this out of udev, and udev seems to be correctly identifying all the information:
$ udevadm info --no-pager /dev/input/by-id/usb-Flydigi_Flydigi_VADER3_Flydigi_VADER3-joystick
P: /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.1/usb1/1-1/1-1:1.0/input/input110/js0
M: js0
R: 0
U: input
D: c 13:0
N: input/js0
L: 0
S: input/by-path/pci-0000:08:00.1-usbv2-0:1:1.0-joystick
S: input/by-id/usb-Flydigi_Flydigi_VADER3_Flydigi_VADER3-joystick
S: input/by-path/pci-0000:08:00.1-usb-0:1:1.0-joystick
E: DEVPATH=/devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:08:00.1/usb1/1-1/1-1:1.0/input/input110/js0
E: DEVNAME=/dev/input/js0
E: MAJOR=13
E: MINOR=0
E: SUBSYSTEM=input
E: USEC_INITIALIZED=425423507609
E: ID_INPUT=1
E: ID_INPUT_JOYSTICK=1
E: ID_BUS=usb
E: ID_MODEL=Flydigi_VADER3
E: ID_MODEL_ENC=Flydigi\x20VADER3
E: ID_MODEL_ID=028e
E: ID_SERIAL=Flydigi_Flydigi_VADER3_Flydigi_VADER3
E: ID_SERIAL_SHORT=Flydigi_VADER3
E: ID_VENDOR=Flydigi
E: ID_VENDOR_ENC=Flydigi
E: ID_VENDOR_ID=045e
E: ID_REVISION=0104
E: ID_TYPE=generic
E: ID_USB_MODEL=Flydigi_VADER3
E: ID_USB_MODEL_ENC=Flydigi\x20VADER3
E: ID_USB_MODEL_ID=028e
E: ID_USB_SERIAL=Flydigi_Flydigi_VADER3_Flydigi_VADER3
E: ID_USB_SERIAL_SHORT=Flydigi_VADER3
E: ID_USB_VENDOR=Flydigi
E: ID_USB_VENDOR_ENC=Flydigi
E: ID_USB_VENDOR_ID=045e
E: ID_USB_REVISION=0104
E: ID_USB_TYPE=generic
E: ID_USB_INTERFACES=:ff5d01:ff5d03:ff5d02:fffd13:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=xpad
E: ID_PATH_WITH_USB_REVISION=pci-0000:08:00.1-usbv2-0:1:1.0
E: ID_PATH=pci-0000:08:00.1-usb-0:1:1.0
E: ID_PATH_TAG=pci-0000_08_00_1-usb-0_1_1_0
E: ID_FOR_SEAT=input-pci-0000_08_00_1-usb-0_1_1_0
E: DEVLINKS=/dev/input/by-path/pci-0000:08:00.1-usbv2-0:1:1.0-joystick /dev/input/by-id/usb-Flydigi_Flydigi_VADER3_Flydigi_VADER3-joystick /dev/input/by-path/pci-0000:08:00.1-usb-0:1:1.0-joystick
E: TAGS=:seat:uaccess:
E: CURRENT_TAGS=:seat:uaccess:
I do not understand how udev is able to get this information, but e.g. lsusb is not.
I was testing some things with this PR and after searching I came across with this discussion on reddit which one of the participants probably is @ahungry.
They managed to make Steam recognize the buttons by forcefully setting a
SDL_GAMECONTROLLERCONFIGafter installing the drivers from this PR.I tested myself, by putting the following environment variable on
/etc/environment:SDL_GAMECONTROLLERCONFIG="030081b85e0400008e02000004010000,Flydigi Vader 3 Pro,crcb881,platform:Linux,a:b0,b:b1,x:b2,y:b3,dpleft:h0.8,dpright:h0.2,dpup:h0.1,dpdown:h.4,leftx:a0,lefty:a1,leftstick:b9,rightx:a3,righty:a4,rightstick:b10,leftshoulder:b,lefttrigger:a2,rightshoulder:b5,righttrigger:a5,back:b6,start:b7,guide:b8,misc1:b1,touchpad:b16,paddle1:b14,paddle2:b11,paddle3:b13,paddle4:b12,"It worked for the paddles! Steam recognized them, but didn't let me remap them per game, so it wasn't the solution that I was expecting.
Then I found this tool called input-remapper. With it, I was able to remap all the additional buttons, even making combination of buttons!
Maybe it can be of some help for you!
this is what i originally did to allow me to map the extra buttons in steam. i figured out what my particular issue was from this, though; turns out that steam was now recognizing the controller under the name Atari Xbox 360 Game Controller, so my previous SDL_GAMECONTROLLERCONFIG wasn't working. After some editing and rebooting it fixed it right up! I might check out input-remapper anyway though, as manually editing steam controller configs is pretty annoying.