• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Linux Gamepads are not working on Linux (Ubuntu)

thom

Member
It appears that gamepads aren't working properly on Linux (Ubuntu). After some tests I have noticed the following:
-The gamepad slot used is not in the 0-11 range, but will start at 12.
-The buttons of XInput (Xbox) gamepads are also assigned wrong on Linux, for example if you press the "LT" button it detects "right stick x+", while PS4 controllers have the right buttons assigned.
-Axis values are wrong.
-Remapping the buttons using gamepad_test_mapping() does not work, the game will crash if you try it on Linux.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
I've also noticed this myself. Didn't notice the "starts at 12" thing, though, that might help solving my issues.

-Remapping the buttons using gamepad_test_mapping() does not work, the game will crash if you try it on Linux.
The manual claims this isn't supported, so that makes sense.

-The buttons of XInput (Xbox) gamepads are also assigned wrong on Linux, for example if you press the "LT" button it detects "right stick x+", while PS4 controllers have the right buttons assigned.
This seems to be a issue on the driver level (below GM), I debugged my controller using the jstest-gtk program and some buttons/axes were mixed up (like the right stick horizontal position being controlled by one of the shoulder buttons).
 

Yal

🐧 *penguin noises*
GMC Elder
I did some experimentation, and I found out the following:
  • For me, gamepads started being found at slot 20. (0-indexed) Thus, the first gamepad slot is machine-dependent. It definitely doesn't stick to the range specified in the manual.
  • Gamepad layout found by GM doesn't match GM's gamepad_ constants nor the layout reported by jstest-gdk.
I've submitted a bug report on this.
 

Yal

🐧 *penguin noises*
GMC Elder
The tutorial also claims that only slots 0-11 will be used (with provisions for functionality being slightly different on Android but no other platform differences pointed out)... and this wasn't the case with neither my nor @thom's testing. In fact, both of us exclusively got numbers outside of this range.

1593805260859.png

Either the manual or the code should be updated to clarify this (preferably the code, since it's consistent for every other platform - at least if you trust the wording in the manual; and I'd rather have a notice that it's not supported at all for the linux target than having to handle all the "under the hood" stuff myself with no documentation of how it works).

In my case, even if I'd blindly use the correct ID from an asynchronous event, I need to know what the valid range of devices are for a bunch of different things (controller customization being one of them - a potentially infinite menu wouldn't fit on the screen).
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Yup, I agree, but I just wanted to point out that with the async event, you can at least get a pad index without having to worry about the actual index value.
 

Yal

🐧 *penguin noises*
GMC Elder
It's good to know it's an option, it just wouldn't work particularly well with the way my game is structured (gameplay and menu objects are completely separated, so I'd need to duplicate the asynchronous events over a large amount of objects; right now I pretend to read gamepad input everywhere, but the script that actually reads it does nothing for an unplugged device, so it never generates events - thus nothing needs to be aware of whether a gamepad is plugged in or not and the logic gets a lot simpler. I still display the connectedness status to the player where needed, but under the hood there's no difference between a disconnected gamepad and a gamepad nobody is pressing buttons on for 99% of objects). Overall it feels safer to check the current status when needed than to keep track of changes and intuit the state, too... there's always that risk of desync.

But yeah, my complaint boils down to "the reality and the manual doesn't match". Since there's a lot of emphasis on the 0-11 limit, it definitely looks like a bug. I've always assumed that whatever the device enumeration is host-side, GM abstracts it away so the gamepads are mapped to slot 0-11 in the order they're found... on my linux computer, the gamepads get mapped to device files with numbers 1 and 2, so I'm completely clueless as to why the internal numbering would jump to 20 joystick-side.
 

kburkhart84

Firehammer Games
@Nocturne I agree that this is a pretty big concern. I've never messed with testing my input system on Linux or Mac...but since it is 100% gml it should in theory work fine. However...since the manual is pretty clear that there is only gamepad indices 0 - 11, that is all I've set my input system to use. Instead of relying on async events, it loops through whatever gamepads are connected, but won't go over 11. Do you think you could clarify with the internal team what may be going on there? It seems to me to be either a bug or incorrect documentation.

