-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Limit resolution of containers/streams #172
Comments
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? |
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 |
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 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). It's definitely easier to force this in Wolf and just override what the user is requesting |
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.
The text was updated successfully, but these errors were encountered: