[GSoC] Some questions about wayland clients with no outputs present

Tue May 3 00:33:14 UTC 2016

On Mon, May 02, 2016 at 12:49:04PM +0200, Armin Krezović wrote:
> On 30.04.2016 22:14, Bryce Harrington wrote:
> > On Sat, Apr 30, 2016 at 05:20:09PM +0200, Armin Krezović wrote:
> > But virtual outputs is not a bad idea, it could be useful for testing or
> > perhaps to extend one's rendering beyond ordinary hardware capabilities
> > or something.  But it should be user-controlled via commandline options
> > or config file options.
> 
> I was thinking about using the virtual outputs when no physical outputs
> are present, and keep them out of the way otherwise. Sure, a command
> line switch/config option is useful, especially for the test suite (Pekka
> proposed something similar).

I wonder what situation would arise where the user would want to use the
drm backend when there weren't any physical outputs.  I can see that for
testing purposes but am drawing a blank for use cases other than that.

> >> The second and more harder way is to simply cope with no outputs present and
> >> watch for output plugging/unplugging. This would require clients to watch for
> >> output changes and take apropriate action.
> > 
> > I would think this is not something the clients need to take action on.  
> > E.g. for the screen blanking, when an output becomes inactive the client
> > doesn't need to watch for that, the compositor simply stops directing
> > them to render.
> > 
> 
> Hm, thanks for the info. I kinda got confused between desktop-shell/shell.c
> and clients/desktop-shell.c here, which is what lead me to this conclusion.
> 
> Now, to confirm, the shell is the X window manager equivalent of the wayland
> world? Is it responsible for placing windows and moving them around? If so,
> my work has suddenly become way more easier.

Pretty much yeah.  The core of Weston doesn't make assumptions about how
windows are laid out and stuff - it provides an abstract compositing
core.  It has multiple different "shells" that sort of wrapper the core
and implement the GUI management policy particulars.  I have a few notes
on this too which I'll shoot your way.

