ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.21k stars 174 forks source link

[Feature Request] Allow signing into Native + Steam for Windows in Wine at the same time #4412

Open starlightknight opened 8 years ago

starlightknight commented 8 years ago

I know this was previously declined roughly 3 years ago in #1065, but nowadays you can be logged into the same Steam account on multiple computers anyways for in-home streaming, which didn't even exist back then. It seems silly that this is now allowed, but we can't be logged into a single copy of both Steam for Linux and Steam for Windows on Wine with the legitimate goal of playing our purchased games.

I don't know what the remaining concern here is, but if Valve is worried about someone dual-boxing in a game or the like, it seems like the Steam Windows client is already conscious of the fact that its being run inside of Wine since it makes a point of specifically printing out and separately labeling the detected Wine version in System Information when it's being run inside of Wine. Surely this could be used make a special exception for this case, for 1 native and 1 wine?

I'm a long time Linux user and I'm thrilled with the work you guys are doing for Linux. I'd love it if all games are native, but unfortunately we're no where close. A lot of games in my library do work perfectly fine in Wine though, which is better than nothing. My primary gaming-quality PC machine is hooked up to my TV and runs Kodi + Steam Big Picture Mode on Linux. I've been launching the Wine games as non-steam games via native BPM, but it is very broken for multi-player games -- one of them signs out the other and then a multi-player game will throw up a no connection warning when going online.

As far as I can tell, my only recourse here is to restart the affected clients in the right order, which totally breaks the console like experience of BPM, leading to a terrible user experience. If not for this issue - it would work pretty well considering the games themselves run perfectly fine for me.

Please reconsider and make an exception for this use case (or bribe all the devs and publishers to give us native ports ;-) ). It also seems like it should be easier to reconnect if something like this happens.

Tele42 commented 8 years ago

I believe the technical issue here is with both the native client and the steam on wine client wanting to use the same resources on the network loopback device, so when a second steam client initializes, there is unexpected interactions between the two clients, since it's unnatural for this scenario to occur otherwise.

starlightknight commented 8 years ago

That's interesting - that would make sense. If that's the case, then I wonder if this scenario could potentially be solved by using network namespaces

Ruedii commented 8 years ago

I've run into this issue as well.

I also agree that it would work best by using network name-space to detect if it is the same household.

This would also work well with household sharing.

As of issues with conflicting ports. Generally setting up a dummy adapter works fine for that. The conflicting ports work fine through NAT, with two devices on the same NAT address, so that solution should work.

ghost commented 8 years ago

I can run native Steam for Linux and Steam for Windows under Wine at the same time, so I’m not sure what the issue is for you? I haven’t tried to play a game on both at the same time, though. What I do is launch Steam for Linux, then launch Steam for Windows under Wine, play a Windows game, then close Steam for Windows.

ibrokemypie commented 7 years ago

@stqn1 if you log into native, then open wine version and log in, native gets logged out until it is fully quit and relaunched

Ruedii commented 7 years ago

There are three ways to fix this.

  1. Namespaces
  2. Virtual network devices
  3. Port incrementing

The first two can be done by the user or the steam client given the proper utilities and system authority.

The third requires backend support from Steam.

I think that 1 or 2 are actually better options.

On May 26, 2017 4:15 AM, "Conor Randall" notifications@github.com wrote:

@stqn1 https://github.com/stqn1 if you log into native, then open wine version and log in, native gets logged out until it is fully quit and relaunched

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ValveSoftware/steam-for-linux/issues/4412#issuecomment-304221079, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBV6cg_lrsI2hA60mBSh5tAw5GVvxRTks5r9ooQgaJpZM4ILRF0 .

ibrokemypie commented 7 years ago

@Ruedii, could you give an example of how a user would implement 1? 2 seems a bit overboard to me... 3 seems good though

ardje commented 7 years ago

Example of namespaces:

create a macvlan device

ip link add link eth0 name wineth type macvlan mode bridge ip link set dev wineth address 02:01:02:03:04:05

create namespace

ip netns add winens ip netns exec winens ip link dev lo set up

transfer and setup macvlan device

ip link set dev wineth netns winens ip netns exec winens ip link set dev wineth up ip netns exec winens ip a a dev wineth ip netns exec winens ip ro add default via

If you do it right, you will never use eth0 for your host, but a macvlan version of the eth0, because macvlan's can't talk to the master, but see all other macvlan devices as a kind of bridge. It is in fact a lightweight bridge. Now to use wine in that, you have to just ip netns exec winens wine... You can als ip netns exec winens bash and still expect everything to work, as your tcp connection is on another layer :-). I really really really love network namespaces.