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. Just an idea. <div class="gmail_quote">Am 30.04.2016 5:20 nachm. schrieb "Armin Krezović" <<a href="mailto:krezovic.armin@gmail.com">krezovic.armin@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote></div>