Frogging-Family / wine-tkg-git

The wine-tkg build systems, to create custom Wine and Proton builds
883 stars 159 forks source link

[proton-tkg] Mouse clicks not captured in Civilization VI on wine master proton-tkg #1163

Closed Arastais closed 5 months ago

Arastais commented 5 months ago
GameSid Meier's Civilization VI (289070)
Graphics Card AMD Radeon RX 7900 GRE (Driver Mesa 24.0.5-1)
DistroArch (kernel 6.8.7-arch1-2)
Proton-TKG Version9.7.r5.gc5ff8141
Proton-TKG Configdefault proton-tkg.cfg
Logsteam-289070.log

When using a wine master upstream build of proton-tkg, the game fails to capture the mouse properly. Mainly, I can't click anything with the mouse, rendering the game unplayable. The game's custom mouse cursor shows up fine, and the game loads and otherwise runs perfectly. Keyboard inputs are even received properly.

This does not happen with valve wine based builds of proton (including Proton GE).

I have also tested with an NVIDIA GPU with the latest proprietary driver, and the behavior is exactly the same. This behavior is also the same regardless of using the native wayland or X11 driver. The game being fullscreen or windowed does not matter either.

mikeserv-git commented 5 months ago

That could be a focus issue, try alt-tabbing a couple of times (might have to cycle through a few windows). I have that in a lot of games.

The ultimate fix for me to bring a game in focus is to press hotkeys to bring up a window list, and use the arrow keys and hit enter on the game. This may not work in all window managers/desktop environments.

This problem changes with different Protons/Wines. I sometimes get that where it wasn't happening before in some games.

Note that it might not SEEM like a focus problem :-)

Tk-Glitch commented 5 months ago

This is a known issue on upstream wine https://bugs.winehq.org/show_bug.cgi?id=51537 We used to offer the valve patch but it got frogged due to upstream changes along the way. Could you please try the attached userpatch? Thanks! civ6_mouse.mypatch.zip

Arastais commented 5 months ago

@Tk-Glitch I'm unable to test the patch as I'm suddenly unable to build proton-tkg, even with a fresh clone and just running ./proton-tkg.sh with no configuration changes. I get: cp: cannot create regular file 'proton_dist_tmp/lib/wine/i386-unix/': Not a directory late into the build cycle, once it's building the openvr components.

I assume this a bug when trying to make symlinks copy the file, as the actual file name is missing. You can see this with the lines just before it:

'/home/artin/Downloads/wine-tkg-git/proton-tkg/openvr/bin/win32/openvr_api.dll' -> 'proton_dist_tmp/lib/wine/dxvk/openvr_api_dxvk.dll'
'/home/artin/Downloads/wine-tkg-git/proton-tkg/openvr/bin/win64/openvr_api.dll' -> 'proton_dist_tmp/lib64/wine/dxvk/openvr_api_dxvk.dll'
'/home/artin/Downloads/wine-tkg-git/proton-tkg/openvr/build/vrclient.win64/vrclient_x64/vrclient_x64.dll.so' -> 'proton_dist_tmp/lib64/wine/x86_64-unix/vrclient_x64.dll.so'
'/home/artin/Downloads/wine-tkg-git/proton-tkg/openvr/build/vrclient.win64/vrclient_x64.dll.fake' -> 'proton_dist_tmp/lib64/wine/x86_64-windows/vrclient_x64.dll'
'/home/artin/Downloads/wine-tkg-git/proton-tkg/openvr/build/vrclient.win32/vrclient/vrclient.dll.so' -> 'proton_dist_tmp/lib/wine/i386-unix/'

which looks like it's missing the file name in the i386-unix line.

Don't know if it's related to the patch specifically, as I tried without the patch and it's still giving me the error, but this only started happening once I applied the patch. The patch itself applies successfully.

Tk-Glitch commented 5 months ago

@Arastais Just tested and I couldn't reproduce the issue. I also checked out that specific line in the script and it seems fine. Maybe something went wrong with a previous build and you should just nuke proton_dist_tmp then try a rebuild. It shouldn't be a symlink.

Arastais commented 5 months ago

Maybe something went wrong with a previous build and you should just nuke proton_dist_tmp then try a rebuild.

@Tk-Glitch Tried that, same thing. Also tried doing a fresh git clone of the entire repo and building proton-tkg with no config changes like I said - same thing. In fact, I think this only started happening once I re-cloned proton-tkg.

