-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Add steam sandboxing / Multiple client launch #988
Comments
I'll be honest, I don't really grasp what it is you're requesting, but SteamTInkerLaunch is for launching games via Steam mostly. I'm unsure how it could handle multiple Steam Client launches. This is not something I'm personally that interested in working on, but I wouldn't necessarily be opposed to it being included in STL, provided there are more implementation details for someone else to pick up this work. Also, is this above board with the Steam terms of use? If so, then I don't see any reason why it couldn't be included, but since SteamTinkerLaunch is primarily for launching games, and this is more in relation to manipulating the Steam Client, it may not be so much of a "natural fit". I'm also not sure what "IPC" is? My perspective on this is that it's something we would add as a command that a user can run with As long as this is acceptable usage of Steam, and pending more discussion from a user who could implement it, I'd be okay with someone opening a PR (or multiple, if necessary) to implement this. But this is definitely not something I would be looking at personally, so it'll be a community contribution. If you can confirm that this is acceptable usage of the Steam Client, I'll add the "help wanted" label onto this :-) If it is as straightforward as you are describing (using some symlinks and setting some environment variables) it may be as simple as adding a function that can be attached to a command. So it may be a relatively-straightforward issue for someone to tackle. |
IANAL - but this is already possible OOTB with steam flatpak versions since each instance is already sandboxed. wrt IPC - steam sets up default Environment variables for Interprocess communication for co-ordinating various locks/pipes etc. You can overide the expected defaults with some environment variables which allows multiple instances to launch without hiting another instances IPC filehandles etc. Googling this will net some forum posts on how people are doing this on windows. The main benefit for a average 'normal' use case that this will allow launch of multiple games at the same time without tripping over steams internal holds etc - especially useful if i.e you have multiple Outputs (needed for multiseat). This also allows for Split screen local play and/or dedicated host/observer instance for lan play when there isn't a dedicated server (most newer titles don't) and allowing the same machine to be used for play as well. -- Beyond that scenarios are mostly for local split-screen co-op. I.e https://nucleus-coop.github.io/ and For headless/cloud-steaming play ( i.e sunshine : https://github.com/LizardByte/Sunshine Which - with a little window manager/compositor integration / hints as part of launch handling would be relatively trivial to accomplish once the initial multiple instance bits are sorted. |
Thanks for the detailed reply!
This sounds a little sketchy in regards to DRM bu I assume it functions the same way as having two PCs running at once, and relevant DRM would still kick in. And as you said similar can be achieved by having multiple Steam packages installed, i.e. Steam Flatpak, just without as much convenience I would imagine. I'll attach a help wanted label now as this is not something I plan to look at personally but would be fine accepting a PR for. Hopefully this is enough information for someone to pick it up. If anyone is looking at this in future please us this issue for discussion! I can't give much help on the feature itself but I can help with any general questions around developing a feature for STL, either here or in a PR review :-) |
I don't think the DRM would be a problem tbh except possibly for native titles. Proton/Wine already launches each instance in it's own sandbox anyway. You might hit issues if you have to be logged in to some cloud service inside the title and try using the same handle from two instances; but that's going to be title/service dependent and not really something this is trying to circumvent or overcome. |
Agreed with all of your points but especially this, and that's basically what I was getting at. As long as this isn't circumventing anything, I'm happy to have it as part of STL. But it's not something I'll find the time to work particularly when it comes to testing, but if someone makes a PR I could dig out my old uni laptop to test it on. Thanks again! I hope I don't come off as dismissive because I'm supportive of the feature, I just won't find time to work on it myself. |
My first use case would be to get it implemented and some integration with Sunshine to provide for remote play setup on headless/workstation machines I'm not currently in front of. This is pretty trivial as sunshine handles input mapping through the moonlight client. Which IME is the biggest annoyance. Steamtinker launch running a gamescope/sway session which then launches a dedicated sunshine instance to that output with a dedicated steam instance would be the workflow. |
System Information
Feature Description
Add integrated steam sandboxing as an option.
The above is relatively trivial with a sandbox wrapper like sandboxie plus, but actually can be achieved with some symlink and IPC variable manipulation alone.
This step potentially opens an easy path the local split screen support (pending input mapping, focus fixups).
I have tested this under sway using a flatpak and a system installed version of steam; but ideally this should be able to be done as part of steamtinkerlaunch as it's a natural fit of it's featureset.
The text was updated successfully, but these errors were encountered: