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

[Pekka Paalanen]

On Sat, 30 Apr 2016 17:20:09 +0200
Armin Krezović <krezovic.armin at gmail.com> wrote:

> Hi all,
> 
> Now that I've analyzed the weston codebase a bit, I'm ready to
> bombard you people with some questions :).

Hi Armin!

> 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.

Heh, that was unexpected. :-)

> 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.

Clients, that is toolkits really, should already be handling wl_output
global removals. It is possible they do not, but that is not your
concern. Let us focus on Weston particularly, and the demo clients in
weston repository. You should not care about any other toolkits for
now, they might make your GSoC project scope explode.

I explained some of the mechanisms that apps and toolkits should be
using already in my reply to Eugen. If they were implemented properly,
I would expect all clients to just work.

> 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.

I would say the DRM backend is the wrong place. Surely running with
zero outputs may apply to all backends, so the implementation should
live in Weston core.

However, there are some catches about manufacturing a weston_output
that is not created by the backend. I have seen some of that in my
experiments towards Weston IVI remoting.

I think we should keep the fake output design as plan B, and only in
case the plan A below is not possible to execute under the single GSoC
project.

> 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?

Considering it would never cause the number of wl_outputs to drop to
zero, they would be just fine if they expect output hot-unplugging to
occur at all. Dropping the number to zero might break a few more
assumptions, though I have hard time imagining what they could be.

The Wayland protocol implementation is safe anyway, wl_proxies cannot
suddenly disappear.

> 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.

This is the plan A and the approach to the tried first.

> 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?

Maybe, though it doesn't really matter much. Also the compositor could
ask the window to un-fullscreen, at least with xdg-shell. wl_shell
might be a different case. The interesting question is what happens
when output comes back.

For a multi-output scenario, you could unplug an output where there are
windows, but it's not the last output. The case is the same from client
perspective.

> 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).

The compositor too could signal a resize.

> 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?

There is nothing to be issued as such. It's only compositor-internal
state change, and clients will get notified via wl_surface.enter/leave
events.

What clients can do depends on the shell protocol extension, e.g.
xdg-shell. Normally only maximize and fullscreen window state can have
a designated output by the client. Otherwise it is all compositor's
discretion.

> 4. Is there anything special needed for XWayland or is it just another wayland client?

XWayland probably cannot remove the last or primary output at all, but
you should not worry about that for now. If there is something to fix,
it must be fixed in XWayland (the X server - to keep a ghost output if
necessary).

It is good to investigate the client side problems too, but I think it
is getting too much weight for starters. When I wrote up on this
project, the main culprits I were thinking about in Weston were all the
code that does:

	assert(!wl_list_empty(&compositor->output_list));
	output = container_of(compositor->output_list.next,
			      struct weston_output, link);

or similar. That is, code that explodes if the output list is empty or
there cannot be a valid weston_output pointer. You can find it by
grepping for 'output_list'.

Some major issues are the functions weston_surface_is_mapped() and
weston_view_is_mapped(). I think we are finally going to need to add
booleans 'is_mapped' in weston_surface and weston_view structs. It is
possible that these are actually the source for almost all of the cases
where having no outputs would explode.


Thanks,
pq
-------------- 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/2f0507bb/attachment.sig>