I could try building in a clean chroot, but I would need to use the PKGBUILD, and I don't know if that's a good idea given the warnings inside it: e.g. Packaging proton requires some ugly hacks that can break expected behavior.


I also tried disabling the SteamVR components (as I don't care about VR anyway) with _steamvr_support="false" (in wine-tkg-git/proton-tkg/proton-tkg-profiles/advanced-customization.cfg), but that suprisingly didn't change anything either.


I also checked out that specific line in the script and it seems fine.

Which line are you referring to? Because in the script file I see: https://github.com/Frogging-Family/wine-tkg-git/blob/77f6a3b62a050d205584c1fd1f9fe9eec8e41284/proton-tkg/proton-tkg.sh#L241

The actual command looks correct like you say, but for some reason it's failing to create the i386-unix directory. What's odd is that there's this line right before it:

cp -v "${_nowhere}"/openvr/build/vrclient.win64/vrclient_x64/vrclient_x64.dll.so proton_dist_tmp/$_lib64name/wine/x86_64-unix/

and that seems to copy fine.

Tk-Glitch commented 5 months ago

Something changed/broke on your end. Maybe the build fails earlier than that and you get a broken build missing the i386-unix dir? On proton builds, since some MR it seems some of our traps are not getting triggered by errors anymore, so it might attempt to continue even though the build is broken.

Output of the archlinux CI also, steamvr support enabled:

2024-05-01T10:31:07.7490861Z '/__w/wine-tkg-git/wine-tkg-git/proton-tkg/openvr/bin/win32/openvr_api.dll' -> 'proton_dist_tmp/lib/wine/dxvk/openvr_api_dxvk.dll'
2024-05-01T10:31:07.7522095Z '/__w/wine-tkg-git/wine-tkg-git/proton-tkg/openvr/bin/win64/openvr_api.dll' -> 'proton_dist_tmp/lib64/wine/dxvk/openvr_api_dxvk.dll'
2024-05-01T10:31:07.7593530Z '/__w/wine-tkg-git/wine-tkg-git/proton-tkg/openvr/build/vrclient.win64/vrclient_x64/vrclient_x64.dll.so' -> 'proton_dist_tmp/lib64/wine/x86_64-unix/vrclient_x64.dll.so'
2024-05-01T10:31:07.7617551Z '/__w/wine-tkg-git/wine-tkg-git/proton-tkg/openvr/build/vrclient.win64/vrclient_x64.dll.fake' -> 'proton_dist_tmp/lib64/wine/x86_64-windows/vrclient_x64.dll'
2024-05-01T10:31:07.7681657Z '/__w/wine-tkg-git/wine-tkg-git/proton-tkg/openvr/build/vrclient.win32/vrclient/vrclient.dll.so' -> 'proton_dist_tmp/lib/wine/i386-unix/vrclient.dll.so'
2024-05-01T10:31:07.7705372Z '/__w/wine-tkg-git/wine-tkg-git/proton-tkg/openvr/build/vrclient.win32/vrclient.dll.fake' -> 'proton_dist_tmp/lib/wine/i386-windows/vrclient.dll'

which looks like it's missing the file name

That's because we're copying the file as is to the dir. No need to set a file name in this case since you got it from the source to copy from. You may notice that it's done the exact same way for vrclient_x64.dll.so, which doesn't fail for you.

edit:

The actual command looks correct like you say, but for some reason it's failing to create the i386-unix directory. What's odd is that there's this line right before it:

That dir is created by wine at build time. If it's missing, your wine build is broken. Try building with _log_errors_to_file="true" set, that should capture the point of failure.

Arastais commented 5 months ago

That dir is created by wine at build time. If it's missing, your wine build is broken.

Turns out that was the hint I needed. My wine build was indeed failing because it was re-using components from a previous build (e.g. gstreamer) that had failed because of a previous patch (specificially the patches in #1116; I'll make a note there), despite the fact that my wine-tkg was a fresh clone. Forcing recompilation of said components allowed wine to build successfully again.


Thankfully, after all that was sorted out, the patch works. Game works perfectly it seems, even with the wayland driver. Thanks for all your great help.

Maybe this would be a good patch to add to wine-tkg by default?

Tk-Glitch commented 5 months ago

I'm glad we got this sorted. Yes that's worth adding back to the meta-patchset indeed. Thanks for testing and confirming it does work on upstream trees !