Remove unneeded dependancies and implement nested compositor layouts in RIVER & KWIN

[davidawesome02-backup]

NOTE: THIS IS FROM A SERIES OF FEATURES, this removes dependencies as well as implements river game layout, use just my main branch for the one that just removes unnecessary dependencies.

Implements river window layout management as well as nested kde layout after launch.

I copied / re-implemented my C version of the river game layout, accessible via a --internal-layout option that passes a FD to get nested virtual monitor information back at the host. When starting with either option (kde or river), we launch the compositor, then inside there, we launch a new version of river that sends back up its state. We then launch instances inside that DISPLAY / WAYLAND_DISPLAY. We watch all child processes, then when any are closed, we just check if it was the nested compositor and exit instantly or if its a game, count down until all games die.

New gamescope changes allow you to unbind the inputs via win+G like specified in the gamescope docs. Now gamescope builds support --nested-follow-window-scale allowing the games launched inside sessions to resize dynamically if one should die, or for better nested support.

Fixed a few layout bugs at small sizes with settings and the top bar being clipped on smaller screens (I use a 1600x900 screen, and it spawns small and is hard to use without adding this at least in settings).

Also, the big xml files are required for us to be able to talk to river (so we don't have to hardcode things) in case river ever changes.

RIVER IS NOT REQUIRED TO BUILD OR RUN, IT IS FULLY OPTIONAL.

This is the main change I was interested in commiting as of lately; but I hope to over the next few days change a few other things mainly:

1. Launching should search PATH rather than using hard coded local paths, and should instead just offer a option to prepend our binary's path to the PATH variable.
2. The build script can be replaced with a more pure rust version via build.rs compiling the binaries, then copying them to /src/bin (excluded from git) where cargo build -F build_all can be made to allow us to build all the deps (and build_NAME) to build each of the different binaries.
3. Building off of 2, we can also use include_bytes (as well as a feature flag) to allow -F embed_all to allow directly embeding (and extraction at runtime) of gamescope, umu, gbe, and the kwin scripts to avoid the current .tar.gz export, and instead be able to supply a single binary.
4. Ability to directly add devices via a selection on the right hand side / using a path box where you can add it your self (my vm I use to test this splits my mouse into two mice where one clicks and one moves, making movement inaccessible to party deck by default)
5. Make players (via a setting disabled by default) able to be created without inputs bound to them, this is useful for testing (I have been doing this via directly disabling features in the code).
6. Addition of --auto that will take all arguments after it as direct commands to be ran, allowing for partydeck to be used directly as a wrapper for any game in steam (without steam api emulation for some games), or just via the steam ui easily by using partydeck --auto %command% as the custom command.
7. Removal of --kwin as with this patch, it is essentially not required any more, and if I want to implement 6, we will have to rework it so arguments are fully passed without causing errors (currently I think strings are not escaped properly)

If you have any questions, thoughts, or anything, please feel free to let me know! If you want to just take a part of this commit, and I can split it if need be.

[wunnr]

Hi, apologies for the delay, I have not had a lot of free time lately; I would greatly appreciate it if you could sync your fork with the latest commits from main so as to make it easier for me to review the changes and additions that the fork is offering.

For example, the top bar UI has already been modified to be much more compact. This should solve the clipping issue without introducing additional complexity into the UI codebase. This is how the top bar looks on smaller displays now:

Regarding river: do you know if it is possible to do multi-monitor with river? As in, on a multi-monitor DE setup can you spawn 1 river session on one monitor, then a 2nd session on another, and have the games launch to their respective compositors? If that's possible I would probably be fine to just drop the kwin scripting stuff and focus entirely on river support.

[davidawesome02-backup]

@wunnr

Sure, I will see what I can do in a few days here; I have been busy me self too, so I will try this weekend / next week.

I think kwin support is important, and easy enough to keep around for those who prefer it (or want hdr) vs river. River offers better support for auto tiling based on my commit though, and I may have to port it to kwin scripts if possible (we also need to figure out if there is a way to load the kwin script for just a single kwin instance instead of all via dbus).

With the redesigned bar, I will remove my changes from that, and rebase to new main; sorry I started working before you made those changes.

Do you want me to keep in my patch for the settings window on small monitors, or do you want that in a different patch if it hasnt been fixed?

River being a nested comp allows us to do multi-monitor, but would require us talking to kde or whatever upper window manager they have if we wish to spawn it on a certain monitor (and wayland hates this). We can ofc spawn multiple versions of river and distribute the games between them, its just placing the river instance automatically into the screens at the position we want may be a hassle, but nesting this way (esp with the new launch code) should be a lot easier for us if we wish to spawn multiple instances and let users move the windows after they spawn.

I also just recently finished the bundling stuff for at least gamescope, but its not yet done for river (most likely we will just ask the person who builds partydeck to have river installed if they wish to embed it with the embed flag, rather than compiling a pure river as unnecessary without any changes (gamescope has changes and is thus a good thing to compile)) nor the GBE we are using. -- If you want to see how I was thinking of doing embedded executables, please read the changes provided in my fork for embeded-executables branch. (use via cargo run -F embed_gamescope -F build_gamescope for example)

If you have any comments on the other ideas above, please feel free to let me know so I don't make any features something too outside of your ideals for the project.

Hi, apologies for the delay, I have not had a lot of free time lately; I would greatly appreciate it if you could sync your fork with the latest commits from main so as to make it easier for me to review the changes and additions that the fork is offering.

For example, the top bar UI has already been modified to be much more compact. This should solve the clipping issue without introducing additional complexity into the UI codebase. This is how the top bar looks on smaller displays now:

Regarding river: do you know if it is possible to do multi-monitor with river? As in, on a multi-monitor DE setup can you spawn 1 river session on one monitor, then a 2nd session on another, and have the games launch to their respective compositors? If that's possible I would probably be fine to just drop the kwin scripting stuff and focus entirely on river support.

[davidawesome02-backup]

Okay, @wunnr just rebased to main, removed the top bar patch, and made it so it should work. It compiles and runs fine on my end, so please make sure this is good for you. I have been going through it again because I am not good at git yet, so I had to do a lot when rebasing this, but it all looks fine.

Let me know if there are any other changes you want to this, or thoughts on my changes :P

If this patch gets merged, I will be working on the new build system (you can see the current state if you want on my branch) so let me know if you have any preference as to how I make this work :)

