Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

[Carlos Garnacho]

Hi!,

On Wed, Jan 16, 2019 at 10:52 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Wed, 16 Jan 2019 09:56:59 +0100
> Olivier Fourdan <ofourdan at redhat.com> wrote:
>
> > On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan at redhat.com> wrote:
> > >
> > > Hi
> > >
> > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > > >
> > > > On Tue, 15 Jan 2019 23:21:05 +0100
> > > > Carlos Garnacho <carlosg at gnome.org> 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 <carlosg at gnome.org>
> > > > > ---
> > > > >  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?
> > >
> > > I am not sure I understand what xwayland-on-demand changes there.
> > >
> > > Considering "xrdb" is a regular X11 client, it requires a display,
> > > hence it must have Xwayland running.
> > >
> > > If Xwayland is not running (i.e. xrdb is the first X11 client to be
> > > started), then Xwayland will be started (as there is a "demand" from a
> > > client, the client being xrdb) and other following X11 clients will
> > > connect to the same display and have the resources set in xrdb
> > > available.
> > >
> > > I remember Ray (halfline) advocating for Xwayland running xrdb itself
> > > at startup to avoid this issue. But that's a bit of a special case for
> > > specific X11 client (xrdb) which could be considered as legacy...
> > > (like, people may not want to slow down Xwayland startup waiting for
> > > xrdb to complete when they don't actually use any X11 application
> > > benefiting from the X11 resources database)
> >
> > There: https://bugzilla.gnome.org/show_bug.cgi?id=769644
> >
> > > Maybe a more general design of a script being run automatically by
> > > Xwayland if present, so that users/distro-maintainers/sysadmins can
> > > tailor that startup script at will?
>
> Hi Olivier,
>
> the problem is this sequence:
>
> 1. Desktop is starts up
>
> time passes, the user doing things...
>
> 2. The user starts the first real X11 application (not xrdb), which triggers
> the launch of Xwayland in the Wayland compositor.
>
> 3. Xwayland processes the X11 application, but the resources database
> has not been loaded, so the application is not following the user
> preferences.
>
> Right now, there is only one way to solve this: at step 1, run xrdb to
> load the resources database. But that has the side-effect that it will
> launch Xwayland, when the whole point is to postpone Xwayland launch
> until the first real X11 application is launched. IOW, we lose the
> on-demand launch of Xwayland, because now it happens at desktop start
> time anyway.
>
> You cannot launch xrdb at step 2 or 3, because the X11 app will race
> against it and probably win, which means the application doesn't see
> the right resources.
>
> What I think we would need is a way to launch Xwayland, but ensure it
> does not process the real X11 apps until all the preparations (xrdb,
> XWM init, etc.) have finished. What the preparations are exactly, only
> the Wayland compositor (the desktop) will know.

I TBH didn't remember about xrdb, but there's similar concerns with
other services that do provide settings to x11 clients (eg.
gnome-settings-daemon through xsettings), just with the small nicety
here that applications would eventually respond to changes.

I'm not sure it can be handled that much generically if we have
"random" clients belong to the initialization phase :( (the
compositor/session might know best though). I thought adding a side
channel might a be a possibility, but then how to funnel those clients
through it? And how to know they are done initializing?

Cheers,
  Carlos