> > The slight but crucial difference, however, is that when a screensaver
> > kicks on, you don't want the clients to rearrange or move around.  You
> > want everything to come back exactly as it was; whereas with output
> > unplugging, you probably *do* want things rearranged.  Unfortunately the
> > tricky thing there is that how to rearrange things is going to be a
> > policy thing.  I should imagine different *shell* implementations could
> > desire setting different types of settings.  Neither the backends nor
> > the clients should be making that policy, just the shells.
> > 
> > The fullscreen shell is simplest - there's just one client so it is just
> > resized to the new number of outputs, or if 0 outputs just stops
> > rendering, and restores when some output gets attached.  The desktop
> > shell perhaps should force clients to be moved off of the removed
> > output(s), maybe just to some randomly chosen spot.  Extra snazzy would
> > be if it could rearrange the clients to look nice on the remaining
> > outputs (but that's almost certainly beyond scope for your project).
> > Other shells like IVI would probably have their own desired behavioral
> > policies...
> > 
> 
> This is why I asked what should be done on output unplugging. I see that
> window placement isn't that important, but I'd still like to try to
> arrange the windows symetrical to the unplugged screen. I am unsure if
> they should be scaled/resized in case of, ie, moving from a screen with
> bigger resolution to a screen with smaller one. What do other
> compositors/shells do?

For Weston I don't think anyone has spec'd that out; I couldn't speak
for other compositors - quite likely you can find some good guidance
there.  You might check if there's a design doc for Gnome Shell or KDE.
I know a very detailed and thorough one was done for Canonical's Unity
but it no longer appears to be public (I can't find it anyway).

Your mentors may have more specific guidance on all of this.

Bryce

> > I would imagine that Weston would want to exhibit the same general
> > behavior when outputs are changed, for any backend.  So if you're
> > running desktop shell on the drm, x11, headless or other backends and
> > remove one output, then whatever happens as a result should always
> > the same result regardless of backend.
> > 
> > So, the backends should indicate to the compositor (and thence to the
> > enabled shell) that the output change has occurred, and then the shell
> > has the responsibility to rearrange the client surfaces as it wishes.
> > Perhaps you'd like to focus your scope on the backend side of things,
> > make sure the communication path *to* the shell is all working, but
> > leave the layout logic as outside scope to be done as followup work.
> > 
> 
> I think that desktop-shell already supports rendering on multiple outputs
> (as confirmed by plugging in a second monitor) and stopping any rendering
> from a certain output when it gets removed. It still needs to properly handle
> screen blanking and screensaver when all outputs are gone. The things will
> change when I start working on second part of my GSoC, which involves
> extended screens.
> 
> >> The second question then might be: What should clients do in such case?
> >>
> >> 1. Do they only need to schedule redraw and toggle back fullscreen if it was on?
> > 
> > Hope my ramblings above stumbled into an answer for this.
> > 
> >> 2. Do they need to resize/scale relative to the size of new screen? (eg, a maximized
> >> app on 1920x1080 screen would not be entirely visible on 1600x900 one).
> >>
> >> 3. Is there something as "move an app to different screen" that can be issued
> >> by compositor? Or do apps need to do that too?
> > 
> > #2 and #3 are Weston shell policy, so there won't be a single answer;
> > potentially each shell could do it differently.  Again, I suggest
> > focusing just on making the underpinnings work right, and maybe pick one
> > shell (likely the desktop shell but pq might prefer you focus on IVI or
> > something) as a demo/reference implementation.
> > 
> 
> As noted above, I'd like for clients to be on exactly similar spot on the
> new screen, even after all outputs are gone. This might require preserving
> client layout somewhere, so would it be okay?
> 
> As for the shell choice, I haven't worked on IVI shell yet, or even used it.
> I'm more familar with the desktop shell, but I may need to ask more questions
> about some terms used in the implementation that I don't yet understand.
> 
> >> 4. Is there anything special needed for XWayland or is it just another wayland client?
> > 
> > I would suggest leaving Xwayland outside scope for your project, I
> > think you're going to have plenty on your plate as it is.
> > 
> 
> Fair enough.
> 
> > Bryce
> > 
> 
> Thanks for taking your time to respond. It means a lot.
> 
> Armin.
> 

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJXJzCgAAoJEFFnYkKqnAm6r9kP/0j0VACKxVOYsZ8ucBS9k/p/
> 29vnB7XGb62ej88CsDlLBPJdydabUfBxNWtron6IyMBiIk4khWPqjKqu4ZUcvn59
> P/gb0qaFOBgvC5XhAKCNnS87dDr9cNPCi0SBe6ntQ6Nw9RnsCPZ8K1AHeyjpKjsJ
> 8/rEPxJQXjuPtVFtpHNLBMHuo50AYgN9AbgIVBRNmwYuzKB0MkvQHr8aMcWDVCRG
> 8Ordg7kKD5AqMpKXXkIocwpuOmroXYDO7IedZdbO8JzDSynpTEYvBwTaH4WGIWSB
> 7Ob1AQQcbXzqvY0vfAFP0C9M03+rVs0DwRo2j83TVBZvOSRGSnV+6oVGdeTecRuh
> QaFROr5wwvMLVPm3sWRDysavBkG5eTW28RxSajMKr6I1UUMlVP21itYcfFbujVer
> FTP+2NCdvCroVj6Fo4bWPhUuggv3eGVkfkDAf/rN3NpvG4S2Uj8zOsofsJ7fZDdL
> t/fwrYyECy8UjTURWiEBP+EfxMv6CpUd9NqJLVW/hUHKmDtVL+hdjfENzDV6dd+M
> jPbWprXeyTgVpZdE/14AqeAaE986LiHsC5X0klvyMdiASJD2HdjTfTZZpITML5IO
> SE2BlYzSs4P7gnTgTiz2+tvkSmSMz6/lU/6faOSN9qen/3dpwoH+cv1vHHhx0VNu
> rRpOWUkwK2AnHsX15X35
> =oZV6
> -----END PGP SIGNATURE-----