Hello everyone! 👋
For the past year I had fun messing around with Docker containers, Moonlight/Sunshine and HW acceleration; so much so that I’ve ended up building a Gamestream server from scratch!
The basic underlying idea is to allow the followings:
- Share a single server (possibly headless but doesn’t have to be) with multiple users
- by creating virtual HW accelerated desktops
- whilst keeping remote mouse, keyboard and controllers completely separated
- with low latency
It’s still rough around the edges, and it needs more testing from the community; if you want to check it out, here you can read the docs and here’s the Github repo.
Whoa, what a cool project! It seems like way more than I need for single-user purposes, but I’ve been relying on Moonlight, Sunshine, and Chiaki quite a lot more than I ever expected to since I ended up taking quite a liking to using the Steam Deck as a pseudo thin-client. Kind of the best of both worlds letting another machine do the heavy lifting somewhere else in the house, so any advancements in the local game streaming space are extremely welcome to see.
Yeah the Steam Deck is such a perfect target for Moonlight I use it for all the demanding games that I can’t run properly natively or when playing on the couch with a big screen.
This is really awesome, and might fit the bill for a linux terminal server environment im setting up. Ill defo take a look when I can.
wohoooo … this looks fun.
will spend one of the next weekends to have a look
Thanks! If you manage to try it out please let us know how it goes!
will do
This looks promising! How’s k8s compatibility/support? As I understand k8s doesn’t officially support splitting the GPU between pods, but there apparently some workarounds.
I don’t have a lot of experience in k8s but the basic principle should work; at the moment Wolf connects directly to the Docker socket in order to spin up and down apps on demand.
I guess there might be some issues in passing the required socket files to the pods, but the whole running model can be changed in theory. Instead of having a single Wolf process you have one front instance that deals with clients and the Moonlight protocol which in turns starts new Wolf pods with the app running that then feed audio and video stream directly to clients.
Definitely do-able, just needs some proper thinking and probably a proper REST API
Very nice! I’ve been on the hunt for a headless gamestream solution but not found something yet so will definitely be watching this project.
On first run it was failing to work, console log was showing http errors.
Also, it looks like lots of things run with Docker priveleged=true / root permissions? That’s a no-go in my book. Any reason why?
On first run it was failing to work, console log was showing http errors.
Would you like to open up an issue on Github or share some logs in our Discord channel?
Also, it looks like lots of things run with Docker priveleged=true
Are you talking about Games on Whales compose file and script? That’s a bit legacy as things are right now, Wolf does run all containers as unprivileged by default
Oops! Mixed up the two repos. Thanks for clarifying.
I’ll post a log as well with the error I’m getting.
What’s required to map a folder into one of the containers (i.e. retroarch)? I’ve attempted to edit config.toml to include it, but the main wolf container immediately crashes on boot due to interrupt code 11. There’s no other error messages, just a binary stack trace.
The folder exists. I’ve tried directly mounting the host path as well as mounting it into Wolf-Wolf-1 and using the local path, but nothing works. Even perfectly mirrored paths don’t work. Wolf appears to be running as root so I don’t think it’s a permissions error? I can certainly access the folders. They are a locally mounted NFS, but I’ve used this with dozens of containers without issue.
It’s probably failing to parse the
config.tomlfile, although that should usually print a proper error line. Have you tried deleting the file or copy and paste the default?Looks like the mount definitions require the
:ro(or maybe:rq?) at the end unlike regular docker volumes, that was the issue.Ooops that was a lazy leftover from my side, sorry about that. Thanks for letting me know, I’ll fix it soon!
This looks really cool!
