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

Mon May 2 11:55:00 UTC 2016

On Sat, 30 Apr 2016 22:19:45 +0200
Eugen Friedrich <friedrix at gmail.com> wrote:

> Hi Armin,
> 
> first of all I wish you existing and successful project experience!
> 
> About the missing output for clients, have just an idea: how about creating
> some fake output object, maybe defined in weston.ini and send this to the
> clients.
> Client needs also the information that current output is a fake output in
> order to decide what to do: just continue or wait for a real one.
> Compositor could just pass the buffers that are arrived on the fake output
> to the real one, ones its available.

Hi Eugen,

sorry, I don't understand what that would benefit.

Extending the Wayland core protocol to support and identify outputs as
fake, so that a client could... detect fake outputs, filter them
out from the output list, and then realize there are no real outputs
and act accordingly?

Clients (toolkits) already should deal with wl_output globals going
away or not existing in the first place. When the last output goes
away, it won't have any too radical effects: all wl_surfaces would
simply receive a leave event for the last output, saying the wl_surface
while still mapped is not actually on any output - it is off-screen. A
wl_surface can be off-screen for other reasons too.

A side-effect of a wl_surface being off-screen is that wl_surface.frame
callback won't be sent (so often), which automatically throttles
well-behaving clients' rendering to a halt (or reduced rate). Clients
that do not use the frame callback or Presentation feedback would be
better to observe the wl_surface.enter/leave events and stop rendering
when all outputs have been left.

Of course if a window was maximized on the output that went away or
something, the toolkit needs to respond somehow. Also compositor could
choose to unmaximize such windows first anyway and move then to
remaining outputs if any.

Buffers have no ties to an output. A wl_buffer is attached to a
wl_surface, and that wl_surface may be showing on any number of
outputs, including zero, at any number of copies.

wl_output also has no relation to a GPU (rendering device), and a
wl_buffer must be somehow usable (by the compositor) on all wl_output
that exist or might appear.

*If* there would be a fake output (a weston internal object), and *if*
that output is advertised to clients (wl_output), it would probably be
hot-plugged right before removing the last wl_output and removed right
after plugging the first real wl_output. But I don't think we should
have any fake outputs unless e.g. weston internals really can't work
without any, and fixing it would not be fitting the GSoC timescale.

Thanks,
pq

> Just an idea.
> Am 30.04.2016 5:20 nachm. schrieb "Armin Krezović" <krezovic.armin at gmail.com
> >:  
> 
> > Hi all,
> >
> > Now that I've analyzed the weston codebase a bit, I'm ready to
> > bombard you people with some questions :).
> >
> > For those that aren't yet aware, I'll be working on making weston
> > able to run with no outputs and survive with all outputs plugged
> > out at runtime.
> >
> > For starters, I've simply commented out the output backend load code
> > in src/main.c to see what would happen. To my surprise, the compositor
> > didn't crash, but the desktop-shell did.
> >
> > I'm currently guessing that it crashes because the clients that use
> > clients/window.c code look for outputs in the registry. Of course,
> > there are none because the backend that updates the global registry
> > isn't loaded.
> >
> > Now, my conclusion is: In order to make weston work without any outputs
> > present is to make clients work without any outputs present. This will
> > probably require people to update their toolkits and apps.
> >
> > As I've originally proposed, I see two different ways in achieving this:
> >
> > First and easiest way is use of a virtual output. I could modify the
> > DRM backend to add a virtual output if no physical outputs are found
> > and remove the output when a physical output is connected. Add similar
> > behavior on phyisical screen unplug. If there are none left, add a virtual
> > output. If I remember correctly, Pekka once noted that DRM backend already
> > supports output hotplugging, more or less, but it doesn't support the
> > primary output unplugging.
> >
> > Now, the first question is: Even if this way is picked, would clients or
> > something else require much work to make them behave correctly when
> > the primary output is unplugged?
> >
> > 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.
> >
> > 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?
> >
> > 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?
> >
> > 4. Is there anything special needed for XWayland or is it just another
> > wayland client?
> >
> > That would be all for now.
> >
> > Armin.
> >
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160502/bcb36159/attachment.sig>