[PATCH weston 2/4] weston: Move output position setting to compositor
ppaalanen at gmail.com
Mon Oct 10 10:54:28 UTC 2016
On Sun, 9 Oct 2016 19:04:19 +0200
Armin Krezović <krezovic.armin at gmail.com> wrote:
> On 07.10.2016 11:58, Pekka Paalanen wrote:
> > On Fri, 30 Sep 2016 23:25:28 +0200
> > Armin Krezović <krezovic.armin at gmail.com> wrote:
> >> This moves current output positioning code and scale/transform
> >> application to the compositor itself, so the compositor
> >> can configure output layouts any way it wants.
> >> A helper function for setting x and y coordinates is also
> >> added, and couple of assertions to weston_output_enable()
> >> as well, to make sure everything has been set up.
> >> Signed-off-by: Armin Krezović <krezovic.armin at gmail.com>
> >> ---
> >> compositor/main.c | 26 ++++++++++++++++++++++++++
> >> libweston/compositor.c | 40 ++++++++++++++++++++++------------------
> >> libweston/compositor.h | 3 +++
> >> 3 files changed, 51 insertions(+), 18 deletions(-)
> > Hi,
> > moving the output positioning out from libweston and into the
> > compositor is very good. The setter for x,y is good too.
> > I'm just not sure we should assume that outputs cannot occupy the
> > negative coordinates. If one hotplugs an output to the left, I'd assume
> > the existing windows would stay put on the right. If we cannot use
> > negative coordinates, everything has to be moved to keep them at the
> > same position from the user point of view.
> > Thanks,
> > pq
> I'd rather go for the second approach - move everything to the output it
> was on, in case an output gets attached on the left of an output that had
> something displayed (weston_output_move() can be easily adapted).
I wonder if that is possible in libweston core rather than delegating
to all shells individually.
See e.g. handle_output_move() in shell.c.
You are also going to have to move all input device coordinates, so
that the pointers stay on the same outputs as they used to, and
touch-points that are down do the same.
It doesn't sound easier to me.
Moving the global coordinate frame origin involves much more than just
moving outputs. If you only move outputs, your relative input devices
may warp away from the output they were on. I'm not sure how absolute
input devices like touch screens behave. So the question is, will the
user expect the warp or not?
There are cases when you cannot avoid moving existing outputs and that
is natural. But there are also cases where you could, if you were able
to use negative coordinates (or place the first output at 1M,1M instead
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 811 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel