[PATCH weston v5 06/36] libweston: introduce weston_output::head_list

Mon Feb 5 10:02:14 UTC 2018

On Fri, 2 Feb 2018 12:35:42 -0600
Derek Foreman <derekf at osg.samsung.com> wrote:

> On 2018-02-02 02:32 AM, Pekka Paalanen wrote:
> > On Thu, 1 Feb 2018 15:36:55 -0600
> > Derek Foreman <derekf at osg.samsung.com> wrote:
> >   
> >> On 2017-12-14 05:40 AM, Pekka Paalanen wrote:  
> >>> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> >>>
> >>> The intention is that in the future backends will dynamically allocate
> >>> weston_heads based on the resources they have. The lifetime of a
> >>> weston_head will be independent of the lifetime of a weston_output it
> >>> may be attached to. Backends allocate objects derived from weston_head,
> >>> like they currently do for weston_output. Backend will choose when to
> >>> destroy a weston_head.
> >>>
> >>> For clone mode, struct weston_output gains head_list member, which is
> >>> the list of attached heads that will all show the same framebuffer.
> >>> Since heads are growing out of weston_output, management functions are
> >>> added.
> >>>
> >>> Detaching a head from an enabled output is allowed to accommodate
> >>> disappearing heads. Attaching a head to an enabled output is disallowed
> >>> because it may need hardware reconfiguration and testing, and so
> >>> requires a weston_output_enable() call.
> >>>
> >>> As a temporary measure, we have one weston_head embedded in
> >>> weston_output, so that backends can be migrated individually to the new
> >>> allocation scheme.
> >>>
> >>> Signed-off-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> >>> ---
> >>>    libweston/compositor.c | 216 +++++++++++++++++++++++++++++++++++++++----------
> >>>    libweston/compositor.h |   7 +-
> >>>    2 files changed, 181 insertions(+), 42 deletions(-)

> > 
> > Aside from cms-colord.c, in the full clonemode series (this is a
> > partial one), the only other use of weston_output_get_first_head() is
> > in compositor-drm.c drm_output_set_mode().
> > 
> > In drm_output_set_mode(), the first head is used to get the "inherited
> > mode", that is, the video mode on the output before weston took over.
> > This video mode is fed into drm_output_choose_initial_mode(). The
> > trouble is, if we are enabling for the first time an output with
> > multiple heads, which head's original mode should be used? I suppose
> > you'd filter out any heads that didn't have any mode set, but how to
> > pick then? So I went for the easy way out for now.  
> 
> (Is it just me or has drm_output_choose_initial_mode's doxy gotten a 
> little stale?)

Yes, I thought I fixed it... oh, it's just buried in an unrelated patch
I have never published, so the fix doesn't exist yet.

> Not sure I'm ready to think that far ahead yet, but I'll try...
> 
> At some point I think it should be possible for all the heads in an 
> output to have completely different resolutions as well as refresh 
> rates.  On a windows PC here I can set my 4k monitor and 1920x1200 
> monitor to be clones, and I can set the resolution to 3840x2160.

That is not shared-CRTC cloning, that is independent-CRTC cloning. My
work does not include independent-CRTC cloning. This patch series is
purely for shared-CRTC cloning, which implies that all connectors are
driven from the same CRTC, or if multiple CRTCs are used they must be
guaranteed to be gen-locked (for which there is no kernel UABI yet).

The rule I installed here is: if heads might have different timings,
they cannot be attached to the same weston_output. Weston_output
maintains the repaint state machine which must be locked to the
hardware scanout cycle. Therefore there can only be one scanout cycle
timing-wise per weston_output.

Once we fix libweston's damage tracking to cope with overlapping
weston_outputs (I have no immediate plans to work on that, tough), then
the scenario you mentioned can be realized by creating a weston_output
for each monitor and configuring these weston_outputs to display the
same area of the desktop. That way the monitors can have independent
timings, resolution, scaling, rotation, color profile, everything, but
at the cost of having to render framebuffers for each separately.

> This looks poor with black bars top and bottom on the 1920x1200 monitor, 
> but it does work, and I can see some people thinking this is a 
> reasonable way to hook up a projector.
> 
> So, I think the weston_output resolution and weston_head resolution 
> should be potentially independent (even when not cloned) of any 
> modelines available from the head.

No, I'd like to think my design is much simpler than that. ;-)

> That makes picking a potential output mode from several heads a serious 
> mess. :)
> 
> So, drifting slowly back to some kind of point...
> 
> Will simply picking the current mode on the first head be surprising to 
> users?  Will it result in situations where switching two monitor cables 
> will cause surprising behaviour?

It's possible that may change the end result, and probably there are
many more causes as well.

I'd like to point out that clone mode is a new feature, so there won't
be a regression at least.

> I don't really know how we should define surprising in this context, but 
> I suppose we should do our best to light up all the displays set as 
> cloned, and also not exit.

I agree.

> I think we should be as lazy as possible in order to get that.  I 
> suspect that level of lazy is somewhere between "just use the first 
> head" and "savage stack of broken heuristics that fall apart in the dark 
> corners".
> 
> The concept of the mode currently in use for an "output" at weston 
> startup seems somewhat meaningless when an output is actually an 
> internal canvas abstraction and all the heads in that output may have 
> different modes at launch time. :/

Indeed.

> (All that said, I'm not sure any of that actually matters in the context 
> of the series currently under review.)

Yeah, I'd like to think of it as another problem to be solved later.

To be independent of ordering, we would probably want to collect
current modes from all heads and sort that list, then pick...
- largest? high chance of not working for some heads
- smallest? ..maybe

Or repeatedly pick the next largest and check against monitor mode
lists to see if it's there, or against monitor specs to see if it might
work.

Of course, this whole question is avoided if weston.ini contains an
explicit mode to set.

Unless that mode is "vague", and one needs to look for a match from a
list of supported modes. But for that there is something fun like
https://gitlab.collabora.com/pq/weston/commit/060887a14d7955f70d7c39f2dfc358a7a3841633

Thanks,
pq

> 
> Thanks,
> Derek
> 
> >> In any event, everything up to this point is still:
> >> Reviewed-by: Derek Foreman <derekf at osg.samsung.com>  
> > 
> > Very much appreciated.
> > 
> > 
> > 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/20180205/823a0b97/attachment.sig>