KSP 1.4 Joystick not found under linux

[soulsource]

I've found a way to get my input working!

But first: The fact that there's a workaround should not stop the investigation of the original bug.

Advanced Fly-ByWire to the rescue! While the plugin has not officially been updated to KSP 1.4 yet, it can be recompiled against the new game dlls and the updated Toolbar with nearly no changes to the source code.

Edit 3: Scroll down to Edit 3 below, old text left for reference:

I don't know if I can post the dll I just compiled, as some modders are not too happy if someone else just recompiles their mod and uploads the dll... So, instead I'll just post a step-by-step guide of how I got it to work.

1. Install a C# compiler. I used Mono 4.4.1.0.
2. Download and install the old version of Advanced Fly-By-Wire. Delete the Toolbar mod that comes with it.
3. Download Toolbar Continued and install it.
4. Clone the git repo for Advanced Fly-By-Wire
5. In the Advanced Fly-By-Wire source tree edit the file ksp-advanced-flybywire-linux.csproj to have dependency hints point to the correct dll paths in your KSP 1.4 folder (don't worry about KSPUtil.dll, that one isn't needed any more). I've also added <DefineConstants>LINUX</DefineConstants> to all configurations, just to be sure, but I don't think it's required if you select the correct configuration when building.
6. In the same file fix the <PostBuildEvent> stuff. It'd try to copy the generated dll to the game folder. Maybe just remove that part.
7. Edit SDLController.cs: Replace the line

   SDL.SDL_PollEvent(out ev);

   with this:

   SDL.SDL_PumpEvents();

   The reason is that recent Unity versions use SDL for input handling (at least on Linux), so advanced fly-by-wire mustn't consume the input event. The value given back by PollEvent() has not been used anyhow, so obviously the call was only there to cause population of the event queue.

8. xbuild /property:Configuration=Release ksp-advanced-flybywire-linux.csproj
9. That should create a subfolder "obj", which should contain the new Advanced Fly-By-Wire dll file.
10. Replace the ksp-advanced-flybywire.dll in your GameData/ksp-advanced-flybywire with the newly built file.
11. Use the toolbar in a flight scene to set up your input and enjoy joystick/gamepad support in KSP 1.4.

Edit: I've just seen that @linuxgurugamer has forked the Advanced Fly-By-Wire repo with an additional patch so it does not require Toolbar. I haven't tried to build that one though.

Edit2: I've also opened a pull request on Github containing this one line code change.

Edit 3: I tried to reach out to the author of Advanced Fly-By Wire (Alexander Dzhoganov) if he minds if I upload an updated .dll for 1.4.x, but didn't get a reply. Therefore I just assumed he won't mind, and upload the dll here. Installation is simple: Download the latest Advanced Fly-By-Wire release from Github and install it. Delete the toolbar folder. Get Toolbar Continued and install it. Then download my Advanced Fly-By-Wire dll for 1.4 and replace the dll from the official release. Read on.

Edit 4: I just found out that the .dll file I uploaded in Edit 3 does not work with libsdl2-2.0.8 (and probably other versions as well...). I've only tested it with libsdl2-2.0.4, for which it seems to be working fine. I'll try to fix it so it works with libsdl2-2.0.8 too.

Edit 5: Okay, I've got my Advanced Fly-By-Wire dll from Edit 3 working with libsdl2-2.0.8. Not by changing the source code, but by setting an environment variable. Let me explain: Unity is using SDL internally, yet for reasons beyond my understanding it is not linked dynamically against the system installed libsdl2, but instead uses static linking for this lib. That's usually fine, but if mods try to load the system installed SDL2 version, incompatibilities might arise. Anyhow, luckily the SDL developers are aware of this problem, and offer a solution. So, all one has to do to get the mod working on systems with a newer libsdl2 version is to set the  SDL_DYNAMIC_API=<Path_To_libsdl2.so> environment variable. In other words, I now run my KSP install with following command line:

SDL_DYNAMIC_API=/usr/lib64/libSDL2.so LC_ALL=C ./KSP.x86_64

 

