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

Huge rep to all involved.

I think ED is the last major piece of software keeping me on Windows. Everything else has either a native binary or works through Wine.
 
We will try to sponsor inclusion into staging patches, which means majority of distributions will have them at next staging release.

There 's one issue though, even though adding keys is fixed loading presets other than the custom one you create from blank doesn't work.

Not a massive issue although you can't use binds you created on windows or preconfigured binds for HOTAS etc. Also keyboard and mouse are unfriendly names (probably the reason why it doesn't work correctly).
 
There 's one issue though, even though adding keys is fixed loading presets other than the custom one you create from blank doesn't work.

Not a massive issue although you can't use binds you created on windows or preconfigured binds for HOTAS etc. Also keyboard and mouse are unfriendly names (probably the reason why it doesn't work correctly).

Hmmm, can we debug this? What's going on in console when we try to get presets loaded?
 
My hunch is that this is the raw hid.dll access to device IDs and manufacturer IDs we spoke about last night. If you map keyboard controls then look in custom.3.0.binds, the stored usb IDs have nothing to do with the actual IDs of the hardware. Looking at last years' wineconf slides "everything in there is stubbed".
 
Hi, long time lurker here ...


There 's one issue though, even though adding keys is fixed loading presets other than the custom one you create from blank doesn't work.

Not a massive issue although you can't use binds you created on windows or preconfigured binds for HOTAS etc. Also keyboard and mouse are unfriendly names (probably the reason why it doesn't work correctly).

To have the control schemes appear and not map again the keys I had to install a 64 bits dinput8.dll

"winetricks -q dinput8" -> creates the reg but only install the dinput8 32 bits version, then copy from "somewhere" a dinput8.dll 64 bits to <wine-prefix>/drive_c/windows/system32 , the version of the dll has to be a 6.x.x. because a dinput8 from windows 10 (version 10.x.x) has dependencies of api-ms*/ext-ms .dll's not yet implemented in Wine.

In similar way I dont know why for my Wine Staging compilation in order to see the intro movie and background movie (in the options) I had to install quartz.dll (64 bits) and K-Lite-Codec-Pack-1450_Basic.exe, maybe is something with my gst-plugins version but with K-Lite works ok : https://youtu.be/XsirDkR6ZQw.

Yesterday I play all the day, and after some graphics adjustments ED works better than in Windows in my potato lap.
 
Hmmm, can we debug this? What's going on in console when we try to get presets loaded?

Sort of figured it out:

8IIzwDL.png



Sticking the unfriendly names in the presets makes them load:

3aJ6sJt.png


Question is why is wine giving the mouse "3ED89E57" and keyboard "648A0AB8" unfriendly names?
 
Did first proper session with system to system flyby.

Visual game looks impressive. However there's hefty performance penalty on at some points when playing 1920x1080 - frame rate crawling at 20 fps (in rich stations, so that would make sense). I suspect shaders compilation aren't properly optimized yet and as it is shader heavy game, that impacts performance.

Still surreal experience. Did not expect to happen so suddenly.

WUzK0FE.png

oSZESN7.png
 
Sort of figured it out

Sticking the unfriendly names in the presets makes them load:

You beauty!

Question is why is wine giving the mouse "3ED89E57" and keyboard "648A0AB8" unfriendly names?

Look up their USB IDs using lsusb, compare them to the ones stored in the bindings under Wine. On my system they were wildly different, so they will not be in the database ED is using to look up device names that it has presets for. Either that or if this lookup is provided by a Windows API that is incompletely implemented under Wine, this will also fail. Compare with the bindings file from Windows.
 
Do the 410.66 Nvidia drivers have anything related to dxvk in them or anything odd like that? I'm not getting bright blue/yellow graphics. I'm getting normalish looking ones with some odd shadows without DXVK installed. I have 3.17 and Nvidia 410.66 drivers. That is the only potential out of the ordinary thing I can think of. That and dotnet452 actually installed itself.
QM0yPui.jpg

The worst thing in this image live is that the shadows on the planet are dancing around a lot. But this is basic game graphics when I first got in the game.

When I did earlier graphics testing there were settings that would change the colors. I set my graphics all up to ultra. Maybe this avoids graphics settings that cause those psychedelic color oddities. Edit: I did a cursory change of settings and did not create the bright colored graphics problem. Not sure yet why I haven't gotten them.
 
Last edited:
Do the 410.66 Nvidia drivers have anything related to dxvk in them or anything odd like that. I'm not getting bright blue/yellow graphics. I'm getting normalish looking ones with some odd shadows without DXVK installed?

That's really hard to tell. It is just possible that those drivers have no issues with translated DirectX shader commands to OpenGL. Either way, it is good to have both cases covered, because hard to tell which version will be optimal for player to get best performance - as it happens with wine.
 
