How to install ED on Linux using Wine [EXPERIMENTAL, NOT OFFICIALLY SUPPORTED]

Cmdr Eagleboy · Dec 26, 2018

Flyinspaghetti said:
I don't know if this is the same as the Windows bug, that one was more terrain randomly glitching out but could be reset by reentering the instance. This one is more a set thing in where the specific locations are always bugged and the terrain is generated the same way each time i.e. like the crater engulfing Traders Rest.

I'm thinking maybe there's an error that causes the generation to offset, I wouldn't be surprised if that specific crater can be found on the surface in a different location normally.

Considering IR code base for Nvidia drivers are same as far as I know, it seems compute shaders screw up somewhere and I think it is shared issue between Windows and Linux driver code bases. I might be wrong, but that feels well founded guess.

Yesterday again got terrain issues while playing on Windows, so...yeah.

Aquilinus · Dec 27, 2018

Aquilinus said:
[…]

The only problem now is that ED: Horizons refuses to start. The shader generation issue has already been solved as far as I can see, but when in the "preparing planet generation system" loading screen (the second screen after the shader generation thing), it slowly progresses to 12%, then the Frontier crash reporter pops up, but the loading continues to ~18%, and then the whole ED client crashes. I also saw my system memory (8GB) being nearly filled by the ED client at that point.
What could be the issue here? Graphics? Wine? I already saw this thread with exactly my problem, but that should be resolved since DXVK ~0.90?!
[…]

So after some more fiddling & research, I found out that LLVM was the culprit. I had the oibaf PPA for my graphics stack, which delivered only LLVM 7.0.1. The padoka PPA however has LLVM 8.0.0. Now the issues are gone and Horizons starts just fine.

Maybe this helps someone.

fuzzylunkinz · Dec 27, 2018

Aquilinus said:
So after some more fiddling & research, I found out that LLVM was the culprit. I had the oibaf PPA for my graphics stack, which delivered only LLVM 7.0.1. The padoka PPA however has LLVM 8.0.0. Now the issues are gone and Horizons starts just fine.

Maybe this helps someone.

Yep! Was just going to post this here because it will probably affect all/most AMD users. The shaders compile with LLVM 7 but that version of the compiler uses an insane amount of memory.

So if you are on AMD and having issues (or just want the game to load faster on AMD), see here https://github.com/doitsujin/dxvk/issues/36#issuecomment-449992460

FYI, this will potentially affect the amdgpu-pro driver as well, as if I remember correctly some combination of that driver packages LLVM for shaders. And if this is an issue there, note that upgrading the system LLVM with the Padoka PPA or similar will probably not help unless you uninstall the amdgpu-pro driver. Something to consider.

EdVaessen · Dec 27, 2018

I have a problem that might have to do with the fact that I compiled the NVIDIA drivers (NVIDIA-Linux-x86_64-415.22.01.run) against the kernel. Trying to get a good resolution in the ED demo version, I only managed to screw up my system so much that when leaving ED, the screen resolution had gone low and remained so. Rebooting does not help and since I am on OpenSuSE Leap 15.0, I do not know how to set the screen resolution back to 1920 x 1080. There seems to be no utility for that.

khaezaid · Dec 28, 2018

EdVaessen said:
I have a problem that might have to do with the fact that I compiled the NVIDIA drivers (NVIDIA-Linux-x86_64-415.22.01.run) against the kernel. Trying to get a good resolution in the ED demo version, I only managed to screw up my system so much that when leaving ED, the screen resolution had gone low and remained so. Rebooting does not help and since I am on OpenSuSE Leap 15.0, I do not know how to set the screen resolution back to 1920 x 1080. There seems to be no utility for that.

Do you not have nvidia-settings installed? If not, install that and use it to set your resolution.

Flyinspaghetti · Dec 28, 2018

EdVaessen said:
I have a problem that might have to do with the fact that I compiled the NVIDIA drivers (NVIDIA-Linux-x86_64-415.22.01.run) against the kernel. Trying to get a good resolution in the ED demo version, I only managed to screw up my system so much that when leaving ED, the screen resolution had gone low and remained so. Rebooting does not help and since I am on OpenSuSE Leap 15.0, I do not know how to set the screen resolution back to 1920 x 1080. There seems to be no utility for that.