EDIT as a note: Just realized why your release binary / zip is soo large compared to mine with the new embeded patch; you seam to be building gamescope in debug mode in your CI pipeline. If you want, the new embeded patch also has a -F build_all that would also build gamescope and if in --release mode, allowing us to get rid of the separate steps we currently have in CI, but if you care, we should switch to using the --buildtype=release meson flag.

Unrelated new issue I found when rebasing:

Unfortunately it appears there may be a issue with launching games, where bwrap is always called with ~/.steam despite my vm not containing steam, and thus crashing any launches.

(I have been testing with konsole and just made a new handler just in case the format conversion was wrong; I will make a separate merge for that issue as this one is already huge, and slightly out of scope for just what I wanted to change originally lol, sorry.)

[davidawesome02-backup]

Well shoot, sorry I had to force push, I accidentally forgot to add one of the files to fix the new monitor system, so it didn't even build with that version.

[wunnr]

I have a couple reasons why I would want to just provide river support:

1. Supporting just one way of compositing is easier than supporting multiple, and with my already limited free time + very limited programming knowledge I would want to keep upstream partydeck codebase as simple as it can possibly be.
2. Compositing all gamescope windows through a nested river session would presumably make partydeck more cross-platform, i.e. users across different DEs/WMs/compositors all get the same experience, rather than the current situation which is geared solely towards KDE/Kwin users.
3. The current Kwin script is a very hacky way of doing tiling/splitscreen, and I sometimes come across weird things like the gamescope windows not properly getting resized or placed in the right areas. Given the ability to do real tiling with river layouts I suppose this would not be a problem on there.