I found a spiffy way to drop down into cli mode that is easier if you install the proprietary drivers. (Possibly Fedora or Systemd only?!)

Instead of the normal command where you have to type it in before you reboot and then retype to get back to graphics mode.

On startup:

1. Press 'e' on the kernel you want to load
2. Find the line starting with 'linux' and hit 'end'.
3. Make a 'space' using the 'spacebar' if one is not present
4. Type: 'systemd.unit=multi-user.target'
5. Press 'Ctrl-x' to start the kernel load. Or whatever it tells you to use at the bottom of the screen.

All things typed/pressed are without the ' '.

After successfully installing your graphics drivers reboot.(via ctrl-alt-delete or typing 'reboot' and hitting enter.) It will automatically return to level 5 graphics after starting up the kernel.

This creates a one time drop to level 3 or whatever it is called. I always use this because I can never remember the line to reset back to level 5 and go back to graphics mode. So, I find this easier.

This method is also very convenient if your system gets messed up and you can't get back into the desktop to type in the command to get down to cli mode on restart as this can be done at the kernel load screen.

And another tip for the nvidia drivers. If you get a new kernel and it won't load correctly for any reason with the normal instruction from https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/ (at least this is how I install them) it's usually the DKMS screwing up. Fix this by going into cli on kernel load and reinstall the graphics drivers manually from within that specific kernel. If you drop down to level 3 with this and install the drivers again it will usually allow the kernel to come up. 95% of the problems I have with new kernels is from this issue. Normally it will just let you install them with DKMS and you just restart and start your kernel normally. This time I had to install without DKMS and it said something about mismatched software related to it and to abort or ignore. I ignored and installed the drivers without DKMS and my stuff started up properly. I will just need to manually reinstall the graphics drivers next kernel probably, with DKMS hopefully, and make sure that kernel has graphics drivers properly.

BTW, there have been a lot of issues as of late with kernels needing to have drivers manually installed again and not carrying over from installing them in a previous kernel. This used to not be the case. Although I think the last few kernels may have been fine until this most recent one.
 
Last edited:
I found a spiffy way to drop down into cli mode that is easier if you install the proprietary drivers. (Possibly Fedora or Systemd only?!)

Instead of the normal command where you have to type it in before you reboot and then retype to get back to graphics mode.

You don't actually have to reboot to get to a text console (what you call cli mode) - although I suspect you may not have been completely rebooting, but doing something like `systemctl isolate multi-user.target` which basically stops all the services related to a 'graphical mode'.

Anyway, if you read https://www.fedorafaq.org/basics/ then question 1 explains how to switch to a different text console while keeping your graphical login running. (Note: Sections 4 and 5 here are now outdated, but I can't find a newer version, not a fedora specialist).

If you need to install unpackaged nvidia drivers, you'll need to stop the graphical mode though, so before you switch, log out of the desktop, switch to a text console, then stop the graphical stuff as above, compile and install the drivers using its installer, and then start up the display manager again with `systemctl isolate graphical.target`, or maybe `systemctl start display-manager.service` if you merely stopped that to bring down X.

If there's a risk of you messing up the system entirely such that you can't get back to a graphical login at all, I recommend running a snapshottable root filesystem such as btrfs, so you can take a snapshot, break stuff, and if necessary restore the last good snapshot in the bootloader.
 
Did first proper session with system to system flyby.

Visual game looks impressive. However there's hefty performance penalty on at some points when playing 1920x1080 - frame rate crawling at 20 fps (in rich stations, so that would make sense). I suspect shaders compilation aren't properly optimized yet and as it is shader heavy game, that impacts performance.

Still surreal experience. Did not expect to happen so suddenly.

Shaders will cause massive dips when loading into the game for the first time, and sometimes when going into new areas but will smooth out over time. Probably best thing to do is manage your DXVK state cache & GL cache manually. Probably most optimal to have them on an SSD for faster caching, my GLCache is already at 97 MB which is double what GTA V is and that was a stutter fest not so long back due to shaders.

General performance is pretty good here on a 1070 at least.

You beauty!



Look up their USB IDs using lsusb, compare them to the ones stored in the bindings under Wine. On my system they were wildly different, so they will not be in the database ED is using to look up device names that it has presets for. Either that or if this lookup is provided by a Windows API that is incompletely implemented under Wine, this will also fail. Compare with the bindings file from Windows.

I checked and mine were different also, don't know why this is the only game that suffers with this issue.
 
Interestingly, the current Nvidia driver version supports Vulkan 1.1.82

info: GeForce GTX 1080 Ti:
info: Driver: 410.66.0
info: Vulkan: 1.1.82

from "drive_c/Program Files (x86)/Frontier/EDLaunch/Products/elite-dangerous-64/EliteDangerous64_dxgi.log", whereas the older beta driver 396.54.09 reports that it supports Vulkan 1.1.85. No sign of 1.1.88 in its output, although according to this article it does support 1.1.88 features. Perhaps NVidia forgot to bump the version number.