Open up nvidia settings and in display configuration (advanced) make sure your viewport in & out (also panning) match.

fuzzylunkinz · Dec 29, 2018

EdVaessen said:
I have a problem that might have to do with the fact that I compiled the NVIDIA drivers (NVIDIA-Linux-x86_64-415.22.01.run) against the kernel. Trying to get a good resolution in the ED demo version, I only managed to screw up my system so much that when leaving ED, the screen resolution had gone low and remained so. Rebooting does not help and since I am on OpenSuSE Leap 15.0, I do not know how to set the screen resolution back to 1920 x 1080. There seems to be no utility for that.

This is honestly why I switched away from NVIDIA many years ago... way too much trouble with the kernel.

And the nvidia driver always compiles something against the kernel. They literally replace entire kernel subsystems to run as external modules.

EdVaessen · Dec 29, 2018

Flyinspaghetti said:
Open up nvidia settings and in display configuration (advanced) make sure your viewport in & out (also panning) match.

How does one open nvidia settings? Via Yast?

Flyinspaghetti · Dec 29, 2018

EdVaessen said:
How does one open nvidia settings? Via Yast?

Just type nvidia-settings in terminal or use the application launcher for the shortcut (you can then add to your dock or whatever).

Genar-Hofoen · Dec 30, 2018

fuzzylunkinz said:
This is honestly why I switched away from NVIDIA many years ago... way too much trouble with the kernel.

And the nvidia driver always compiles something against the kernel. They literally replace entire kernel subsystems to run as external modules.

One kernel module is compiled against the kernel and which is loaded. This contains the binary blob the GPU needs, as well as any necessary code interface glue. It's not replacing entire kernel subsystems, it's adding one module, similar to the idea of the nouveau.ko kernel module, for example.

Regards.

fuzzylunkinz · Dec 30, 2018

Genar-Hofoen said:
One kernel module is compiled against the kernel and which is loaded. This contains the binary blob the GPU needs, as well as any necessary code interface glue. It's not replacing entire kernel subsystems, it's adding one module, similar to the idea of the nouveau.ko kernel module, for example.

Regards.

I know what a kernel module is, but thanks for making an assumption about my knowledge and feeling the need to explain something (to a Gentoo user nonetheless).

Nvidia builds multiple modules, one of which is nvidia_drm which reimplements/ignores the rest of the kernel DRM subsystem. This is why it took so long for Nvidia to implement kernel mode setting, and why their KMS implementation is still so terrible for even just high resolution console output.

Genar-Hofoen · Dec 30, 2018

fuzzylunkinz said:
I know what a kernel module is, but thanks for making an assumption about my knowledge and feeling the need to explain something (to a Gentoo user nonetheless).

Nvidia builds multiple modules, one of which is nvidia_drm which reimplements/ignores the rest of the kernel DRM subsystem. This is why it took so long for Nvidia to implement kernel mode setting, and why their KMS implementation is still so terrible for even just high resolution console output.

Code:

$ lsmod | grep nvidia
nvidia_uvm            921600  0
nvidia_drm             49152  6
nvidia_modeset       1040384  20 nvidia_drm
nvidia              17313792  1054 nvidia_uvm,nvidia_modeset
drm_kms_helper        208896  1 nvidia_drm
drm                   495616  9 drm_kms_helper,nvidia_drm
ipmi_msghandler        65536  2 ipmi_devintf,nvidia

Okay, I sit corrected. Been a while since I checked what the nvidia stuff actually does

I seem to remember only seeing the one nvidia module in the past. Oh well. Mistakes were made.

fuzzylunkinz · Dec 30, 2018

Cheers

Legroeder · Dec 31, 2018

First of all a big thanks for all the collected infos!
I got it running on Arch Linux today using Lutris and wine tkg-3.21-x86_64.

Beside the Launcher is missing its content the game runs smoothly at around 60fps out here in the void... haven't had a chance to check the performance in the bubble near stations and other ships.

Just a quick go through how I got it working with Arch Linux.

