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

Some news on Wine; bug 46208 has been fixed:
https://bugs.winehq.org/show_bug.cgi?id=46208

This means from 4.2, the futex patch from wine staging will no longer be required. However, wine staging will still be required for the NormalizeString functionality (required for Keyboard functionality).

I also found a bug introduced in 4.1. If you are using an Intel CPU, the registry value of PROCESSOR_ARCHITECTURE is set incorrectly. This results in the launcher only offering the demo (as it thinks your machine is 32-bit). I have submitted a fix to the mailing list.

For now, the work-around is to fix the PROCESSOR_ARCHITECTURE value manually (it should be "AMD64"). Or to avoid 4.1.

Also - an observation I thought I'd share: if you launch ED with the '/steam' option (for example: 'wine64 EDLaunch /novr /steam') - then the launcher will display correctly (as in the launcher glitches don't occur). So that's odd.

I read a little about that a month ago, is the performance decent with the method they settled with? I don't understand much but from what I read the futex patch performed better than the alternative but they didn't want to use the futex method due to other things?

Also considering the whole idea behind getting this sorted in wine devel was for it all to be eventually pulled into proton someday, if NormalizeString & other stuff can't yet be pulled upstream is there any chance of them being looked at again with Proton?

Wanted to just quickly dip in and add that Nvidia *finally* fixed compute shaders regression that caused big disformations on ice planets on Windows (418.81 driver). It is worth to look after when Linux driver update lands if that fixes those issues we had with Engineer bases being sunk into the ground.

Latest Linux driver is actually 418 branch a few days before the Windows one however that still has the issue. Maybe the next one will have it, I got my second account in the bubble at Bakers Prospect ready to test differences if another drops soon.

