Question regarding moving weston_output_from_resource to weston_head_from_resource

[Pekka Paalanen]

On Tue, 28 Aug 2018 08:46:51 -0400
Sichem Zhou <sichem.zh at gmail.com> wrote:

> Hi all,
> 
> Yesterday I just updated my compositor from `libweston-4` to `libweston-5`.
> Great job on the new weston_head API. I've noticed the changes mapping
> `wl_output` to `weston_head` that I hope to pose a question on that:
> 
> Since the `weston_output` represents a logical device and `weston_head` is
> for the physical one, shouldn't the clients only worry about the logical
> device thus `weston_output_from_resource` shouldn't change to
> `weston_head`. For example if I have a client that work with multiple
> `wl_output` like LibreOffice presentation application. It occupies multiple
> monitors if in the presentation mode. If it gets multiple `wl_output` for a
> single logical device. I think it leads to a confusing behavior. This is my
> guess, I don't have multiple monitors thus I cannot test it.
> 
> What you guys think?

Hi,

I'm the author of that particular change. I was following the protocol
specification for wl_output which includes things like monitor make and
model. It seems the intention in protocol was to expose the physical
monitors rather than logical outputs. See:
https://gitlab.freedesktop.org/wayland/weston/commit/1b9bf598a57aa60115ecaba6ee547db80927c9bb

It is not a given that cloned monitors are under the same logical
output. That is only true for display hardware level cloning in Weston.
Aside from bugs, I don't think anything prevents a libweston based
compositor from creating multiple logical outputs that overlap
completely or even partially. Well, after we move the layout code from
libweston to the users, anyway.

You're right that from application perspective it is confusing. I
wonder if xdg_output would be a better match in describing outputs for
window management purposes. A problem there is that xdg_output are
created from wl_output, so they cannot aggregate multiple wl_outputs
per se, but maybe they could somehow indicate overlaps.

I'm not sure what the best solution is. Maybe we should have wl_output
represent a logical output rather than a monitor and deprecate even
more information that wl_output events deliver?

But that would still leave the possibility that multiple logical
outputs may be showing the same part of the desktop like clone mode
would, expect they have different timings. We also should not collapse
multiple logical outputs behind a single wl_output global, because the
presentation timing extension ties presentation timestamps to
wl_outputs, assuming a single wl_output has a single clearly defined
display cycle.

If there are use cases where applications themselves need to pick and
choose which regions of the desktop, roughly corresponding to the
concept of a "logical output" they want to occupy, we might need new
protocol for that. Otherwise there is the possibility of choosing
wl_outputs that are actually overlapping. I had this very problem in
weston-desktop-shell helper client with wallpapers and panels, where I
worked around it by inspecting wl_output x,y parameters - parameters
that I have myself criticised for exposing too much compositor
internals to clients. My preferred solution for weston-desktop-shell
would be added private protocol for the desktop-shell plugin to ask for
specific wallpapers and panels from the helper.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180828/75ad7179/attachment.sig>