Created a new Prefix for Elite (64-bit, tkg-3.21-x86_64)
Started wineconfig using Lutris
- Not installed wine-mono when asked by the popup
- Set windows version to Windows 7

Installed .NET 4.5.2, corefonts, quartz and vcrun2017 (DXVK is provided by Lutris)

Code:

WINEPREFIX=~/Games/EliteDangerous WINE=~/.local/share/lutris/runners/wine/tkg-3.21-x86_64/bin/wine64 winetricks dotnet452 corefonts quartz vcrun2017

Proceeded as normal - Installed the launcher, Downloaded EDH, start having fun

BurntJello · Dec 31, 2018

khaezaid said:
I suspect your issues with the controller have more to do with Steam and less to do with Proton. Remember when Steam released the Steam controller and added a way to rebind the steam controller as either a gamepad or as keyboard/mouse controls? Well, now that feature exists for other controllers too. It's been known to cause problems for some. You can try going into the controller settings in steam and turning off "Generic Gamepad Configuration Support".

As far as VR goes, according to proton logs I'm looking at, it appears as if ED does detect my Vive very briefly. It loads openvr_api.dll and vrclient_x64.dll. My Vive detects something is going on and shows me a load screen for about 30 seconds. However, the game unloads all VR stuff before it ever outputs anything to it. I'm not sure exactly why. It's rather difficult to make sense of the log, because there are many error messages, and most of them are harmless. I'll have to compare to the log for a known working VR title (ie. The Red Stare).

Also, I'm pretty sure you don't have to install dxvk with winetricks if you are using Proton. Proton comes with it's own version of dxvk, so as long as the wine prefix was created properly (ie. created by Steam), dxvk should already be working. I believe the above instructions are specific to people using standalone Wine. In any case, I've managed to run the game in non-VR mode without having to install dxvk with winetricks.

Frist!

ED is working in VR! https://imgur.com/a/ug8nA5h

Switched to steam beta + steamvr beta and it worked!
1. start steam VR
2. launch game in VR from steam
Quality is low. It has bad double-vision when looking around. This is disappointing because it looks fine in windows. (why is Async Reprojection Off ???)

I also rebuilt the steam proton prefix. (deleted the folder and let it make a new one, also using the ED proton from RedMcg)