Edited May 4, 2018 by soulsource
Add info on how to get advanced fly-by-wire working if system-installed libsdl2 version is not the same as the one Unity was built against.

[UomoCapra]

The team is currently investigating this issue and we'll inform you when a definitive solution is found. 

Thanks for bringing this up  

[rispeed]

Same problem i really hope they fix this my joystick won't work with 1.4 using fedora linux. works fine on all previous versions.

[Badsector]

Please help with informations about your system https://bugs.kerbalspaceprogram.com/issues/17984 for solve this issue.

Thanks

[steve_v]

On 4/19/2018 at 4:06 AM, Badsector said:

Please help with informations about your system https://bugs.kerbalspaceprogram.com/issues/17984 for solve this issue.

I have done this, because Squelch asks for more info, and I keep the following out of the bugtracker because it doesn't really belong there...

My joystick is not a gamepad. SDL is correctly identifying the device and assigning it an ID, and it is correctly determining that it is not a gamepad. The comment re. "helping the effort" by adding your device to the GameControllerDB, complete with mappings to inputs like "leftshoulder" "start", "x" and "y" that do not exist on this device, is utterly ridiculous. As is the implication that these mappings not existing for a majority of devices is a problem the "Open Source Community" needs to fix.

My device is a generic USB-HID joystick, not a bloody xbox controller. SDL is working as intended. The problem here is that the game engine doesn't support anything but console-controllers, and things that pretend to be console-controllers.
Additionally, even when a device does pretend to be a console-controller, most of the time the game still doesn't identify axes properly.
None of this stupidity has anything to do with SDL, it's a bug that Unity introduced by switching to SDL2 input exclusively, then failing to implement it properly on their side.

How about let's stop faffing about with client-side workarounds and fix the real problem.

Edited April 21, 2018 by steve_v

[Kerbal101]

@steve_v When you speak of "console controllers", these things are usually different, because they talk MS-only "XInput".

This "Xinput"  is not related to neither "libinput", nor "xorg", its a relatively new protocol that was introduced by MS to replace classic joystick API.
The classic joystick API in MS world is called "DirectInput" and in Linux world - classic joystick API [ link ].

Both APIs talk through USB, however they return different values.
Typically in Linux, if a classic joystick (Joystick that talks classic protocol) is attached to software that listens for newer "Xinput", then software will not be able to detect it.
And if "Xinput" joystick is attached to software that listens to classic API, then software will incorrectly map keys.

Some joysticks allow to switch between the API, like can be seen [ here ] but also joysticks with classic API-only and "Xinput" API-only are sold and produced today, adding to the confusion.
This is a big headache today. In my humble opinion there is no advantage from "Xinput", its just a different language.
I guess its just another "  ' 'thanks' ', Microsoft " thing.

Unfortunately I am not a software developer, but in Windows there is software piece that allows to emulate (emit) classic joystick events to Xinput events, that is then detected by software.
It looks like Unity is using Xinput now and abadoned DirectInput, and this is a big problem for Linux until similar emulation layer is implemented ... or there is an option to add classic interface + switch in the settings.

The workaround I see at start of the page, that uses Fly-By-Wire mod basically uses a mod that can listen to classic API, you are effectively bypassing the "Xinput".

More information: [1], [2]

[steve_v]

1 hour ago, Kerbal101 said:

@steve_v When you speak of "console controllers", these things are usually different, because they talk MS-only "XInput"...

