[PATCH weston 4/4] compositor: Implement horizontal output layout configuration

[Pekka Paalanen]

On Sun, 9 Oct 2016 19:30:11 +0200
Armin Krezović <krezovic.armin at gmail.com> wrote:

> On 07.10.2016 12:19, Pekka Paalanen wrote:
> > On Fri, 30 Sep 2016 23:25:30 +0200
> > Armin Krezović <krezovic.armin at gmail.com> wrote:
> >   
> >> This patch adds horizontal output layout configuration using
> >> the previously added code.
> >>
> >> When an output is added, it looks for outputs that it should
> >> be placed next to, if they are specified. If such output is
> >> found, output layout is updated if needed (outputs on a given
> >> position are moved right if they collide with the new output)
> >> and the output is positioned next to the specified output,
> >> either on its left or its right.
> >>
> >> If a certain position wasn't specified for the current output,
> >> the compositor looks for any existing outputs that have
> >> current output specified on that position, and updates the
> >> positions accordingly, if corresponding output is found.
> >>
> >> Output positions can only be set once, where config file
> >> specified option is always set, even if such output will
> >> never be present. If a certain position wasn't set, the
> >> compositor may update the position if it finds another
> >> output that wants to be placed next to the output that's
> >> being configured. In such case, first existing output that
> >> matches the position is picked up, rest is ignored.
> >>
> >> Default behaviour is still to place outputs that have
> >> no matching configuration top right.
> >>
> >> Signed-off-by: Armin Krezović <krezovic.armin at gmail.com>
> >> ---
> >>  compositor/main.c | 159 +++++++++++++++++++++++++++++++++++++++++++++++++++---
> >>  1 file changed, 153 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/compositor/main.c b/compositor/main.c
> >> index e379d8d..c039ae6 100644
> >> --- a/compositor/main.c
> >> +++ b/compositor/main.c
> >> @@ -480,20 +480,167 @@ wet_init_parsed_options(struct weston_compositor *ec)
> >>  	return config;
> >>  }
> >>  
> >> +static struct wet_output *
> >> +wet_output_from_output(struct wet_compositor *compositor, struct weston_output *output)
> >> +{
> >> +	struct wet_output *iterator, *next;
> >> +
> >> +	if (wl_list_empty(&compositor->output_layout_list))
> >> +		return NULL;
> >> +
> >> +	wl_list_for_each_safe(iterator, next, &compositor->output_layout_list, link) {
> >> +		if (iterator->output == output)
> >> +			return iterator;
> >> +	}  
> > 
> > Hi,
> > 
> > wet_output uses a destroy listener on the output, so use that:
> > 
> > listener = wl_signal_get(&output->destroy_signal, handle_output_destroy);
> > wet_output = container_of(...);
> >   
> 
> Thanks for the hint.
> 
> >> +
> >> +	return NULL;
> >> +}
> >> +
> >> +static struct wet_output *
> >> +wet_output_from_name(struct wet_compositor *compositor, const char *name)
> >> +{
> >> +	struct wet_output *iterator, *next;
> >> +
> >> +	if (wl_list_empty(&compositor->output_layout_list))
> >> +		return NULL;
> >> +
> >> +	wl_list_for_each_safe(iterator, next, &compositor->output_layout_list, link) {
> >> +		if (!strcmp(iterator->output->name, name))
> >> +			return iterator;
> >> +	}  
> > 
> > No need to check for empty list, and no need to use _safe. Applies
> > probably to all loop below, too.
> >   
> 
> I have been burned when using non-safe version in the past (getting
> random segfaults with non-safe version and not with safe version),
> so I keep on using it. I'll see if it's still needed.

Hi,

the _safe version is only safe against a single kind of use: removal of
the current element. If you remove any other element, it can explode
still. So you really should know when and which elements you are
removing. This is one of the nastiest traps with wl_list.

> >> +
> >> +	return NULL;
> >> +}
> >> +  
> > 
> > I kind of wonder how much sense it makes to do first just 1-D layout
> > and then later expand to 2-D layout. I fear the code re-use might be
> > non-existant.
> > 
> > If you are struggling with 2-D layout, maybe X.org could provide some
> > example?
> > 
> > I do not have a suggestion for a good layout algorithm or even a method
> > of description. People have been configuring X.org for ages, so
> > something similar might be familiar.
> > 
> > Positioning by absolute coordinates I would like to leave out if
> > possible, or at least you would need to check that:
> > - all outputs create a single connected region (so pointers can travel
> >   everywhere)
> > - no outputs overlap (IIRC this is a limitation of Weston's damage
> >   tracking)
> > 
> > 
> > Thanks,
> > pq
> >   
> 
> I have thought about 2D layout, but I have ran in a problem that I can't
> solve.
> 
> I'll try to illustrate.
> 
> 
> |--------||-------------|
> |        ||             |
> |________||             |
>           |_____________|
> |--------------|
> |              |
> |              |
> |______________|
> 
> Lets say I have an 800x600 output top left, and 1024x768 next to it.
> I want to place an 1280x1024 output below 800x600 one. I'd get something
> like this, or the output below would overlap with the one on top right.

Right.

> Now, one of the solutions is to align both of the outputs on the bottom
> border, so I get something like this:
> 
>            |-------------|
> |---------||             |
> |         ||             |
> |_________||_____________|
> |--------------|
> |              |
> |              |
> |______________|
> 
> Suggestions welcome.

The main question here is, how much do you want magic inference vs. the
user being more explicit in what he defines. I cannot say which way to
go, but I could imagine something for both.

For each output relationship, define "alignment". For left/right-of, it
would be top or bottom. For above/below-of, it would be left or right.

The question of magic vs. explicit is about what you do with alignment:
do you require the user to set it if the default is not fine, or do you
try to automatically adjust it?

In the above example, you can find the output you would overlap with,
and try to change its alignment.

One problem with magic is that it might reposition an already
positioned output when hotplugs happen, even if there was no obvious
need for it. In your example, hotplugging the bottom output could cause
the top-right output to move.

I have never really played with laying out more than trivial monitor
setups, so I cannot say what users would prefer, and even then I suck
with UI design anyway.

If we go with allowing overlap, it's possible people might complain
about misrendering, and it might be very hard to fix. Then again, maybe
not? Fixing it would be awesome.

Maybe do some experiments with overlap to see how badly it misrenders?
To see it, you either have to use the pixman-renderer, or gl-renderer
has to use EGL_EXT_buffer_age and/or EGL_EXT_swap_buffers_with_damage.
Otherwise gl-renderer will just paint everything every time, and you'll
never see the effects of damage tracking (misbehaving).

There is also the unlikely possibility that the damage tracking in
weston has gone through such changes over the years that it no longer
mis-tracks overlaps.

What does X.org do? Does it do the simple "align top/left" and punts
anything more difficult to absolute x,y settings? What about GNOME or
KDE display configuration UIs?

In the long run, fixing and ensuring that overlapped painting works
fine would be the best.


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