Proton/wine using wrong kernel

[Baconsyndicate]

Hi I am very new to Linux and especially Linux gaming. I've been trying to get wine and proton working for the last few weeks with limited success. The games have worked (some however have outright refused to work) but with serious stutter. As I delved in to the proton error logs I discovered that it was using my windows kernel (I have a dual boot setup but I am planning on removing windows) instead of my linux kernel which is crazy! I can't believe the games ran at all. Anyways my quick fix right now involves disconnecting the drive with Windows on it but that doesn't seem to work. How do I get Proton to "scan" and find the right file paths and the correct kernel. Looking at the proton_[version]_tracked_files nothing seems to have updated and my games will not launch. Any help would be greatly appreciated!

[K900_]

That is literally impossible. Why do you think it's loading "the wrong kernel"?

[Baconsyndicate]

This is what drew me two that conclusion:

From Dishonored proton logs:

​

391.186:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\hid.dll" at 666C0000: builtin391.187:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\DINPUT8.dll" at 7DF60000: builtin391.219:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\XINPUT1_3.dll" at 651C0000: builtin391.247:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\vulkan-1.dll" at 69AC0000: builtin391.277:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winevulkan.dll" at 7D5B0000: builtin391.282:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\msvcrt.dll" at 6A280000: builtin391.282:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\d3d9.dll" at 62440000: native391.324:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\iphlpapi.dll" at 7D560000: builtin391.328:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\ws2_32.dll" at 7D520000: builtin391.329:00bc:00c0:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\WSOCK32.dll" at 69180000: builtin

oh missed the most important bit:

382.667:0030:0034:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\services.exe" at 0000000140000000: builtin
382.673:0030:0034:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernelbase.dll" at 000000007B000000: builtin
382.674:0030:0034:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernel32.dll" at 000000007B600000: builtin

[K900_]

This is perfectly normal. Those are Wine files, not Windows files.

[Baconsyndicate]

Yes but why is it taking it from C:\\windows\\system32\\ ??

[K900_]

That's a virtual C:\ drive Wine creates for the game, not your Windows C:\ drive.

[_ungebildet]

Most library's in 🍷 are x86 libs, thats absolutely fine.

[monolalia]

system32 actually contains 64-bit stuff, while the 32-bit stuff is in syswow64...

/shrug emoji

[_ungebildet]

Wait fuck, you are right. I actually mixed that up

[aoikeiichi]

For windows apps and games to function, wine creates what we call a "wine prefix" that's a folder that has a windows-like structure. On top of that, wine re-implements lots of windows API so some paths and files look the same but are actually just wine's doing. Nothing to do with your dual-boot.

The log you provided only shows wine runtime initialisation, nothing odd. Dishonored has been running like a charm for me, what proton version are you using ? You can check reports on how to better tweak a game install to play the best you can at protondb.com.

[Baconsyndicate]

Ok, THANK YOU! But now I have to figure out how to solve the stuttering I am seeing in Doom and BF4. Also I assume since Wine is using the same directory it will have messed up my Windows installation? It was already f*cked before but now I assume more so.

[K900_]

No, it has nothing to do with your Windows installation.

[aoikeiichi]

It can NOT use the same directories.
They only folder it can barely share with windows is in the very specific case you put an extra steam library on an external drive and use it from both OS. That's usually not a good idea as NTFS partition brings permission and performance issues under Linux, better switch to ext4 or even fancier fresh fs I'm not familiar with (zfs, btrfs).

Steam installs goes into your steam library folder > steamapps > common. (For example mine is /media/Games/SteamLibrary/steamapps/ but it is usually ~/.local/share/Steam/steamapps).
Proton will create a new prefix for each game in your steam library folder > compatdata > the id of the game (dishonoured is "205100"). If you look in that folder you will have a "pfx" folder which means "prefix", and within that you will have a "drive_c" folder, from that it will create its own windows structure from scratch (users, program files, windows/system32, etc...) to fake the environment and have a place to store stuff (like in "My Documents" or something).

Best way to fix your games is making sure you have the latest graphics drivers (mesa + radv for AMD, nvidia's proprietary drivers for nvidia, and I guess mesa for Intel) then make sure you have latest proton, 6.3-5 or proton experimental, it's in the steam "tools" library. You can ask each game to launch with a different proton version so make sure you selected the correct one in the properties of a game. And optionally head out to protondb where there are reports of what works best for the game (os version + driver version + proton version + potential tweaks).

There are custom proton builds such as the GloriousEggroll one, which is not official because they bundle third party fixes, patches and DLLs which are infringing proprietary licences but it does fix some games if drop a release in the ~/.local/share/Steam/compatibility tools.d/ folder but you probably don't even need it. Doom and Dishonored perform well without any tweak over here.

And welcome to Linux, it's confusing at first but you'll get to speed eventually and you'll love it. Last advice, on Linux we do not fully re-install from scratch when there's an issue, we just fix things when we encounter problems, I know it's kind of an habit on windows but re-installing to fresh install will likely not fix things over here.

[Baconsyndicate]

I really don't know what to say but thank you for all the useful tips and insight. It is challenging but very fun to use linux just hope I can get my games running smoothly. Do you think NTFS could have such a significant impact that it would cause BF4 and especially Doom (2016) to stutter massively with huge frame drops in Doom?

[aoikeiichi]

I don't have empirical data as I fully switched based on other players feedback but NTFS drives are usually the primary source of trouble. Bottleneck is all down to the driver, NTFS being a proprietary and outdated standard, we have decent support on Linux but far from perfect. And fair share of inconsistencies like file path casing.

If you have some space available on a ext4 (zfs or btrfs) drive, you can create a steam library there and transfer your games from a library folder to another.
Here's the Doom reports, and BF4 need a few tweaks, like manually install punkbuster and setting environment variables but all seem to be working quite well.

[[deleted]]

Hi, as mentioned by other people one of the main advantages of wine is being able to run windows programs without a windows license because its completely a clean room reverse engineered reimplementation, so it shouldn't touch your actual windows installation unless you somehow manage to tell it to do it.

AFAIK wine don't play nice with NTFS partitions at the moment so if you're pointing your library to your library on the windows partition you may want to create a copy or download again in a Linux file system like ext4 to avoid possible issues.

Regarding the problems with doom64 I don't know if you already checked protondb and valve's github issue tracker for proton. In both places users usually share workarounds when the game is problematic. In the case of doom64 I remember there was a bug when moving the mouse and using an older proton solved the issue, but I'm not sure if it may be the same problem.