As for the multi-monitor issue, I am aware that there is no wayland protocol for a window placing itself on a specific monitor, which is super frustrating. Though, ProtonGE/Proton-EM do have an environment variable WAYLANDDRV_PRIMARY_MONITOR to control which monitor windows go to, and in my testing it actually seems to work well; it may be worth looking into their implementation in the wine-wayland driver and seeing if it's something that could be patched into river. You know more about wayland development than I, though, so it is entirely up to you to decide how feasible this is or if it's even worth pursuing.

[wunnr]

Unfortunately it appears there may be a issue with launching games, where bwrap is always called with ~/.steam despite my vm not containing steam, and thus crashing any launches.

Just fixed this with 225dbce, you should now be able to launch games without steam installed as long as the handler does not use a steam runtime or have a steam appid associated with it

[wunnr]

As for embedding binaries/data files into the executable, my stance on this is:

Right now I do not consider partydeck good enough for general public use right now, it's still missing a lot of features that would be helpful for general purpose use, and users still experience significant issues with it depending on their setup. Until partydeck gets more stable and feature-complete I'm not concerned with how best to package the app. Plus, having all the binaries and resources sitting next to the binary has made it easier to drop in different versions of those resources to test if everything is integrating properly, so I think I'll keep distributing partydeck as an archive until it hits some sort of milestone where I feel comfortable with widely distributing and promoting it. This is subject to change in the future ofc, and I do appreciate you thinking about how to improve the experience of downloading/installing the app.

[davidawesome02-backup]

As for embedding binaries/data files into the executable, my stance on this is:

Right now I do not consider partydeck good enough for general public use right now, it's still missing a lot of features that would be helpful for general purpose use, and users still experience significant issues with it depending on their setup. Until partydeck gets more stable and feature-complete I'm not concerned with how best to package the app. Plus, having all the binaries and resources sitting next to the binary has made it easier to drop in different versions of those resources to test if everything is integrating properly, so I think I'll keep distributing partydeck as an archive until it hits some sort of milestone where I feel comfortable with widely distributing and promoting it. This is subject to change in the future ofc, and I do appreciate you thinking about how to improve the experience of downloading/installing the app.

Cool, good to hear your stance on that. I have my repo open on that if you want it, and I currently have it just extracting the files if they dont exist to a bin directory inside the partydeck-home-path-thingy and then just prepending the bin's path to your system $PATH before starting the games. This only overwrites if the executables don't exist there at all, and is perfectly fine to be replaced with other executables for testing purposes, or just use the ones to the side of partydeck if the option is disabled in settings to use embeded executables. The choice is yours for if you want this ofc, but I have it mostly done if you want to see those changes, though I know you are limited with time.

I have a couple reasons why I would want to just provide river support:

1. Supporting just one way of compositing is easier than supporting multiple, and with my already limited free time + very limited programming knowledge I would want to keep upstream partydeck codebase as simple as it can possibly be.

2. Compositing all gamescope windows through a nested river session would presumably make partydeck more cross-platform, i.e. users across different DEs/WMs/compositors all get the same experience, rather than the current situation which is geared solely towards KDE/Kwin users.

3. The current Kwin script is a very hacky way of doing tiling/splitscreen, and I sometimes come across weird things like the gamescope windows not properly getting resized or placed in the right areas. Given the ability to do real tiling with river layouts I suppose this would not be a problem on there.

As for the multi-monitor issue, I am aware that there is no wayland protocol for a window placing itself on a specific monitor, which is super frustrating. Though, ProtonGE/Proton-EM do have an environment variable WAYLANDDRV_PRIMARY_MONITOR to control which monitor windows go to, and in my testing it actually seems to work well; it may be worth looking into their implementation in the wine-wayland driver and seeing if it's something that could be patched into river. You know more about wayland development than I, though, so it is entirely up to you to decide how feasible this is or if it's even worth pursuing.

