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

[Armin Krezović]

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ć" <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: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160502/615f900d/attachment.sig>