inclement
commented
2 years ago Thanks yet again - the code is good but I'd like to be a little careful with this one, as for xdg-shell views (which as the main shell should be our generic behaviour I think) the fullscreen behaviour required is quite specific:
The output passed by the request indicates the client's preference as to which display it should be set fullscreen on. If this value is NULL, it's up to the compositor to choose which display will be used to map this surface.
If the surface doesn't cover the whole output, the compositor will position the surface in the center of the output and compensate with with border fill covering the rest of the output. The content of the border fill is undefined, but should be assumed to be in some way that attempts to blend into the surrounding area (e.g. solid black).
If the fullscreened surface is not opaque, the compositor must make sure that other screen content not part of the same surface tree (made up of subsurfaces, popups or similarly coupled surfaces) are not visible below the fullscreened surface.
I'm not a huge fan of how prescriptive this is, but it's what the protocol says so if we tell an xdg-shell view it's fullscreen we should obey it. I think that means some tweaks from what you currently have:
- Only one view should be fullscreen at once in a given workspace, i.e. if another becomes fullscreen, we must deny the request or de-fullscreen the first one - probably the former is better
- Only the fullscreen view should be rendered, i.e. instead of
// Render fullscreen views lastwe should render any fullscreen view first and if one was rendered on an output then skip the rest for that output
I'd also like to have a config option named something like "global_allow_fullscreen" which, if false, retains the current behaviour - this is my preference (and why it's currently that way), because I don't want apps to have control over how they're displayed within the output. This is important for e.g. firefox, which asks to go to xdg-shell fullscreen mode when you fullscreen a video, but you can reasonably want to do that within the firefox window without that window having to fill the output. I'm expecting to give more control over that later (via a system of configurable window hooks), but for now a global toggle should be good.
(Firefox actually has a bug right now (link) if fullscreen requests are denied, but that's a separate issue!)
How does that sound to you?
flaviozavan
Introduces support for fullscreen requests and initializations in both xdg and xwayland
Not implemented: handling full screen requests to specific outputs. We always go with the one the view is already in.
Testing:
mpvis very versatile for this. Try all of the combinations:-fs -vo wlshm);-vo wlshm);-fs -vo x11);-vo x11).Toggle to and from fullscreen a few times. Move to other workspaces, try floating fullscreen view, try resizing, dragging...
Also try making a floating window fullscreen and back. It should remember the old geometry.