-
Notifications
You must be signed in to change notification settings - Fork 76
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
New release for compatibility with wlroots 0.9.x? #107
Comments
Why not backport the fixes to release? Like FreeBSD Ports. |
@jbeich that would also be possible. Usually I try to avoid it as it could also introduce regressions (especially if one uses this strategy to aggressively and/or doesn't pay enough attention), but in this case it should most likely be fine. In any case: Thanks for pointing out the relevant patch :) |
I'm working on the rendering code right now, which I'd like to get merged before I cut a new point release. |
I've merged the rendering work today. If you can, please give it a test (especially over multiple outputs) so that we can get a new point release out. |
@Hjdskes cool :) I gave it a test today and it failed on one of my systems (with or without my second monitor). I initially planned to open an extra issue but it seems like a wlroots bug and also affects sway. I'll include the information in this comment but it's probably not relevant for Tested commit: e3f9959 When I run cage from a virtual terminal (e.g.
This happened on my old desktop system with an Radeon HD 6950 ( When I run Relevant issues: swaywm/sway#4898 |
@Hjdskes turns out this bug was due to an too old Mesa version (sorry about that), I could successfully test it now :) Regarding the multiple outputs: I didn't have a look at the source-code yet, but IMO it would be nice to have some control over it (via CLI parameters, environment variables, or a configuration file) - if this isn't already possible (and maybe also an option to select only one monitor). On my old desktop setup I have a secondary monitor with a lower resolution, with is normally fine. But when I use cage it extends windows over both monitors as if they would have the same resolution. As a result parts of the windows aren't visible anymore. In my case the secondary monitor with the lower resolution contains the left part and my primary monitor the right part of the window. But since the "left" monitor has a lower resolution I have no way to see the bottom left part of the window. Visually this looks approximately like this (not to scale):
Also my secondary monitor is physically positioned right of my primary monitor while cage does position it left of the other monitor (therefore this should probably be somehow configurable). Another issue I've noticed is that the Firefox window (experimental Wayland support) is now consistently too small, filling only ~10% of my secondary monitor. Hope this helps :) |
@kennylevinsen Do you know upfront what to do here? I can have a look but if you know already then that speeds things up 😃 |
There are three separate issues here:
Ignoring a rule engine (akin to sway's for_window), as well as IPC, the following options are what I would consider to make sense for xdg_shell:
The first two are very simple, and just a matter of toggling the view size calculation. The last one requires a little bit more logic, as views has to be rearranged when created/destroyed so that the 3 last top-levels are always shown on each their own output. These two are just the outstanding tasks from the multi-output PR. I think the main "blocker" here is that it increases the amount of configuration for cage quite significantly, so we should probably introduce a config file first. I didn't want to piggyback introduction of a configuration subsystem in the original PR. :)
@primeos Just for some user feedback, exactly behavior where you looking for in the multi-output case? Only one monitor being used? |
@kennylevinsen good question... :)
Yes, that sounds likely :) I just noticed that it now happens consistently with cage while it did only happen occasionally with the current stable release. But it's probably best to ignore it and wait for a Firefox fix since all other applications did behave as expected. |
Responding to both of @kennylevinsen and @primeos here, since you both kind of said the same thing.
This is Cage's use-case: to span a single application across the available outputs. I was hoping there would be a way to fix this in wlroots and to dynamically resize clients appropriately during rendering, but it doesn't look like there is. I don't think changing Cage's behavior in multi-monitor setups is the right way to go, since it would detract from what Cage is meant to be. Therefore, Cage will have to require monitors with identical resolutions and orientations so that it can span everything across the available outputs correctly. I will add this to the documentation somewhere.
Configuring the output layout is something I'm willing to have, but I wonder if Cage is the right place to have this. I'd rather have Cage support the |
Sounds good - wlr_layer_shell or fullscreen_shell can be used if/when implemented for output addressing, in case a single application wishes to handle outputs independently (which is perfectly valid).
I don't think that restrictions on the output configuration makes any sense. Grid configurations are common, and it is easy to make a "perfect" grid layout with multiple resolutions, such as one 4k screen beside two stacked 2k screens. And even then, if a user wants to make abstract art out of their displays, let them. Maybe just state that the application will be sized after the bounding box of the layout, and that some parts of an application surface may be hidden if the layout is imperfect?
I like the idea. Although, we would probably need to document it with an example, as I suppose people would be confused by the lack of built-in configuration. |
Yes, this is what I meant to say but didn't. Thanks for writing it down properly :)
Sure, that's fine. There's a bunch of documentation to be written anyway :D |
Hello, Hjdskes! wlroots 0.11 has been released and with it there are more changes that need to be pushed out for cage to still work. Do you expect the project will be able to address these? (I'm not prodding you with expectations - this is a genuine question for Arch packaging!). |
Same question here from the openSUSE side ;) |
@Hjdskes I would like to add, that it would be beneficial to have signed commits from your side on master, so that integrating patches such as #145 will become easier. Thanks and keep up the good work! |
Would you like to see a release straight for wlroots 0.11? I'm working on Cage 0.2 with larger changes so while I can cut a release to ease packaging, it won't be a very polished release with up to date documentation. The alternative is to wait a little longer until I am ready with Cage 0.2, or for the community to provide the documentation updates (i.e., the man page, the wiki and website can be updated later). |
A (patch level) release being able to target wlroots 0.11.0 (i.e. with #145 included) would be very much appreciated! Thank you! |
@dvzrv The commit signing should also be fixed, thanks for giving me the incentive to look into it properly. If it happens again, please open a new issue for that. |
The current release (0.1.1) fails to build with wlroots 0.9.x (due to breaking changes in wlroots):
But the current version from the master branch is already compatible with wlroots 0.9.x.
Would it be possible to release a new version that builds with wlroots 0.9.x so that downstream package maintainers could use a tagged version instead of a commit from the master branch?
There's currently no hurry because Sway 1.2 is also not compatible with wlroots 0.9.x, but if there is no reason against cutting a new release, it would be nice if the new release is ready once Sway 1.3 will be released.
The text was updated successfully, but these errors were encountered: