[GH-ISSUE #172] Limit resolution of containers/streams #112

New issue

Open

opened 2026-10-15 12:56:37 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-15 12:56:37 +00:00

Owner

Originally created by @mattman107 on GitHub (Feb 16, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/172

Currently Wolf will default the resolution to whatever the client is asking for.

It could be convenient for users hosting a wolf server to limit the resolution that containers run at either globally or on a per app basis.

Originally created by @mattman107 on GitHub (Feb 16, 2025). Original GitHub issue: https://github.com/games-on-whales/wolf/issues/172 Currently Wolf will default the resolution to whatever the client is asking for. It could be convenient for users hosting a wolf server to limit the resolution that containers run at either globally or on a per app basis.

bsakaguchi added the

enhancement

label

2026-10-15 12:56:37 +00:00

bsakaguchi commented

2026-10-15 12:56:38 +00:00

Author

Owner

@mattman107 commented on GitHub (Feb 16, 2025):

I just had another idea too. I know the concept of users isn't a thing in base wolf, but it seems as though that is something wolf manager is looking to implement. Maybe there could also be a resolution/fps limit per user?

@mattman107 commented on GitHub (Feb 16, 2025): I just had another idea too. I know the concept of users isn't a thing in base wolf, but it seems as though that is something wolf manager is looking to implement. Maybe there could also be a resolution/fps limit per user?

bsakaguchi commented

2026-10-15 12:56:38 +00:00

Author

Owner

@salty2011 commented on GitHub (Feb 16, 2025):

WolfManager's user system mostly takes advantage of setting the paired clients state folder. Normally wolf just generates a random number for each clients state folder. But you can override this to be any folder.

So essentially WolfManager is taking advantage of this to pseudo have users.

But we can currently set some settings per client. So if this feature were to be implemented these settings may be able to be exposed as settings per client or global. Would just need to be exposed via the wolf api for WolfManager to set it.

So WolfManager can only set what Wolf exposes via API

@salty2011 commented on GitHub (Feb 16, 2025): WolfManager's user system mostly takes advantage of setting the paired clients state folder. Normally wolf just generates a random number for each clients state folder. But you can override this to be any folder. So essentially WolfManager is taking advantage of this to pseudo have users. But we can currently set some settings per client. So if this feature were to be implemented these settings may be able to be exposed as settings per client or global. Would just need to be exposed via the wolf api for WolfManager to set it. So WolfManager can only set what Wolf exposes via API

bsakaguchi commented

2026-10-15 12:56:38 +00:00

Author

Owner

@Skerga commented on GitHub (Feb 16, 2025):

Since each user get his own folder anyways and the folder currently contains only subfolder based on appimages used, couldn't we just add a config file at the top layer of the user folder that gets mounted read-only into the started container? This way we could make a small change to the init script in base-app where resolution is set.

@Skerga commented on GitHub (Feb 16, 2025): Since each user get his own folder anyways and the folder currently contains only subfolder based on appimages used, couldn't we just add a config file at the top layer of the user folder that gets mounted read-only into the started container? This way we could make a small change to the init script in base-app where resolution is set.

bsakaguchi commented

2026-10-15 12:56:38 +00:00

Author

Owner

@ABeltramo commented on GitHub (Feb 16, 2025):

@Skerga that wouldn't work because there are practically 2 compositors at the moment: Sway/Gamescope (the inner one, the one that the app will interact with) gst-wayland-display (our custom micro Wayland compositor).
If you change the inner resolution, you'll still render and encode the video at the requested resolution.

It's definitely easier to force this in Wolf and just override what the user is requesting

@ABeltramo commented on GitHub (Feb 16, 2025): @Skerga that wouldn't work because there are practically 2 compositors at the moment: Sway/Gamescope (the inner one, the one that the app will interact with) gst-wayland-display (our custom micro Wayland compositor). If you change the inner resolution, you'll still render and encode the video at the requested resolution. It's definitely easier to force this in Wolf and just override what the user is requesting

bsakaguchi referenced this issue

2026-10-15 13:00:03 +00:00

[PR #112] [MERGED] docs: correct apps links #366