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. Am 30.04.2016 5:20 nachm. schrieb "Armin Krezović" <[email protected] >: > 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > >
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
