On Tue, 15 Jan 2019 23:21:05 +0100 Carlos Garnacho <[email protected]> wrote:
> If Xwayland gets to realize a window meant for composition before the > compositor redirected windows (i.e. redirect mode is not RedirectDrawManual > yet), the window would stay "invisible" as we wouldn't create a > wl_surface/wl_shell_surface for it at any later point. > > This scenario may happen if the wayland compositor raises Xwayland on > demand for a X11 client being started. In this case the first data on > the socket is the client's, the compositor can hardly beat that in > order to redirect subwindows before the client realizes a Window. > > In order to handle this case, allow the late creation of a matching > (shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured > to be created after the compositor set up redirection. > > Signed-off-by: Carlos Garnacho <[email protected]> > --- > hw/xwayland/xwayland.c | 37 +++++++++++++++++++++++++++++++++++++ > hw/xwayland/xwayland.h | 1 + > 2 files changed, 38 insertions(+) Hi Carlos, this reminds me of other ordering issues with starting Xwayland on demand: xrdb. I presume the X resources should be merged before any app X11 client is processed, so that they see the user's resources at start-up. AFAIK, that cannot happen if Xwayland is started on-demand. Either it is too late if app start-up triggers it, or then you launch Xwayland at desktop start-up, essentially not doing on-demand anymore. Have you seen people complain about that? Could that be fixed somehow? Pass the X11 app socket to Xwayland later after the XWM init is complete? Stall non-XWM clients inside Xwayland by default until XWM is ready? Thanks, pq
pgpSd0yJ20KZT.pgp
Description: OpenPGP digital signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