Controls are still broken to the point of being unusable. I have disabled all the steam controller stuff, has made no difference.
Unchecked all controller boxes in settings and bigpicture. In game prefs set "Steam Input Per-Game Setting" to Forced Off. Steam Overlay is disabled (though we know that's a lie, it still loads and screws stuff up, at least it does on windows).

Any help on this is appreciated as the game is unplayable for me with steam/proton because of this.
Is there a way to launch the game through proton without steam? Wondering if that might leave out steam's controller hijack garbage... or how to kill the overlay because I guess that is to blame (can just rename/delete steamoverlay64.dll on windows to kill it and i dont know how to do it on linux).

alejandor · Dec 31, 2018

I have seen a noticeable drop in performance post Q4 release. My card is low-end (GT 730) so this might make it more evident.

RedMcG · Jan 1, 2019

BurntJello said:
ED is working in VR!

That's great news!

BurntJello said:
Is there a way to launch the game through proton without steam?

There is. You just need to setup your environment to use the steam runtime. The easiest way to do this is to turn on PROTON_DUMP_DEBUG_COMMANDS and use the `run` batch script it creates (usually under `/tmp/proton_USERNAME`). You can obviously modify it as you see fit (like remove the `/steam` option so ED runs standalone).

ED uses XInput for its controllers and Wine uses SDL for its XInput mappings. If you look under `/proc/<game_pid>/environ` you can see the environment being used for that linux process. In there you will see an environment variable called `SDL_GAMECONTROLLERCONFIG` which you can use for mapping your devices buttons. For example - I use a Logitech F310 Gamepad and the output in my `environ` is:

Code:

SDL_GAMECONTROLLERCONFIG=Logitech F310 Gamepad (XInput),a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3

This git repo has user provided mappings - so if your device is in there - you may be able to use one of those:
https://github.com/gabomdq/SDL_GameControllerDB/blob/master/data/SDL_gamecontrollerdb2.0.9.h

Just look under the `#if defined(__LINUX__)` section.

For testing - I didn't find anything great - but this might be your best option:
http://www.generalarcade.com/gamepadtool/

BurntJello · Jan 1, 2019

RedMcG said:
That's great news!

There is. You just need to setup your environment to use the steam runtime. The easiest way to do this is to turn on PROTON_DUMP_DEBUG_COMMANDS and use the `run` batch script it creates (usually under `/tmp/proton_USERNAME`). You can obviously modify it as you see fit (like remove the `/steam` option so ED runs standalone).

ED uses XInput for its controllers and Wine uses SDL for its XInput mappings. If you look under `/proc/<game_pid>/environ` you can see the environment being used for that linux process. In there you will see an environment variable called `SDL_GAMECONTROLLERCONFIG` which you can use for mapping your devices buttons. For example - I use a Logitech F310 Gamepad and the output in my `environ` is:

Code:

SDL_GAMECONTROLLERCONFIG=Logitech F310 Gamepad (XInput),a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3

This git repo has user provided mappings - so if your device is in there - you may be able to use one of those:
https://github.com/gabomdq/SDL_GameControllerDB/blob/master/data/SDL_gamecontrollerdb2.0.9.h

Just look under the `#if defined(__LINUX__)` section.

For testing - I didn't find anything great - but this might be your best option:
http://www.generalarcade.com/gamepadtool/

Cool. Thanks. I now have a script that can launch ED without steam and works just like in windows, just had to remove the extra params to EDLauch.exe ... once the game is running I can turn on/off HMD as I please.

This test also confirmed that it is indeed proton screwing with my buttons. Looking inside Steam/config/config.vdf I see it does list my controller... and that's the problem. I don't want it to. (at least I think I don't)
The problem: "start:b9"
Button9 is NOT "start". Button9 needs to just be Button9. I use it as my modifier button. I can't have it acting as ESC.
I tried deleting the button definition from that file, didn't work... it must be somewhere else too but I'm not sure where to look. [where is it]
So close... just need proton to treat my controller the same as wine does...

Captain Willard · Jan 1, 2019

Funny thread. Wasting time with a lame system that no one supports just to be different.
You go.

Flyinspaghetti · Jan 1, 2019

BurntJello said:
Frist!

ED is working in VR! https://imgur.com/a/ug8nA5h

Switched to steam beta + steamvr beta and it worked!
1. start steam VR
2. launch game in VR from steam
Quality is low. It has bad double-vision when looking around. This is disappointing because it looks fine in windows. (why is Async Reprojection Off ???)

I also rebuilt the steam proton prefix. (deleted the folder and let it make a new one, also using the ED proton from RedMcg)

Controls are still broken to the point of being unusable. I have disabled all the steam controller stuff, has made no difference.
Unchecked all controller boxes in settings and bigpicture. In game prefs set "Steam Input Per-Game Setting" to Forced Off. Steam Overlay is disabled (though we know that's a lie, it still loads and screws stuff up, at least it does on windows).

Any help on this is appreciated as the game is unplayable for me with steam/proton because of this.
Is there a way to launch the game through proton without steam? Wondering if that might leave out steam's controller hijack garbage... or how to kill the overlay because I guess that is to blame (can just rename/delete steamoverlay64.dll on windows to kill it and i dont know how to do it on linux).

That's great news it works at all, keep in mind all this is still work in process and best places to leave feedback on VR/rendering issues would be the Proton & DXVK githubs.

As for controls playing in the game directory in the control schemes folder delete the .binds files. When you load the game this will create a completely blank custom preset and load nothing else, obviously you have to go through the effort of rebinding everything yourself but it should stick.

alejandor said:
I have seen a noticeable drop in performance post Q4 release. My card is low-end (GT 730) so this might make it more evident.

Yes, not only a drop in performance in general but some locations have really severe drops that don't happen on Windows or before 3.3 on linux. For DWE2 I'll probably be playing on Windows due to this, as well as respecting the fact Ed commented this thread before about the so called technical issues.

Saying that I'm surprised you can even play on Linux with a GT 730.