I just bought a new gamepad: Trust GXT 540 Yula. Upon plugging it in the device is detected and lights up accordingly. The issue I seem to be having is it refuses to work under Xinput mode: It will only function properly when the switch is flipped to Dinput. The device is detected in both cases but under X-input the buttons are simply ignored and no actions are registered (neither any buttons nor moving the thumb pads). I can use it fine under D input for now... however since I hear X input is the more modern and correct system, I was wondering if this is a known issue and what could be causing it.

My Linux distro is the KDE version of Manjaro OS. Kernel 5.13.5. X11 Plasma session, not using Wayland yet due to its issues with monitor standby.

lsusb calls the controller by different device names based on the active mode.

dinput (working):

xinput (not working):

Do you have xpad installed and running?
https://github.com/paroj/xpad

The only xpad in my system packages is a sticky notes application. That says it's a kernel module: I use only the officially built kernel otherwise I'd break my system. Is it not builtin to the kernel by default? If so is it something I should check with systemctl?

https://github.com/paroj/xpad/issues/119

Someone pointed me to this issue. Looks like it might be what I'm experiencing too: The effects described are exactly the same. Not sure how to test it to be sure beyond doubt though.

I'm not sure on Manjaro, but it is included with Ubuntu. You can check for its presence (as in whether or not its presently loaded) with lsmod. On the system I have with a generic Xbox gamepad attached it shows up as loaded, and on another (without a gamepad) it does not. This thread may also be informative: https://unix.stackexchange.com/quest...h-a-usb-device

If your distro has 'usb-devices' run that (it is part of usbutils), and it will show what driver is loading for the device - it should be xpad when in xinput mode. If that's happening, and you still have no input, then the thread you found may apply to your controller. Do you have another, different, xbox gamepad to try out?

lsmod confirms I have xpad running:

usb-devices command lists the controller as follows (set as X input):

Confirming xpad issue 199 is the cause for my issue: Upon running the fixcontroller.py script provided as a workaround, the OS senses all inputs on the gamepad under x-input as well. Really hope that bug can be fixed soon!

The sticks and buttons are probably just mapped wrong. I'd strongly suggest that you at least try just using the standard kernel drivers and using a program to map them properly. I use this one:

https://generalarcade.com/gamepadtool/

That generates a command to set the SDL_GAMECONTROLLERCONFIG environment variable, which you'd paste into ~/.profile.

That should solve your problem.

It's not an issue with button mapping: Once the device works in this mode all buttons and dpads work just as intended. It seems to be a problem with initializing the device correctly via USB and sending it an activation / wakeup signal.

MirceaKitsune: Glad you were able to sort it (even if needing to run that script is a bit of a hack), and good to know the distro is loading the proper driver at least.

Considering the information in that issue: Can anyone suggest a better workaround to using that python script, in order to send whatever activation signal the device expects over USB? A user on Reddit suggested messing with the udev rules, I never did anything like that in the past and don't even know where to begin nor what to change them to. I tried echoing stuff to the device (echo 1 > /dev/bus/usb/005/011) however this only gives me an invalid argument error. Please let me know what comes to mind, would appreciate help in solving this somehow, thank you.

A super 'brute forcy' kind of idea that comes to mind would be to throw it into rc.local, but this makes two assumptions:

1) The controller is always (or almost always) attached to the machine
2) That 'fixcontroller.py' solves the problem until next reboot (or if you manually hotplug the controller)

If both of those conditions are met, or reasonably met, just call that 'fixcontroller.py' from rc.local on startup - hopefully that would work (and I'd like to believe if it didn't, it would provide a clear error message as to why not).

If #2 isn't met, as in it appears to 'time out' then I'd consider running it as a cron periodically as well (once you figure out what the 'time out' period is like and confirm the 'time out' isn't due to some power saving thing that you can defeat), and hope it doesn't cause chaos if it runs while a game is also running.

If #1 isn't met there's probably some nice way to have it trigger on a hotplug detect event, but you'd need someone with more bash-fu than me to help you do it. Some quick googling found this thread: https://unix.stackexchange.com/quest...n-a-usb-device which may be somewhere to at least start.

Finally, the other idea is to get a controller that works more properly with xpad. The one I have used says 'PDP' on it, and has had no issues, nor was it very expensive (I think it was around $20 US). I know that isn't a great answer ("go spend money") if there's a 'free' software fix, but long-term it may be less headache to just have more compatible hardware.

That would work in theory, however I'm looking for a less hacky solution. Also I shut down the controller from my USB hub when not using it, might start doing this with some devices to not waste power or wear them out.

That's okay. Will wait for someone with more knowledge in bash and device files to suggest a solution. Just hope there is an easier one handy.

As for getting another controller that's out of the question I'm afraid: I got this as part of a gift an online store gave me, wouldn't have had the money for such a thing otherwise. It's the only good model I could find at a decent price, nothing as good is currently available to me. It also works and feels great otherwise, I love it! It just has this issue of acting as a knockoff Xbox controller when set to X input mode, a stupid design choice by Trust I agree... everything beyond that is perfect with this model to me, I honestly recommend it in fact (though if anyone buys one expect running into annoyance for now).

Also PR #120 in xpad is said to fix my issue. For some mysterious reason though it suddenly went inactive two years ago

All makes sense - I think having a custom udev rule would be the ideal then (or just get used to manually running that script whenever you plug the device in, which is what I'm assuming you're doing presently), but you'll either have to play with it until you can get it working, or try finding someone to help teach you what to do.