This is all well-and-good (and also very M$ specific), but the thing is, my device is not a game-controller, it doesn't use XInput GameController*, and it works perfectly well like that. Except in KSP.
SDL2 (which uses the new evdev driver) is reporting perfectly usable joystick events. So is SDL1, which uses the old joydev driver. I can hack together a little moving whatsit that uses SDL2 to access my joystick in about 10 minutes.
So either the Unity build KSP uses isn't actually using SDL at all, or it's only using part of the API (i.e. ignoring devices that don't use GameController). If Unity is insisting on using some new M$ specific API and ignoring everything else, this is still Unity's problem, and we shouldn't have to work around it.
And mapping the buttons ids to xbox-specific names is still ridiculous.

 

1 hour ago, Kerbal101 said:

Typically in Linux, if a classic joystick (Joystick that talks classic protocol) is attached to software that listens for newer "Xinput", then software will not be able to detect it.

Sure. Again, this is Unity's problem. If a ~20KB test application can detect and use my device, so can Unity.

 

1 hour ago, Kerbal101 said:

It looks like Unity is using Xinput now and abadoned DirectInput, and this is a big problem for Linux until similar emulation layer is implemented

It's a big problem for Unity, if they want to support joystick devices on GNU/Linux. It's not the job of the OS or the input abstraction layers to pander to the vagaries of one game engine.
If Squad has decided to use a game engine that lacks support for the most common joystick protocol on the market, and wants joysticks to work, then it becomes Squads problem too.
I still don't see this being up to "the open source community" or Linux to fix in any way. It's not broken. DInput works fine. SDL works fine. Evdev and joydev work fine. If you don't want to use them, you get to provide the emulation layer.

 

1 hour ago, Kerbal101 said:

or there is an option to add classic interface + switch in the settings.

Much better.

* Thanks Voidi, that's actually more accurate terminology WRT SDL2.

Edited April 21, 2018 by steve_v

[Voidi]

The problem coming up with 1.4 has nothing to do with Xinput or similar, as this is a Windows-only Part.
The problem is very good described here https://www.reddit.com/r/linux_gaming/comments/5xics8/a_big_problem_with_joysticks_in_linux_right_now/ (although there answering a different question)

TL, DR: with some update of the unity engine they moved from doing the input stuff for linux in Unity itself to a (crossplatform) libary named SDL2, but use only the higher-level, more abstract part of it (GameController API). Which requires that there is mapping specific for used joystick modell.
I suppose only Unity can solving this problem.

EDIT:
Somewhere the i read the GameController API have problems with Joysticks with a lot of buttons. This makes this part of Unity even more problematic for KSP

Edited April 21, 2018 by Voidi

[steve_v]

38 minutes ago, Voidi said:

with some update of the unity engine they moved from doing the input stuff for linux in Unity itself to a (crossplatform) libary named SDL2, but use only the higher-level, more abstract part of it (GameController API).

Indeed. To wit: "only using part of the API".

 

38 minutes ago, Voidi said:

I suppose only Unity can solving this problem.

I suppose this too.

Frankly, I find the "open source needs to fix this" attitude I saw in the bug report to be somewhat pathetic.

This entire situation is insane. @Unity3D: "Using the GameController API exclusively" is a moronic thing to do if you want anything other than (some) gamepads and steam controllers to work. Everyone else has figured this out already.

 

38 minutes ago, Voidi said:

EDIT:
Somewhere the i read the GameController API have problems with Joysticks with a lot of buttons.

The GameController API has problems with a lot of things that aren't gamepads, because it wasn't designed for things that aren't gamepads. Right now it's only viable purpose is to provide an easy way to make all the zillions of xbox controller clones work like xbox controllers. Using it for generic joysticks is madness.

 

Edited April 21, 2018 by steve_v
Edit to the edit.

[AlexO]

Same under KSP 1.5.1

What is the status?

[Dafni]

48 minutes ago, AlexO said:

Same under KSP 1.5.1

What is the status?

Tiny grain of hope this gets fixed in 1.6.

 

If the unity version persists the chance is near zero I believe.

Edited December 11, 2018 by Dafni

[steve_v]

Reviving for status update: Still no fix as of 1.7.3, no news from SQUAD on progress, priority, or ETA.

As of ~11 months ago: "We are unable to provide a date as to when that task may be prioritized at this stage."
Translation: "We're not going to do anything about it."

 

On 3/27/2018 at 7:15 AM, UomoCapra said:

The team is currently investigating this issue and we'll inform you when a definitive solution is found.

The team is currently doing nothing whatsoever about this, since all potential solutions would require coding effort from SQUAD. As such you will never be informed of any solution as nobody is actually working on one, the PR team is fully occupied hyping DLC anyway.
There, FTFY.