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

[Pekka Paalanen]

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.

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.

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20190116/6c02b3e3/attachment.sig>