Honestly, the way the documentation makes it out makes the most sense to me. It is a set of known values, with the first 4 corresponding to XInput, and the next 8 being DInput(well....non-XInput at the least). I would have thought based on this that the engine is polling all gamepads that are connected, and simply assigning them IDs from 0 - 11. But the above information, where someone saw ID 20.... that seems like a bug to me.
 
  • Like
Reactions: Yal

Yal

🐧 *penguin noises*
GMC Elder
Honestly, the way the documentation makes it out makes the most sense to me. It is a set of known values, with the first 4 corresponding to XInput, and the next 8 being DInput(well....non-XInput at the least). I would have thought based on this that the engine is polling all gamepads that are connected, and simply assigning them IDs from 0 - 11. But the above information, where someone saw ID 20.... that seems like a bug to me.
Speaking of this, clarifying which platforms treats XInput as a special case and which ones treat all 11 slots the same could also be nice - I'm assuming only Windows has special XInput treatment and the gamepads just have a fallback on the other platforms? (When testing with a DInput and an XInput gamepad on my Linux machine, they were jumbled together in adjacent slots 20 and 21)

(Also, if ranges outside 0-11 are to be expected, getting new read-only global variables gamepad_first and gamepad_last for the slot range could be useful for all potential iteration needs - the thing where android phones can't use slot 0 because it's used by generic bluetooth devices could also benefit from this)
 

kburkhart84

Firehammer Games
Speaking of this, clarifying which platforms treats XInput as a special case and which ones treat all 11 slots the same could also be nice - I'm assuming only Windows has special XInput treatment and the gamepads just have a fallback on the other platforms? (When testing with a DInput and an XInput gamepad on my Linux machine, they were jumbled together in adjacent slots 20 and 21)

(Also, if ranges outside 0-11 are to be expected, getting new read-only global variables gamepad_first and gamepad_last for the slot range could be useful for all potential iteration needs - the thing where android phones can't use slot 0 because it's used by generic bluetooth devices could also benefit from this)
This all makes sense to me. If it were a documented feature that way, I could easily code my input system accordingly. Right now I'm depending on 0 - 11.

Honestly, I'm thinking that since Linux is simply a market with less influence, they just haven't gotten around to fully integrating the whole 0 - 11 indices mapping for it, rather they are just using some number the OS is giving them. To me, that's a bug. But as you say, if it IS intentional, then something should be done either to verify the range of IDs, or to at the least document what is going on. Otherwise, they should finish the code making it function equally to Windows where possible, and documenting when they can't(like XInput for example).
 

Yal

🐧 *penguin noises*
GMC Elder
they just haven't gotten around to fully integrating the whole 0 - 11 indices mapping for it, rather they are just using some number the OS is giving them.
The "on android, index 0 is used by bluetooth devices and can't be used" thing also smells of this... there's no conceptual reason for the slots to not start at 0 and go up to <max supported value>, fully abstracting the OS's mapping of the devices.
 

kburkhart84

Firehammer Games
The "on android, index 0 is used by bluetooth devices and can't be used" thing also smells of this... there's no conceptual reason for the slots to not start at 0 and go up to <max supported value>, fully abstracting the OS's mapping of the devices.
100% agree...this is why I believe they simply haven't "finished" coding these things anywhere except for Windows. There is no reason we should have to care that index 0 is stuck that way, since theoretically that is on the OS side, not on the GML side. I don't necessarily expect full feature parity between all platforms...but this is one of those things that should in general match up, except maybe where XInput is concerned. So I would expect it to be something where on non-windows platforms, devices 0 - 3 maybe don't function(as they were reserved for XInput). The reason I would agree with that is because the coding internally for devices 0 - 3 isn't the same as 4 - 11, so I could understand if it was easier for them to simply not do anything for 0 - 3 on other platforms, for consistency sake. The alternative would be to use different functions between XInput and DInput, but I don't think that's necessary.
 
Top