I've never used Lutris myself, so I'm not entirely sure, but x86_64 might refer to the type of prefix (as in it'll support 64-bit). The ED Launcher however is a 32-bit .NET app that needs to be ran as a 64-bit process; so it needs to be started with wine64. But I get the impression from this post:


that you can't use wine64 from within Lutris. I think you'll need to run it manually from a Terminal. Hopefully someone here with experience running under Lutris will be able to comment with a bit more authority.

Yes, you can but you just need to set it to "Custom" and manually direct it to the wine64 executable.
 
I read a little about that a month ago, is the performance decent with the method they settled with? I don't understand much but from what I read the futex patch performed better than the alternative but they didn't want to use the futex method due to other things?

Performance seems to be the same. The patch submitted for bug 46208 will use RtlWaitOnAddress instead of the implementation they did have for Condition Variables (which had a design flaw that caused ED to freeze). But RtlWaitOnAddress currently has a futex path anyway. So the upshot is that performance is much the same; but if futex isn't available in your kernel - then whilst performance will take a hit - with the bug fixed, it won't freeze.

But I saw on the mailing list that another patch has been submitted for bug 45524. This patch is pretty much the same one we we've been using in wine-staging (it adds a futex path directly to Condition Variables). It's not been accepted in to the master branch yet - but that's only because patches aren't accepted on the weekend and I assume this too will be in 4.2.

Also considering the whole idea behind getting this sorted in wine devel was for it all to be eventually pulled into proton someday, if NormalizeString & other stuff can't yet be pulled upstream is there any chance of them being looked at again with Proton?

Yeah - that's my hope. I suspect the next Proton release we see will be 4.0, and these patches are going to be in 4.2 - so we missed that boat. But I'll submit another pull request when it comes out with whatever patches are required. They seemed more likely to pull patches that were already in wine as oppose to wine-staging, so these new ones might get accepted. But hopefully I can also convince them to take the NormalizeString patchset as well.
 
Yeah - that's my hope. I suspect the next Proton release we see will be 4.0, and these patches are going to be in 4.2 - so we missed that boat. But I'll submit another pull request when it comes out with whatever patches are required. They seemed more likely to pull patches that were already in wine as oppose to wine-staging, so these new ones might get accepted. But hopefully I can also convince them to take the NormalizeString patchset as well.

Good news! The NormalizeString patchset was just accepted in to the wine master branch. My fix for PROCESSOR_ARCHITECTURE and the direct futex path for condition variables were also accepted.

So I just compiled and tested the latest and Elite seems to work perfectly with no need for any additional patches (from wine-staging or elsewhere). So from 4.2, wine-devel will be sufficient and any Proton version rebased from 4.2 onward should run Elite without the need for a custom version!
 
Latest Linux driver is actually 418 branch a few days before the Windows one however that still has the issue. Maybe the next one will have it, I got my second account in the bubble at Bakers Prospect ready to test differences if another drops soon.

I've made my way over to Bakers Prospect now too. I tested with 396.54 and 415.27 before adding a 'me too' to your bug on the nvidia developer site.
 
First of all, kudos to all you guys for working on this and nutting things out; even submitting patches to upstream projects!

However, as a newcomer to Elite on Linux (but neither Elite nor Linux), it would be great if the OP could include just a touch more information.

For example, I've never much used Wine before; when I use Linux I use Linux native software. So as a "dumb" approach, I checked out the repo of my distro. Debian 9 has wine 4.0 from the stretch backports which appears to be MUCH later than the OP-suggested version of 3.19.

Installed and following the instructions, I fail at winetricks installing vcrun2017; the winetricks version in Debian only has vcrun2015.

----

So after skimming this thread, presumably that version of wine would have failed miserably anyway, despite OP.

So if I could just make the suggestion that OP should mention that vanilla-distro versions of wine are not really sufficient (regardless of actual version number), and to download directly from winehq.org and winetricks.org.

Hoping to give this another try soon; wanting to ditch Windows again (ED is literally the only reason I use it).
 
Good news! The NormalizeString patchset was just accepted in to the wine master branch. My fix for PROCESSOR_ARCHITECTURE and the direct futex path for condition variables were also accepted.

So I just compiled and tested the latest and Elite seems to work perfectly with no need for any additional patches (from wine-staging or elsewhere). So from 4.2, wine-devel will be sufficient and any Proton version rebased from 4.2 onward should run Elite without the need for a custom version!

Than you very much for your work! So great to have people like you around to make these things happen.
 
Sooo everything was working fine when the game got stuck trying to open the system map. I killed it and now EDLaunch only offers the "Play Demo" option. I have tried reinstalls, reboots, and nothing changes. I observe that in the wineprefix only the demo folder exists, so the launcher is not even downloading the full game.

I have tried installing it in a windows machine and it works OK, so it is not a problem about my account being flagged for some reason.

I thought it might be related to the game detecting a 32bit platform, but I'm launching as always with wine64.

I can't think of anything that has changed. Any ideas?
 
Sooo everything was working fine when the game got stuck trying to open the system map. I killed it and now EDLaunch only offers the "Play Demo" option. I have tried reinstalls, reboots, and nothing changes. I observe that in the wineprefix only the demo folder exists, so the launcher is not even downloading the full game.

I have tried installing it in a windows machine and it works OK, so it is not a problem about my account being flagged for some reason.

I thought it might be related to the game detecting a 32bit platform, but I'm launching as always with wine64.

I can't think of anything that has changed. Any ideas?

There was a bug introduced in 4.1 of wine that reports the PROCESSOR_ARCHITECTURE incorrectly. You either need to revert to 4.0 or manually change the value to be AMD64 (just look in system.reg for PROCESSOR_ARCHITECTURE).

Note that if you revert to 4.0 it'll only correct itself on the second launch
 
There was a bug introduced in 4.1 of wine that reports the PROCESSOR_ARCHITECTURE incorrectly. You either need to revert to 4.0 or manually change the value to be AMD64 (just look in system.reg for PROCESSOR_ARCHITECTURE).

Note that if you revert to 4.0 it'll only correct itself on the second launch

Changing the value did it. Thanks a lot!
 
Changing the value did it. Thanks a lot!

No problem. Note that the value will be changed by Wine every time you start-up though. I've been running the following before each launch of ED:
Code:
sed -i 's/"Intel64"/"AMD64"/' "${WINEPREFIX}/system.reg"

I've submitted a patch that fixes this which has been accepted and will be in 4.2 of Wine.
 
Last edited:
Hey Cmdrs,

First of all thanks for the great installation guide, awesome job.
I came here to find a solution to my own problem but I see many different issues causing agony for others but mine.

Let me add some info I've figured when I had graphics performance issues:

1. Planetary base at the bottom of the pothole. It's a graphical bug but it is related to the Nvidia driver (no info about AMD). I did my research and found that the actual planet surface rendering issue exists in the Windows world too. There's a bug report form a CMDR somewhere (am sorry, didn't save the link back then) that describes the exact same issue: can't land on base, base rendered underground. In that topic he actually mentiones a bug that exists for the very latest NVidia driver that casuing the issue and reverting to one older solves the problem. I can confirm this on Ubuntu 18.04 solves the planetary surface issue.

2A. Performance/FPS is subpar even on high-end rigs. For me, salvation came from two solutions. First I have a GTX 1060 which should run the game fairly well, but it actually struggled... or something struggled in my rig causing stuttering and massive FPS drops over time. Switch ON vertical sync in game and set the FPS limit to 40 or 60 this modertates the FPS drop for me, well I have none since.

2B. And there's a second thing worth trying. I'm running Wine 4.1 Staging. The wine config has a "staging" tab, there untick the CSMT box and tick the VAAPI box. This skyrocketed my FPS even without the FPS limit and vsync.

3. The keyboard bindings are dead after loading the game, meaning the keyboard not responding neither in game menus nor in game, and it solved itself after once or twice restarted the game. That's pretty bad. The inconsistency of the bug ocurrence lead me to find the predefined bindings' folder and deleted all predefined key bindings which I certainly won't use XBox ctrl, etc., leaving a the file list as short as safely possible (after making a safety copy of the whole folder of course) solved this issue for me. Be aware of if you do a game file validation it will download all the missing files so you may have to do this after a bigger patch again.

4. My actual issue. I've played at the morning gametwo days ago without any trouble, but at the evening my launcher said that the game isn't installed (the game foldera are intact), installing caused a short syncing and now I have only Play Demo button. The log shows that I have no access to the full game. The Technical support asked me to reinstall but that didn't solve the issue either. I've found a reference from a tech staff that says the Windows OS must be 64bit otherwise the game will offer the demo only. While I've changed nothing in the last 2 months in the game environment (running with WINEPREFIX=/media/gary/Backup/LinuxGames/ED wine64 "c:/Program Files (x86)/Frontier/EDLaunch/EDLaunch.exe") and both my host OS (Ubuntu 18.04 and the wine are 64bit) and the OS in winecfg is set "windows 7 the ED client sees the environment as Win XP and 32bit.

Game launcher > Options > Display Hardware Suervey...
Code:
<?xml version="1.0" encoding="utf-16"?>
<DxDiag>
	<SystemInformation>
		<Time>2/14/2019, 07:19:10</Time>
		<MachineName>gary-MS-7816</MachineName>
		<OperatingSystem>Windows XP Professional</OperatingSystem>
		<Language>English (Regional Setting: English)</Language>
		<SystemManufacturer />
		<SystemModel />
		<BIOS />
		<Processor>Intel(R) Core(TM) i5-4690 CPU @ 3.50GHz(8 CPUs), ~3900MHz</Processor>
		<Memory>15977MB RAM</Memory>
		<PageFile>5008MB used, 10968MB available</PageFile>
		<WindowsDir>C:\windows</WindowsDir>
		<DirectXVersion>= "DirectX 9.0c (4.09.0000.0904)</DirectXVersion>
		<DXSetupParameters>Not present</DXSetupParameters>
		<DxDiagVersion />
		<DxDiagUnicode>1</DxDiagUnicode>
		<DxDiag64Bit>0</DxDiag64Bit>
	</SystemInformation>
</DxDiag>

I guess it has something to do with Wine Staging and Vulkan dailies... Does anyone have a solution for this?
 
Hey Cmdrs,

First of all thanks for the great installation guide, awesome job.
I came here to find a solution to my own problem but I see many different issues causing agony for others but mine.

Let me add some info I've figured when I had graphics performance issues:

1. Planetary base at the bottom of the pothole. It's a graphical bug but it is related to the Nvidia driver (no info about AMD). I did my research and found that the actual planet surface rendering issue exists in the Windows world too. There's a bug report form a CMDR somewhere (am sorry, didn't save the link back then) that describes the exact same issue: can't land on base, base rendered underground. In that topic he actually mentiones a bug that exists for the very latest NVidia driver that casuing the issue and reverting to one older solves the problem. I can confirm this on Ubuntu 18.04 solves the planetary surface issue.

2A. Performance/FPS is subpar even on high-end rigs. For me, salvation came from two solutions. First I have a GTX 1060 which should run the game fairly well, but it actually struggled... or something struggled in my rig causing stuttering and massive FPS drops over time. Switch ON vertical sync in game and set the FPS limit to 40 or 60 this modertates the FPS drop for me, well I have none since.

2B. And there's a second thing worth trying. I'm running Wine 4.1 Staging. The wine config has a "staging" tab, there untick the CSMT box and tick the VAAPI box. This skyrocketed my FPS even without the FPS limit and vsync.

3. The keyboard bindings are dead after loading the game, meaning the keyboard not responding neither in game menus nor in game, and it solved itself after once or twice restarted the game. That's pretty bad. The inconsistency of the bug ocurrence lead me to find the predefined bindings' folder and deleted all predefined key bindings which I certainly won't use XBox ctrl, etc., leaving a the file list as short as safely possible (after making a safety copy of the whole folder of course) solved this issue for me. Be aware of if you do a game file validation it will download all the missing files so you may have to do this after a bigger patch again.

4. My actual issue. I've played at the morning gametwo days ago without any trouble, but at the evening my launcher said that the game isn't installed (the game foldera are intact), installing caused a short syncing and now I have only Play Demo button. The log shows that I have no access to the full game. The Technical support asked me to reinstall but that didn't solve the issue either. I've found a reference from a tech staff that says the Windows OS must be 64bit otherwise the game will offer the demo only. While I've changed nothing in the last 2 months in the game environment (running with WINEPREFIX=/media/gary/Backup/LinuxGames/ED wine64 "c:/Program Files (x86)/Frontier/EDLaunch/EDLaunch.exe") and both my host OS (Ubuntu 18.04 and the wine are 64bit) and the OS in winecfg is set "windows 7 the ED client sees the environment as Win XP and 32bit.

1. Known issue, apparently it has been silently fixed in Windows and we are waiting for a similar response with the Linux driver.

2. With the exception of shader caching, the bulk of the performance issues Linux vs Windows stem from new graphical effects added in 3.3. The ultra volumetric setting appears to be the biggest framerate killer in some stations and planetary rings, knocking this down to high helps. It may be the case this fixes itself over time with newer iterations of dxvk and drivers.

3. Yes known issue which appeared in 3.3, deleting the extra presets help avoid the conflict.

4. Literally a couple of posts above redmcg describes the issue and solution.
 
1. Known issue, apparently it has been silently fixed in Windows and we are waiting for a similar response with the Linux driver.

2. With the exception of shader caching, the bulk of the performance issues Linux vs Windows stem from new graphical effects added in 3.3. The ultra volumetric setting appears to be the biggest framerate killer in some stations and planetary rings, knocking this down to high helps. It may be the case this fixes itself over time with newer iterations of dxvk and drivers.

3. Yes known issue which appeared in 3.3, deleting the extra presets help avoid the conflict.

4. Literally a couple of posts above redmcg describes the issue and solution.

Thanks on number 4. I've read those posts but it's not straight obvious what is the issue they are talking about. I'll give it a go.
As of 1-3. I've just shared my experience on those otherwise known issues it may help somebody else to tackle them too.

Great community! Thanks again for the thread!
 
Does this issue happen on Windows? Or is it a Wine specific?

I use the 'Default Context' without any modifications and I never have this issue.

It must only affect joysticks/controllers AFAIK, probably gets screwed by trying to load more than one joystick preset at a time. Maybe due to the way wine handles joysticks it probably doesn't distinguish one from the other very well.

I haven't experienced it myself in Windows, I've seen posts about preset issues although I don't think it's the same.
 
Does this issue happen on Windows? Or is it a Wine specific?

I use the 'Default Context' without any modifications and I never have this issue.

There are several reports from Windows of the client doesn't load the keybindings or even loss of settings. The symptoms are a little sporadic but all show that the game client acts a bit hectic on some box.

A clearer description of my case: After the game loaded and displays the main game menu the keyboard completely irresponsible though the mouse still acts as normal and can traverse the menus or even start the game, but the keyboard remains disabled. Additional to that traversing to the settings menu by mouse all menu is accessible but not the Controls, that doesn't open when the keyboard are irresponsible.

So my solution - based on an assumption that there may be a race condition wile loading the default key bindings - is to remove all clutters from
Code:
/media/gary/Backup/LinuxGames/ED1/dosdevices/c:/Program Files (x86)/Frontier/EDLaunch/Products/elite-dangerous-64/ControlSchemes
while keeping a backup of that folder.

So I've ended up with a shorter list that covers my setup (keyboard+mouse+TM16000M FCS stick only):
Code:
c:/Program Files (x86)/Frontier/EDLaunch/Products/elite-dangerous-64/ControlSchemes
.
├── ClassicKeyboardOnly.binds
├── DeviceMappings.xml
├── Empty.binds
├── GenericJoystick.binds
├── Help.txt
├── KeyboardMouseOnly.binds
├── KeyboardMouseOnlyYaw.binds
└── miiddtcca.dat

Note that the actual custom key bindings are not stored in this folder.
The original list is 33 items long, containing Xbox pad, PS3 pad, Saitek, TM, Oculus, Logitech, etc.
Since I've got the list of files trimmed to a minimum the issue didn't occur again.
 
I didn't have time add to my original post.

The latest WINE 4.1 staging config has the "Staging" tab. There, by default CSMT is selected but it is deprecated. This proved to be a bottleneck on my system.
Disabling CSMT and enabling VAAPI doubled the FPS on my box with GTX 1060 3GB from 60 o 130 FPS. It may worth a try.

https://imgur.com/a/cw71Uq1
 

Yep - I just compiled and rebuilt a prefix from scratch to give a quick test and all seems to be working. The binaries should be available soon.

wine-devel appears to need corefonts installed (where as wine-staging does not). So steps for 4.2 are:

Confirm versions:
Code:
$ wine64 --version # confirm wine 4.2
wine-4.2
$ winetricks --version  # confirm winetricks 20181203-next or later
20181203-next - sha256sum: 758e2368fbc52284da31def9c0f319458dfcfe950169b3e95b14b1e24205b2d6

Set-up prefix:
Code:
$ export WINEPREFIX=~/ED_pfx # <-- this step is optional - default is ~/.wine
# set-up prefix
$ winetricks -q dotnet40 vcrun2015 corefonts dxvk win7

Run ED:
Code:
# export WINEPREFIX location if not already
# cd to location of EDLaunch (found in root of ED installation)
# run ED
$ wine64 EDLaunch /novr /steam
 
Last edited:
Back
Top Bottom