On 30.04.2016 22:19, Eugen Friedrich wrote: > Hi Armin, > Hi Eugen,
> first of all I wish you existing and successful project experience! > Thanks! > 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. > As discussed with Bryce and Pekka, there could be a virtual output, no problems. However, as Bryce explained in a post before yours, I don't think clients need to know whether they're on virtual output or not. It's just the compositor/shell that needs to know that and then tell clients to stop rendering to the fake screen (either if it's the only one around or there are fake screen + one or more physical outputs). > Just an idea. Much appreciated. Armin. > 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 >> >> >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
