Steam invokes UMU on launch, creating "~/Games/umu/umu-default" #394
Comments
|
In umu-launcher v1.2.5, the program will only create the WINEPREFIX at $HOME/Games/umu when the environment variable isn't set by the client. For more details on the logic and where it begins, see Line 106 in c0a9442 Steps to reproduce:
Terminal output: Note, that in the above terminal output, 'umu-default' is only created when PROTONPATH is the only environment variable is set. Moreover, the directory creation is deterministic and happens only in 1 place. Besides simply executing |
|
Thanks for the clarifications. As I understand it, If I specify
|
|
If I'm understanding correctly, ~/Games/umu/umu-default being created unexpectedly is not a problem but you're suggesting that GAMEID shouldn't be set automatically to 'umu-default' or at all in all of the usages where it's absent because you believe it doesn't make sense? cc @GloriousEggroll for thoughts on this change. Because no fixes from the protonfixes module will be applied in all cases when it's absent if that's your concern. While the module will continue to execute, there's currently no file |
|
GAMEID has to be set to SOME value to satisfy all of the checks throughout both UMU and GE/UMU-Proton. There is no getting around that. I agree ~/Games/umu/umu-default should not be created if a WINEPREFIX is already defined, but as for GAMEID it MUST have some value. It is not beneficial to our time to go modify every single check for GAMEID we have when it's already doing nothing with a default value that doesnt exist in the database. |
|
I'm not against That is what I meant to say since from the beginning, and this is my bug report. It is creating a WINE Prefix that serves no purpose. Regarding |
|
This isn’t an issue at all that can be reproduced in v1.2.5. If you read my post, that was what I demonstrated. As for Proton and Steam’s compatibilitytools.d directory, I’m not following your point and it doesn’t hold as ‘umu-default’ isn’t created. |
|
Just confirming I also cannot reproduce this issue. umu-default does not get created if WINEPREFIX is set: |
|
Hi, using Steam might cause this issue. When launching Steam from the terminal, you can see that UMU is also started. The command is |
|
That would explain why the folder was there. Something between version 1.2.3 and 1.2.5 changed and made that folder appear to me, when previously it never was there. |
|
Thanks for the report. Yes, that is not expected behavior and I would be curious to know if the umu-launcher compatibility tool stored in |
|
I’ll have to verify this later. But functionally, the biggest change that occurred between 1.2.3 to 1.2.5 was dropping GAMEID as a requirement. Assuming Steam has been invoking umu-run this entire time because of the compatibility tool, that would lead to the creation of umu-default. |
I removed it from compatibilitytools.d, and now this issue no longer occurs. |
|
Hello, same issue here. The default umu prefix is created each time I launch steam, even without starting a game. For now I have to set a |
No need. Simply remove the umu-launcher directory in compatibilitytools.d |
R1kaB3rN
changed the title
|
Yeah I tried, and it worked. But after some times |
|
If UMU is being started with Steam as another user pointed out, then it probably means that UMU is being launched without taking any arguments, therefore downloading the UMU-Proton by default. |
CachyOS is Arch-based, which presumably uses the upstream umu-launcher package. The upstream package provides the compatibilitytool as a system package installed in If you're familiar with building packages on Arch, then you can use this example PKGBUILD in an Arch chroot: Or apply the same changes to the umu-launcher-git PKGBUILD file. |
|
I looked into this issue a bit more and the problem appears to be more than just the
These commands will run within the prefix at |
|
Linking relevant upstream issue: ValveSoftware/steam-for-linux#11435 |
It worked. Thank you. |
I use the following option to start a non-Steam game I have:
(I have GE-Proton installed in Steam's
compatibilitytools.dfolder.)(The example folder is not in
~/Games.)Since the latest changes, I have not been using
GAMEID=0, because, as I understand it,GAMEID=0orGAMEID=umu-defaultwill simply do nothing (not apply any fixes).But still,
~/Games/umu/umu-defaultis created, even though I have specified theWINEPREFIX.~/.steam/root/compatibilitytools.d/UMU-Proton-9.0-3.2is also being created, even though I have never launchedumu-runwithoutPROTONPATH=GE-Proton.In fact, I have uninstalled UMU, deleted its related folders (
~/.cache/umu,~/.local/share/umuand the Proton incompatibilitytools.d) and it still got created after reinstalling and using it as a fresh installation. I've noticed this behavior after version 1.2.2, but I cannot tell you exactly what is causing this to happen.For one of the non-Steam apps that I use, it is an executable that opens another executable, so I believe
umu-runis not carrying the desired Proton (and other options) to executables launched after the main one after the main one itself launches another.This behavior is not consistent/exactly reproducible, but I believe the cause is what I said in the previous paragraph.
Thanks.
The text was updated successfully, but these errors were encountered: