[PATCH weston 0/7] Initial Xwayland window positioning

Quentin Glidic sardemff7+wayland at sardemff7.net
Tue Nov 29 19:23:07 UTC 2016


On 29/11/2016 16:11, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>
> Many old X11 applications provide -geometry command line option that can be
> used to initially position the window. Some obscure applications even rely on
> this to work properly. Currently it does not work in Weston, the shell will
> unconditionally pick a place of its own.
>
> This series makes -geometry +x+y work.
>
> First it sets up the plumbing needed to deliver initial position from
> xwayland.so through libweston-desktop to the desktop shell.
>
> However, shell using the initial position is not enough because Xwayland runs
> wild with its wl_surface.commits. Commonly Xwayland does the first commit
> before xwayland.so has set up the window geometry, causing the initial
> placement to be wrong. It's a race. Xwayland also waits for frame callbacks so
> the compositor cannot ignore the commit either, because Xwayland would never
> commit again. Writing a completely separate path for Xwayland windows in Weston
> core and the shell would be ugly the least and a maintenance nightmare. Hence
> the race is suggested to be fixed with more X11 protocol, in the last patch, so
> that the first commit from Xwayland happens when everything is actually ready.
>
> A band-aid fix is to handle geometry changes on an already mapped window
> attempting to keep the content in place, but because of a related race the
> decorations are already drawn, so the window appears to jump rather than just
> grow decorations. But, arguably on-the-fly geometry changes should be handled.
>
> The jumping is fixed with the help of a new Xwayland feature:
> _WAYLAND_ALLOW_COMMITS property. With that, we not only ensure the geometry is
> set before the first commit, but also that the decorations are really fully
> drawn.
>
> The last is WIP, because when we investigated the original race, Daniel came up
> with a plan described in https://phabricator.freedesktop.org/T7622 . I have not
> yet done the XWM reorganization it calls for.
>
> This patch series is also available at:
> https://git.collabora.com/cgit/user/pq/weston.git/log/?h=x11-positioning-v1
> with a couple more debug patches on top.
>
> The Xwayland patch series needed for _XWAYLAND_ALLOW_COMMITS is:
> https://patchwork.freedesktop.org/series/15904/
> https://lists.x.org/archives/xorg-devel/2016-November/051913.html
>
> A question was presented, how _XWAYLAND_ALLOW_COMMITS would interact with
> _NET_WM_SYNC_REQUEST in both basic and extended forms:
> https://lists.x.org/archives/xorg-devel/2016-November/051932.html
>
>
> Thanks,
> pq
>
> Pekka Paalanen (7):
>   xwayland: WM debug prints
>   xwayland: add set_toplevel_with_position to internal API
>   libweston-desktop: add set_xwayland_position API
>   xwayland: detect initially positioned X11 windows
>   shell: implement set_xwayland_position
>   libweston-desktop/xwayland: react to geometry changes
>   WIP xwayland: poke _XWAYLAND_ALLOW_COMMITS

Patches 3, 5 and 6 are:
Reviewed-by: Quentin Glidic <sardemff7+git at sardemff7.net>

Same goes for 2 and 4 with the comment addressed.

1 and 7 requires too much X11-enabled brain and xwayland.c knowledge for 
now.


Cheers,


>
>  desktop-shell/shell.c                  | 37 ++++++++++++++++
>  libweston-desktop/internal.h           |  5 +++
>  libweston-desktop/libweston-desktop.c  | 10 +++++
>  libweston-desktop/libweston-desktop.h  | 33 +++++++++++++++
>  libweston-desktop/xwayland.c           | 18 ++++++++
>  xwayland/window-manager.c              | 77 +++++++++++++++++++++++++++++++++-
>  xwayland/xwayland-internal-interface.h |  2 +
>  xwayland/xwayland.h                    |  1 +
>  8 files changed, 181 insertions(+), 2 deletions(-)
>


-- 

Quentin “Sardem FF7” Glidic


More information about the wayland-devel mailing list