I haven't noticed any performance differences between the two - both get a pretty solid 120-140fps at 2560x1440, including in high tech stations. Haven't been to a rich one yet.
 
Interestingly, the current Nvidia driver version supports Vulkan 1.1.82

info: GeForce GTX 1080 Ti:
info: Driver: 410.66.0
info: Vulkan: 1.1.82

from "drive_c/Program Files (x86)/Frontier/EDLaunch/Products/elite-dangerous-64/EliteDangerous64_dxgi.log", whereas the older beta driver 396.54.09 reports that it supports Vulkan 1.1.85. No sign of 1.1.88 in its output, although according to this article it does support 1.1.88 features. Perhaps NVidia forgot to bump the version number.

I haven't noticed any performance differences between the two - both get a pretty solid 120-140fps at 2560x1440, including in high tech stations. Haven't been to a rich one yet.

396.54.09 is a vulkan developer branch driver, it has newer features including transform feedback extension needed for stream output in some games.

https://github.com/doitsujin/dxvk/issues/695

410 on the other hand is just a stable branch driver with turing support. Other than ray tracing extensions you can't use yet it lacks a lot of features.
 
So I spent all day yesterday trying to get even the launcher to run in WINE, on Debian testing. Nope.

Even compiled Wine - lots of thanks to Eagleboy for his patched source tree. Even created a new user account to see if there was some long-forgotten setting lurking in my user account which was breaking wine. Nope. Compared nvidia drivers, kernel versions, tested wine with dxdiag and watched dxdiag draw lots of nice 3D boxes and such on the screen - seems to work fine. Except the bloody launcher ;)

So I've basically exhausted a lot of possible reasons. The next thing to try is installing a different distro on a spare HDD. Just need to decide which distro.
 
So my system with GTX 760 behaves quite strangely. Despite CPU load being moderate - all 8 cores being used around 20% and memory usage from ED not getting into huge increase, I am incresingly sluggish when ED is launched and frame rate slowly eats away. Granted, I ran on high which might have trip dxvk in all wrong ways - after all it is still highly experimental software - so I am not fussing. Will drop settings to medium and see what's what, maybe some shadow shaders make system to trip over.
 
So my system with GTX 760 behaves quite strangely. Despite CPU load being moderate - all 8 cores being used around 20% and memory usage from ED not getting into huge increase, I am incresingly sluggish when ED is launched and frame rate slowly eats away. Granted, I ran on high which might have trip dxvk in all wrong ways - after all it is still highly experimental software - so I am not fussing. Will drop settings to medium and see what's what, maybe some shadow shaders make system to trip over.

This might answer that, just look at the memory usage on the vulkan heap:

Low 1080p 60 fps cap:

2R9wlEo.png


Ultra 1080p uncapped:

1K6VB0c.png
I don't recall windows using that much GPU memory even with super sampling on.
 
Last edited:
So I have a problem that is stymying further progress: I don't get any wine debug output from EliteDangerous64.exe after it is started by EDLaunch.exe.

I do the following:
Code:
> export WINEPREFIX=/path/to/my/ed-wine
> wine "c:\Program Files (x86)\Frontier\EDLaunch\EDLaunch.exe"

click Play, everything works, yet the only debug I get on the console is the launcher complaining about mshtml.

I can check that the ED64.exe process' stderr is still open and being sent to the tty of the shell I started the launcher from (in other words, business as usual):
Code:
> ls -l /proc/`pidof "c:\Program Files (x86)\Frontier\EDLaunch\Products\elite-dangerous-64\EliteDangerous64.exe"`/fd/[012]
lrwx------ 1 wstephenson users 64 Oct 24 07:11 /proc/30184/fd/0 -> /dev/null
lrwx------ 1 wstephenson users 64 Oct 24 07:11 /proc/30184/fd/1 -> /dev/null
lrwx------ 1 wstephenson users 64 Oct 24 07:11 /proc/30184/fd/2 -> /dev/pts/5

stdout is being sent to /dev/null, but if I reredirect it to a file, there's nothing written there.

I haven't messed with WINEDEBUG in this environment, nor is it set by my wine packages. Anyone know what's going on here? I would like to see if any debug is generated by trying to identify controllers in order to offer control presets.
 
Last edited:
One nice thing is if you don't hit apply with any funny character sets and/or you remove it before applying anything it doesn't reset your keybinds. I wonder what about those keys makes it reset. Is it a default in the game software(detects odd choice) or something else?

FYI, The proper keybind names(or something) are in, "Products/elite-dangerous-64/ControlSchemes/Help.txt

I'm going to go out on a limb and guess that when detecting these odd symbols it is auto loading Empty.binds. Could we just fill Empty.binds with keybind we want?(So far I have not gotten empty binds to load...) Is it possible you have to change the, "{NoDevice}" to something?

List of keys: (As appearing in the game when manually changing them with the in game tool)
Note: '|' = Blocky eyeball looking symbol. There are also no " " in the actual symbols. Red symbols are normal.
Escape = Clears choice

"[F1]" = F1
"[F2]" = F2
"[F3]" = F3
"[F4]" = F4
"[F5]" = F5
"[F6]" = F6
"[F7]" = F7
"[F8]" = F8
"[F9]" = F9
"[F10]" = F10
"[F11]" = F11
"[F12]" = F12

"[RIGHTPARENTHESIS_|]" = `~
"[|_|]" = 1 2 3 4 5 6 q w e r t y u i o p [ ] enter
"[BACKSPACE_|]" = 7
"[TAB_|]" = 8
"[
__|]" = 9 Note: "_" is not visible but represents a space. This figure takes up two lines.
"[ _|]" = 0 - a s Note: There is a space between "[" and "_"
"[ENTER_|]" = +
"[" = backspace
"[_|]" = tab Note: There is no space between "[" and "_"
"[PLUS_|]" = \
"[CAPS LOCKS]" = caps lock
"[SPACE_|]" = d
"[EXCLAMATIONPOINT_|]" = f
"[DOUBLEQUOTE_|]" = g
"[HASH_|]" = h
"[DOLLAR_|]" = j
"[%_|]" = k
"[AMPERSAND_|]" = L
"[APOSTROPHE_|]" = ; :
"[LEFTPARENTHESIS_|]" = ' "
"[L SHIFT]" = Left Shift
"[COMMA_|]" = z
"[MINUS_|]" = x
"[PERIOD_|]" = c
"[SLASH_|]" = v
"[0_|]" = b
"[1_|]" = n
"[2_|]" = m
"[3_|]" = <
"[4_|]" = >
"[5_|]" = ?
"[R SHIFT]" = Right Shift
"[L CTRL]" = Left Control
"[L ALT]" = Left Alt
"[9_|]" = Spacebar
"[R CTRL]" = Right Control
"[R ALT]" = Right Alt
"[APPS]" = Menu Key
Nothing = Left/Right windows keys, print screen?(might be blocked by desktop shortcut usage.)

Nothing = Print Screen?(might be blocked by desktop shortcut usage.)
"[SCROLL LOCK]" = Scroll Lock
"[PAUSE]" = Pause

"[INSERT]" = Insert
"[HOME]" = Home
"[PAGE UP]" = Page Up
"[DELETE]" = Delete
"[END]" = End
"[PAGE DOWN]" = Page Down

"[UP ARROW]" = Up Arrow
"[DOWN ARROW]" = Down Arrow
"[L ARROW]" = Left Arrow
"[R ARROW]" = Right Arrow

"[NUM LOCK]" = Num Lock
"[NUM /]" = /
"[NUM *]" = *
"[NUM -]" = -
"[NUM +]" = +
"[NUM 1]" = 1
"[NUM 2]" = 2
"[NUM 3]" = 3
"[NUM 4]" = 4
"[NUM 5]" = 5
"[NUM 6]" = 6
"[NUM 7]" = 7
"[NUM 8]" = 8
"[NUM 9]" = 9
"[NUM 0]" = 0
"[NUM .]" = .
"[NUM ENTER]" = Enter

"[]" = Internet
Nothing = Email, Search, Volume up, Volume Down, Mute. (all used/blocked by Desktop Shortcuts and work properly in that regards.)

"[MOUSE 1]" = Mouse button 1
"[MOUSE 2]" = Mouse button 2
"[MOUSE 3]" = Mouse button 3
"[MOUSE 4]" = Mouse button 4
"[MOUSE 5]" = Mouse button 5
"[MOUSE +Z-AXIS]" = Mouse Wheel Scroll Up
"[MOUSE -Z AXIS]" = Mouse Wheel Scroll Down

Is this the same as what everyone else is getting?

Edit: Maybe this is a hidden linux only retro setting and FDEV is letting us play the old fashion way with only arrows and the numpad!! 8D

BTW, when I was trying to get the windowed mode going so it wasn't always in full screen there was a funny thing where if it was working, about once or twice a week or less, it would reset anyway back to fullscreen and auto reset a manual change in the file from false or true to 1. You would have to manually edit without the launcher up and then save and play. The game/orsomething seems to detect files being even opened and examined while the launcher is up. That or some other aspect of our OS is doing that. I was assuming it was a detection setting in the launcher itself. Make any changes with the launcher closed save and close the editor down before starting the launcher if it seems to reset mysteriously outside of in game keybind resets occurring potentially.
 
Last edited:
Back
Top Bottom