I think I can rewrite the kwin script to be a bit better especially after my tiling stuff with river, and I will look into it over the next few days. I like kwin, and the fact it has hdr and all the other kde magic, but for some downstream users I would expect especially gnome users to hate if they had to install kde just to run a splitscreen program; hense river is an option. I think currently removal of kwin is a bit too soon, and I will have to see what I can do about using the new gamescope options to make the kwin program more fleshed out.

Before I would change kwin, I would like to get comment on the current layout algo in river so I can know if I should port that to kwin or just attempt to keep current kwin layout.

Also, I will have to debug the wayland api's that kwin provides because google is not helpful about the current state of wayland api implementation for any of this info and I dont want to read through kwin's source code that much rn, but it should be possible on kwin and mby a few other desktops to present a fullscreen river / nested kwin to a certain display IF they implement some non testing/unstable protocols.

Just fixed this with 225dbce, you should now be able to launch games without steam installed as long as the handler does not use a steam runtime or have a steam appid associated with it

👍 Good to see!

Sorry for the long drawn out messages and commits, I am not great at git and I think we are both still learning a lot about open source dev, so hopefully its not too bothersome. Thanks for taking a look at this though.

[wunnr]

Before I would change kwin, I would like to get comment on the current layout algo in river so I can know if I should port that to kwin or just attempt to keep current kwin layout.

What's the best way I can test the river layout? just open a partydeck river session with a bunch of instances? What is the max number of instances supported by the layout as of now?

[davidawesome02-backup]

@wunnr

What's the best way I can test the river layout? just open a partydeck river session with a bunch of instances? What is the max number of instances supported by the layout as of now?

Honestly its just calculated on the fly based on the number of instances left alive, and there is no limit to it currently, its just calculated using the equation in layout_managers.rs

You can use partydeck to spawn the instances inside river, or if you want to try with other programs outside of partydeck (just the layout) the way you do that is with

