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 12:40 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Wed, 16 Jan 2019 11:50:12 +0100
> Carlos Garnacho <carlosg at gnome.org> wrote:
>
> > 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?
>
> > > 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?
>
> Hi Carlos,
>
> I have one straw-man idea: When a Wayland compositor launches Xwayland,
> initially it does not pass the displayfd to Xwayland. Instead, it
> passes the XWM fd (just like before) and a *different* X11 listening
> socket for the setup programs.
>
> The Wayland compositor spawns the setup programs with DISPLAY set to
> point to the alternative socket. Once those programs finish or signal
> ready, then the Wayland compositor would pass the displayfd to Xwayland
> for processing.
>
> The obvious problem with this is that I don't think there is a way to
> pass a listening fd to Xwayland after start-up yet. If there was, there
> might be security considerations.
>
> Alternatively, rather than passing the displayfd later, pass it in at
> Xwayland start, but through a new command line option that does not add
> the fd to the event loop until some other message from the Wayland
> compositor.

Yeah, I was thinking something along those lines, a kind of
"maintenance channel" that takes precedence over the spawned client
data.

>
> While I believe it could be done, there is the question of how much
> people care about making it work. Are there people who need it enough?
> After all, running a script that triggers Xwayland at desktop start-up
> is probably not that bad for those who need it.

That is a fair point. This is probably more of a concern for tweaked
setups, making it easy to opt-out is not a big leap then, and could be
a good enough replacement in the mid term.

>
> There is also the point Matthieu made.
>
> Personally I'm totally happy with a "can't bother" answer. I just
> recall seeing the xrdb issue come up once or twice in the past with
> Weston.

I'm ATM making this an experimental feature in mutter (that is, not
enabled by default). I think it's worth revisiting if/when practical
cases arrive, but so far I could perfectly content myself with it
being something people bring on themselves :).

Cheers,
  Carlos