river -c "konsole" and just use the partydeck command inside there to see how it looks;
partydeck --internal-layout 0 inside of river (Main thing is using river's WAYLAND_DISPLAY) then it will run properly for the layout and let you just spawn any number of windows or anything inside it.

To use river, just select the layout manager from the drop down in settings and it should work.
You need the main river executable in your path, and the new gamescope KBM patch I introduced here is helpful as it has the --nested-folow-window-scale allowing for dynamic resizing of nested windows.

[davidawesome02-backup]

@wunnr

Hey, so I am on arch as well, so I didn't realize this, but based on your comment on #109 (comment) should we attempt to implement a kde5 script as well as our current kde6 one and just switch the one that is used in a commit after this? I was already thinking of porting the layout (if you like it) used by my river implementation here to kwin for comparability, maybe I can do both in a pull request after this... would you be interested in that?

Posting here as it is related to my kwin / river changes here, and I don't want to fragment the conversation too much.

[wunnr]

Writing a kde5 script wouldn't be too hard, in fact I wrote one myself back when SteamOS was still on plasma 5 (though I never saved it since SteamOS got an update very soon after), and of course supporting more configurations is definitely nice. However I am a little bit concerned about potential baggage that may come with having to support older software that LTS distros may be using. Will think about it

[wunnr]

Got some time to test the river session, here are some thoughts/questions:

1. Layout seems to work well. I did notice that increasing the width of the river window from 16:9 to something wider dynamically changes the layout from top-bottom to side-by-side; this is probably just a consequence of the dynamic layout code but might be undesirable to some since the current Kwin script gives users the option to do vertical or horizontal split no matter the screen's aspect ratio. This might not matter too much though, it's possible I'm overthinking this

2. River seems to always spawn as a 1280x720 window, regardless of my screen size. Is it possible to launch the nested river session in fullscreen so that it immediately covers my entire monitor without any manual input from my end, something akin to gamescope's --fullscreen option, or does this functionality currently not exist in river?

3. The --nested-folow-window-scale option makes it so that the "monitor resolution" detected by the game is whatever the gamescope window happens to be sized at the time, but this presents a problem for games that can't render to small window sizes. For example, many games will crash on launch if the monitor size is less than 800x600, and right now Partydeck has an option that will automatically correct the instance resolutions if they're too small and specify the -W and -H for gamescope ahead of time. Is there a way to make it so that when --nested-folow-window-scale is enabled that the dynamic resolution gets clamped to 800x600 and above? For example, if my gamescope window starts out as 1920x1080 but then gets squished to 1920x540 by another instance spawning, I would want the game to detect a size of 1920x600 (or ideally 2133x600 to preserve aspect ratio) instead of 1920x540. Hopefully all that makes sense but I can elaborate if needed.

[davidawesome02-backup]

@wunnr

Got some time to test the river session, here are some thoughts/questions:

1. Layout seems to work well. I did notice that increasing the width of the river window from 16:9 to something wider dynamically changes the layout from top-bottom to side-by-side; this is probably just a consequence of the dynamic layout code but might be undesirable to some since the current Kwin script gives users the option to do vertical or horizontal split no matter the screen's aspect ratio. This might not matter too much though, it's possible I'm overthinking this

Yes, that is how I currently have it implemented. I can add a horizontal mode or vertical if we want to strictly hold windows to that (so just it expands down or to the right instead of adding my layout), but this isn't currently implemented, it only has auto-tiling right now.

2. River seems to always spawn as a 1280x720 window, regardless of my screen size. Is it possible to launch the nested river session in fullscreen so that it immediately covers my entire monitor without any manual input from my end, something akin to gamescope's `--fullscreen` option, or does this functionality currently not exist in river?

Unfortunately this isnt a feature at the moment, and would require modifications to river.... unless we want to wrap river in another gamescope instance.... this is getting excessive lol.

I may have to make the river layout inside gamescope eventually, but when I tried before I got lost QUICK especially because it only really has render code for a single open window as far as I could tell before I got lost.

3. The `--nested-folow-window-scale` option makes it so that the "monitor resolution" detected by the game is whatever the gamescope window happens to be sized at the time, but this presents a problem for games that can't render to small window sizes. For example, many games will crash on launch if the monitor size is less than 800x600, and right now Partydeck has an option that will automatically correct the instance resolutions if they're too small and specify the `-W` and `-H` for gamescope ahead of time. Is there a way to make it so that when `--nested-folow-window-scale` is enabled that the dynamic resolution gets clamped to 800x600 and above? For example, if my gamescope window starts out as 1920x1080 but then gets squished to 1920x540 by another instance spawning, I would want the game to detect a size of 1920x600 (or ideally 2133x600 to preserve aspect ratio) instead of 1920x540. Hopefully all that makes sense but I can elaborate if needed.

I don't have that implemented currently, but I could add bounds to it....

If you want a simple solution, you can just have that disabled in settings, or just use the fact that --nested-follow-window-scale is a float value that multiplies the window's size before showing that as the display size... so you could change this to like 2 or 3 to get 3x the rendered pixels, if you want a direct scale with keeping the dynamic aspect ratio, but due to this being a cmdline option we cant change this after launch... (and I dont want to mess with gamescopectl stuff right now).

If you have any good ideas, please let me know, I can try to implement them, but trying to wrap another gamescope instance looks to be the easiest if you want a fullscreen option, despite its obvious drawback of now having 3 compositors before you get your rendered image.

also I just realized I misspelled follow and now I need to fix that 🤦‍♂️ Will do that in a few days.

[davidawesome02-backup]

@wunnr
Hey, so its been a bit for both of us with this PR... do you have any suggestions to what I should change / should split into different pr's so you would feel happy merging some of it?

Sorry if I am missing somthing you said you had wanted done here, but the main thing I have not done yet is fixed the spelling of follow and if I have some time I want to make this workable for you.

I can split this into 2-3 pr's if you want that, sorry for dropping it like this, I am new to git, and I was having some trouble with working on multiple branches so just kept adding patches.

If anything out of this, I feel the patches for removing the unnecessary dependencies should be fine to merge as it changes nothing to the end users.

[wunnr]

Sorry for the lack of updates.

After doing testing with river it seems like it always spawns initially as a 1280x720 window. You can programmatically change the size and such using riverctl, it might be worth looking into automating that, but in its current state I'm not sure it provides much utility to users when compared to the Kwin script or just manually repositioning windows for users of other DEs. If there's a use case that I'm not thinking of I'm open to changing my mind of course.

As for the dependency removal, if you want to separate that into its own PR I can get that merged real quick

[davidawesome02-backup]

@wunnr

Good to hear back on this, the main reason for the river script was to remove the KDE dependency, and to utilize my layout algorithm. River is a minimal dependency window manger, being able to fully bundle with party deck rather than requiring a system package or large dependency chains.

I will see if I can resize the window, my analysis of the wayland protocol didn't show that in the version I was using, but I will check the latest release and possibly update my code to that if its available now, or maybe maybe just add it my self.

The main thing I dont like about kde is that it currently REQUIRES using dbus to affect all kwin sessions; sure this can be avoided using userns like we do with bwrap, but I would prefer to avoid that, as well as the large size of kde. I am a kde user, and I love the team, but I would like to respect gnome, xfce, and other desktops like hyprland.

I am sure with a lot of work, I can port this to gamescope, but it may be difficult to maintain. If you want, I can port my layout manager to the kde code for more than 2 windows, but that's only if you want it.

I will plan on splitting this in a few days into multiple commits (sorry), but please let me know about any features you would want from my river patch as I personally think it is still overall a good addition.

Thanks for your time on Christmas, hope it went well for you if you participate!

[wunnr]

I think my main concern about the current River implementation is that the fact that it starts in a 1280x720 window with no way to automatically size it correctly leads to problematic behavior from older games that use older graphics APIs when combining this with the auto-resizing from your gamescope fork. For example with Source 1 engine games (I use L4D2 for testing), the video mode gets set when the game starts and can only be manually changed later from the ingame menu. In practice this leads to: river spawns in as a 1280x720 window -> Two or more L4D2 instances spawn within river as 1280x360 windows -> engine cannot set video mode with a height lower than 480 -> crashes on startup.

If you could find some way to automate the resizing of the river window on startup, and/or clamp the gamescope auto-resizing so that it doesn't resize to a size smaller than games are able to render to, either solution should alleviate this problem.

[Blahkaey]

My use case for partydeck is running it in steams big picture gamemode, so within a gamescope sesssion. i have found that elden ring has constant stutters when using kwin nested in gamescope, but with this river pr im getting a stutter free experience.

if the resolution issue can be fixed im all for the river compositor being an option

one issue i did find is that river is locked to 60hz instead of my displays 120hz

[Blahkaey]

i have a been playing with labwc as a compositor, had the same resolution issue and found wlr-randr can set the resolution

[wunnr]

Just tested setting resolution with wlr-randr, this also works on river, but wlr-randr has to be run from inside the river session. So we would need some way to:

1. Spawn the river session and get its' Wayland output name
2. Run wlr-randr --output [output name] --custom-mode [monitor size] from the river session

[davidawesome02-backup]

Just tested setting resolution with wlr-randr, this also works on river, but wlr-randr has to be run from inside the river session. So we would need some way to:

1. Spawn the river session and get its' Wayland output name

2. Run `wlr-randr --output [output name] --custom-mode [monitor size]` from the river session

@wunnr

Oh, thats easy. This branch already injects partydeck into the river instance so we can get the WAYLAND_DISPLAY to run the layout manager, I can just spawn the wlr-randr command, or implement it my self as I already have 90% of the required logic :P

I can easily send the wlr-randr command if you want, do you still think adding river would be something of interest to you? I can totally make it work if you want, and I really much prefer this layout structure, I just don't want to pressure you into adding extra complexity in this way if you dont want it as an option.

Also of note, currently it looks like river's devs are switching to a slightly different backend for sending layout updates in a partial rewrite they are doing, but it wont affect us if we bundle river or if I just add the logic for the new layout manager.

I haven't finished splitting the patches yet, (I got a lot of homework recently, and I got hooked into making the remote streaming thing I was thinking for a different patch that I may just keep on my own fork until far later)

@Blahkaey

My use case for partydeck is running it in steams big picture gamemode, so within a gamescope sesssion. i have found that elden ring has constant stutters when using kwin nested in gamescope, but with this river pr im getting a stutter free experience.

Good to hear feedback on this, and thanks for the wlr tip, I will check in a few days.

one issue i did find is that river is locked to 60hz instead of my displays 120hz

I dont think I can fix this easily unfortunately, but I think 60hz would be fine for most people playing games with multiple people (already loosing performance) if they want the river version rather than the gamescope ones; but maybe I am wrong, I will leave it up to wunnr as its something out of my control, and I dont have monitors over 60 hz lol.

If you have a moment, how do you feel about the layout ordering / scaling? I think its nice, but I haven't gotten much feedback on it, and it would be easiest to change before this gets merged if it will be.

(lastly, if this is still a issue with the nested kwin, you may want to make a issue for discussion on it, in case anyone else has similar problems)

Again, really sorry for being a week late everyone.

EDIT:

<interface name="zwlr_output_configuration_head_v1" version="1">
   // ...
    <request name="set_custom_mode">
      <description summary="set a custom mode">
        This request assigns a custom mode to the head. The size is given in
        physical hardware units of the output device. If set to zero, the
        refresh rate is unspecified.

        It is a protocol error to set both a mode and a custom mode.
      </description>
      <arg name="width" type="int" summary="width of the mode in hardware units"/>
      <arg name="height" type="int" summary="height of the mode in hardware units"/>
      <arg name="refresh" type="int" summary="vertical refresh rate in mHz or zero"/>
    </request>
    // ...

-- wlr-output-management-unstable-v1.xml
Okay, I may be able to even set a custom refresh rate as was requested by Blahkaey

[Blahkaey]

No worries mate, i am keen to test again soon after the resolution is able to be set

I'm unsure about @wunnr but i think it is a good feature to add solely because using kwin as the compositor inside steam's big picture mode causes frequent judder, where as this compositor does not have that issue, i think i also read some people talking about stuttering in the issues section which may be related to this.

I have done lots of tweaking and testing with kwin and did not find a solution, i think it could just be down to kwin not playing nicely when nested inside gamescope. i have a working implementation of labwc and it also does not have any stutter issues like kwin does. river and labwc are both based on wlroot so it make sense they will be similar. i might add it to my fork soon but don't plan to pr it as i cant add support for multi monitor as i don't have another monitor to test with

[wunnr]

@davidawesome02-backup

do you still think adding river would be something of interest to you?

@Blahkaey's report that the nested river session performs better than a nested kwin session when under a Steam Gaming Mode session has certainly piqued my interest, so I would say if you can get the kinks sorted out I am still interested in getting this merged. No worries about the slow progress, I am also bogged down with life stuff and other projects which has made my communication slow as well; and we are all working on this stuff for free after all :]

[davidawesome02-backup]

@wunnr @Blahkaey

Hey, just posted the commit I have made that should make any wlroots based compositor work (river in this case being the only one implemented, but still this pr has set the ground works for adding others in the future if wanted, like labwc).

Can either of you let me know if this works for you guys, and if so, I will work on simplifying and rebasing to the new base to avoid extra work for wunnr, should this still be of interest to you.

Edit:
Also of note, it looks as if river cannot be set to a specific refresh rate (most likely locked to 60fps are reported above), when attempting with the api provided, it fails to create the new display config, but this COULD work for other wlroots based monitors, if it need be specified rather than implied.