[xwayland,3/3] xwayland: Handle the case of windows being realized before redirection

Submitted by Carlos Garnacho on Jan. 15, 2019, 10:21 p.m.

Details

Message ID 20190115222105.4817-3-carlosg@gnome.org
State New
Headers show
Series "Series without cover letter" ( rev: 1 ) in X.org

Not browsing as part of any series.

Commit Message

Carlos Garnacho Jan. 15, 2019, 10:21 p.m.
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@gnome.org>
---
 hw/xwayland/xwayland.c | 37 +++++++++++++++++++++++++++++++++++++
 hw/xwayland/xwayland.h |  1 +
 2 files changed, 38 insertions(+)

Patch hide | download patch | download mbox

diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 279358e07..6f7d64ca8 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -688,6 +688,40 @@  xwl_unrealize_window(WindowPtr window)
     return ret;
 }
 
+static void
+xwl_set_window_pixmap(WindowPtr window,
+                      PixmapPtr pixmap)
+{
+    ScreenPtr screen = window->drawable.pScreen;
+    struct xwl_screen *xwl_screen;
+    struct xwl_window *xwl_window;
+
+    xwl_screen = xwl_screen_get(screen);
+
+    screen->SetWindowPixmap = xwl_screen->SetWindowPixmap;
+    (*screen->SetWindowPixmap) (window, pixmap);
+    xwl_screen->SetWindowPixmap = screen->SetWindowPixmap;
+    screen->SetWindowPixmap = xwl_set_window_pixmap;
+
+    if (!RegionNotEmpty(&window->winSize))
+        return;
+
+    xwl_window = xwl_window_get(window);
+    if (xwl_window)
+        return;
+
+    if (xwl_screen->rootless) {
+        if (window->redirectDraw != RedirectDrawManual)
+            return;
+    }
+    else {
+        if (window->parent)
+            return;
+    }
+
+    create_surface_for_window(window);
+}
+
 static void
 frame_callback(void *data,
                struct wl_callback *callback,
@@ -1147,6 +1181,9 @@  xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
     xwl_screen->CloseScreen = pScreen->CloseScreen;
     pScreen->CloseScreen = xwl_close_screen;
 
+    xwl_screen->SetWindowPixmap = pScreen->SetWindowPixmap;
+    pScreen->SetWindowPixmap = xwl_set_window_pixmap;
+
     pScreen->CursorWarpedTo = xwl_cursor_warped_to;
     pScreen->CursorConfinedTo = xwl_cursor_confined_to;
 
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 1559b114d..65f12d478 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -130,6 +130,7 @@  struct xwl_screen {
     UnrealizeWindowProcPtr UnrealizeWindow;
     DestroyWindowProcPtr DestroyWindow;
     XYToWindowProcPtr XYToWindow;
+    SetWindowPixmapProcPtr SetWindowPixmap;
 
     struct xorg_list output_list;
     struct xorg_list seat_list;

Comments

On Tue, 15 Jan 2019 23:21:05 +0100
Carlos Garnacho <carlosg@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@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?


Thanks,
pq
Hi

On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Tue, 15 Jan 2019 23:21:05 +0100
> Carlos Garnacho <carlosg@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@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)

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?

Cheers,
Olivier
On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan@redhat.com> wrote:
>
> Hi
>
> On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Tue, 15 Jan 2019 23:21:05 +0100
> > Carlos Garnacho <carlosg@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@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?

Cheers,
Olivier
On Wed, Jan 16, 2019 at 9:56 AM Olivier Fourdan <ofourdan@redhat.com> wrote:
> On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan@redhat.com> wrote:
> >
> > Hi
> >
> > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > > On Tue, 15 Jan 2019 23:21:05 +0100
> > > Carlos Garnacho <carlosg@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@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?

Humm, thinking more about it, it would still be racy, because mutter
for example (and I think weston as well) reckons Xwayland is started
as soon as it writes to the displayfd, so it won't wait for a script
to complete...

So Xwayland would have to differ writing to displayfd until the
"startup" script is complete (while still accepting connections so
that the clients started from the script can run).

Problem, `NotifyParentProcess()` (which writes to the displayfd) is
invoked directly from `dix_main()` so Xwayland doesn't have much
control over that.

Cheers
Olivier
On Wed, Jan 16, 2019 at 10:35:13AM +0200, Pekka Paalanen wrote:
> On Tue, 15 Jan 2019 23:21:05 +0100
> Carlos Garnacho <carlosg@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@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?

Hi,

At least for traditional Xlib/Xt applications, The ~/.Xdefaults file is
read by applications. It's less efficient than having resouces loaded
in the X server by xrdb, but you can always link .Xdefaults to
.Xresources for this kind of situation.

Not sure if Gtk/Qt/whatever use the Xlib functions or if they have
their own code that would ignore .Xdefaults.
On Wed, 16 Jan 2019 09:56:59 +0100
Olivier Fourdan <ofourdan@redhat.com> wrote:

> On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan@redhat.com> wrote:
> >
> > Hi
> >
> > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:  
> > >
> > > On Tue, 15 Jan 2019 23:21:05 +0100
> > > Carlos Garnacho <carlosg@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@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.

If we have a solution for the xrdb case, then I don't think there is a
need to handle the XWM start-up race any different. Only the
preparation X11 clients would run unhindered until the Wayland
compositor decides the preparations have finished and it's time to
start serving the real X11 apps that have been waiting for the X server
to start talking to them.


Thanks,
pq
Hi!,

On Wed, Jan 16, 2019 at 10:52 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Wed, 16 Jan 2019 09:56:59 +0100
> Olivier Fourdan <ofourdan@redhat.com> wrote:
>
> > On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan@redhat.com> wrote:
> > >
> > > Hi
> > >
> > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > >
> > > > On Tue, 15 Jan 2019 23:21:05 +0100
> > > > Carlos Garnacho <carlosg@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@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
On Wed, 16 Jan 2019 11:50:12 +0100
Carlos Garnacho <carlosg@gnome.org> wrote:

> Hi!,
> 
> On Wed, Jan 16, 2019 at 10:52 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > On Wed, 16 Jan 2019 09:56:59 +0100
> > Olivier Fourdan <ofourdan@redhat.com> wrote:
> >  
> > > On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan@redhat.com> wrote:  
> > > >
> > > > Hi
> > > >
> > > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:  
> > > > >
> > > > > On Tue, 15 Jan 2019 23:21:05 +0100
> > > > > Carlos Garnacho <carlosg@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@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
Hi!,

On Wed, Jan 16, 2019 at 10:54 AM Matthieu Herrb <matthieu@herrb.eu> wrote:
>
> On Wed, Jan 16, 2019 at 10:35:13AM +0200, Pekka Paalanen wrote:
> > On Tue, 15 Jan 2019 23:21:05 +0100
> > Carlos Garnacho <carlosg@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@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?
>
> Hi,
>
> At least for traditional Xlib/Xt applications, The ~/.Xdefaults file is
> read by applications. It's less efficient than having resouces loaded
> in the X server by xrdb, but you can always link .Xdefaults to
> .Xresources for this kind of situation.
>
> Not sure if Gtk/Qt/whatever use the Xlib functions or if they have
> their own code that would ignore .Xdefaults.

I just checked gtk+, and it seems indeed that XGetDefault is called
along gtk+ initialization, mainly pango and cairo which seem to make
sense. I'm not sure about Qt.

However, those are often not the ones to worry about :), as it's
likely they'll run on wayland backends. Probably more of a concern for
the other apps that won't/can't detach from x11, and maybe harder to
get an homogeneous response there. Still, sounds like a possibility.

Cheers,
  Carlos
Hi!,

On Wed, Jan 16, 2019 at 12:40 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Wed, 16 Jan 2019 11:50:12 +0100
> Carlos Garnacho <carlosg@gnome.org> wrote:
>
> > Hi!,
> >
> > On Wed, Jan 16, 2019 at 10:52 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > > On Wed, 16 Jan 2019 09:56:59 +0100
> > > Olivier Fourdan <ofourdan@redhat.com> wrote:
> > >
> > > > On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <ofourdan@redhat.com> wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > > > > >
> > > > > > On Tue, 15 Jan 2019 23:21:05 +0100
> > > > > > Carlos Garnacho <carlosg@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@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
On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote:

> 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.

Who's launching this first X11 app, and why are they unable to defer
launching it until the Xwayland is prepared? There's quite a few ways
we could add this kind of interlock to setup, I just want to clarify
which problem we're solving first.

- ajax
On Wed, 16 Jan 2019 14:05:01 -0500
Adam Jackson <ajax@nwnk.net> wrote:

> On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote:
> 
> > 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.  
> 
> Who's launching this first X11 app, and why are they unable to defer
> launching it until the Xwayland is prepared? There's quite a few ways
> we could add this kind of interlock to setup, I just want to clarify
> which problem we're solving first.

Hi Adam,

any user action could be starting the very first real X11 app:
- user clicking a launcher icon on the desktop, e.g. for a game
- user issuing a command in a shell in a terminal window
- a Wayland app launching another app that just happens to be an X11 app

In the current setup of on-demand Xwayland, the Wayland compositor will
be listening on the X11 DISPLAY socket. When the Wayland compositor
sees the first X11 client attempting to connect, it will launch
Xwayland process and passes the listening socket to it.

IOW, the real X11 apps exists and attempts to connect first, which then
leads to spawning the Xwayland server. That can of course be changed if
there are better ideas. The main point of on-demand launching is that
Xwayland doesn't get started at the same time with the rest of the
desktop environment, unless there really is a X11 app to be ran.


Thanks,
pq
Hi,

On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Wed, 16 Jan 2019 14:05:01 -0500
> Adam Jackson <ajax@nwnk.net> wrote:
>
> > On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote:
> >
> > > 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.
> >
> > Who's launching this first X11 app, and why are they unable to defer
> > launching it until the Xwayland is prepared? There's quite a few ways
> > we could add this kind of interlock to setup, I just want to clarify
> > which problem we're solving first.
>
> Hi Adam,
>
> any user action could be starting the very first real X11 app:
> - user clicking a launcher icon on the desktop, e.g. for a game
> - user issuing a command in a shell in a terminal window
> - a Wayland app launching another app that just happens to be an X11 app
>
> In the current setup of on-demand Xwayland, the Wayland compositor will
> be listening on the X11 DISPLAY socket. When the Wayland compositor
> sees the first X11 client attempting to connect, it will launch
> Xwayland process and passes the listening socket to it.
>
> IOW, the real X11 apps exists and attempts to connect first, which then
> leads to spawning the Xwayland server. That can of course be changed if
> there are better ideas. The main point of on-demand launching is that
> Xwayland doesn't get started at the same time with the rest of the
> desktop environment, unless there really is a X11 app to be ran.

For xrdb specifically, actually, the X11 resources are stored in a
couple of properties on the root window ("RESOURCE_MANAGER" and
"SCREEN_RESOURCES") so Xwayland /could/ set those on init, it's more
the whole logic of merging resources from different files, optionally
invoking a C preprocessor, etc. that would be painful in Xwayland
IMHO.

So if there was a way to (re)use xrdb to send the resources string to
stdout instead of setting the property itself, Xwayland could possibly
get values to set the properties and do that on startup before any X11
client had a chance to connect.

Maybe that would be simplereasier than having side-channels or
interlocking in place at startup?

Cheers,
Olivier
On Thu, 17 Jan 2019 09:47:05 +0100
Olivier Fourdan <ofourdan@redhat.com> wrote:

> Hi,
> 
> On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> For xrdb specifically, actually, the X11 resources are stored in a
> couple of properties on the root window ("RESOURCE_MANAGER" and
> "SCREEN_RESOURCES") so Xwayland /could/ set those on init, it's more
> the whole logic of merging resources from different files, optionally
> invoking a C preprocessor, etc. that would be painful in Xwayland
> IMHO.
> 
> So if there was a way to (re)use xrdb to send the resources string to
> stdout instead of setting the property itself, Xwayland could possibly
> get values to set the properties and do that on startup before any X11
> client had a chance to connect.
> 
> Maybe that would be simplereasier than having side-channels or
> interlocking in place at startup?

Hi Olivier,

maybe, but that is again a solution to just one specific issue, while I
believe there is a whole category of issues like this. The XWM init is
another.

If someone starts a X11 window manager as the very first X11 client,
could that break the whole Wayland compositor's XWM thing completely?
Do we want to protect against that?

Is it worth to solve the whole category at once? I don't know.


Thanks,
pq
Hi Adam & Pekka,

On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Wed, 16 Jan 2019 14:05:01 -0500
> Adam Jackson <ajax@nwnk.net> wrote:
>
> > On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote:
> >
> > > 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.
> >
> > Who's launching this first X11 app, and why are they unable to defer
> > launching it until the Xwayland is prepared? There's quite a few ways
> > we could add this kind of interlock to setup, I just want to clarify
> > which problem we're solving first.
>
> Hi Adam,
>
> any user action could be starting the very first real X11 app:
> - user clicking a launcher icon on the desktop, e.g. for a game
> - user issuing a command in a shell in a terminal window
> - a Wayland app launching another app that just happens to be an X11 app
>
> In the current setup of on-demand Xwayland, the Wayland compositor will
> be listening on the X11 DISPLAY socket. When the Wayland compositor
> sees the first X11 client attempting to connect, it will launch
> Xwayland process and passes the listening socket to it.

That's exactly what I did too for mutter at
https://gitlab.gnome.org/GNOME/mutter/commits/wip/carlosg/xwayland-on-demand

Cheers,
  Carlos
Hi Pekka,

On Thu, Jan 17, 2019 at 10:04 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> On Thu, 17 Jan 2019 09:47:05 +0100
> Olivier Fourdan <ofourdan@redhat.com> wrote:
>
> > Hi,
> >
> > On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> > >
> > For xrdb specifically, actually, the X11 resources are stored in a
> > couple of properties on the root window ("RESOURCE_MANAGER" and
> > "SCREEN_RESOURCES") so Xwayland /could/ set those on init, it's more
> > the whole logic of merging resources from different files, optionally
> > invoking a C preprocessor, etc. that would be painful in Xwayland
> > IMHO.
> >
> > So if there was a way to (re)use xrdb to send the resources string to
> > stdout instead of setting the property itself, Xwayland could possibly
> > get values to set the properties and do that on startup before any X11
> > client had a chance to connect.
> >
> > Maybe that would be simplereasier than having side-channels or
> > interlocking in place at startup?
>
> Hi Olivier,
>
> maybe, but that is again a solution to just one specific issue, while I
> believe there is a whole category of issues like this. The XWM init is
> another.
>
> If someone starts a X11 window manager as the very first X11 client,
> could that break the whole Wayland compositor's XWM thing completely?
> Do we want to protect against that?

In this concrete case, the compositor might also shot Xwayland down if
it fails to acquire the WM selection.

>
> Is it worth to solve the whole category at once? I don't know.

Maybe belonging in the category is Xsettings management, esp. those
that affect UI. It might be visually jarring if the client gets to
display with different theme/icons than the ones it'll eventually get.
Again not sure how much of a practical problem this is, accounting
that toolkits should be good about wayland support, and the outliers
are probably not concerned about Xsettings.

Anyhow, saying "what a compositor may want to run before launching a
x11 client is compositor-dependent" doesn't help give any shape to the
issue :).

Cheers,
  Carlos

>
>
> Thanks,
> pq
Hi,

Catching up on this thread. It's possible I missed something here, but
here's my two cents.

Right now, the Wayland compositor sets up a "dummy" socket for the X11
display. When a client connects, it launches Xwayland on-demand. I assume
this socket handoff is done similar to the systemd approach, where FDs are
inherited into execution context and their names passed by some convention
like LISTEN_FDS.

Until Xwayland adds the socket to its own loop, the client is paused
anyway. So there are no race conditions here -- the race condition only
happens once Xwayland adds the socket. What if we had a special Wayland
event like "add_listen_fd", using Wayland's FD passing, which would add a
new FD to the listen loop of Xorg. With this, we can create a three-stage
initialization process: 1. Create a special "setup" FD, pass it to
add_listen_fd. 2. Run gnome-settings-daemon, xrdb, on this "setup" FD. 3.
After initialization settles, we then pass the client-activated socket
through "add_listen_fd", and the client will finish the handshake process.

The implementation difficulty here is passing the special setup FD to
clients -- we would have to modify Xlib to allow connecting to an X11
socket by FD (using something like xcb_connect_to_fd), and we would have to
ensure that this all inherits to children correctly if
gnome-settings-daemon needs to launch clients during setup (I think glib
forces O_CLOEXEC before spawning children now -- oops). But FD passing for
initialization is already "the right way" to do things in a systemd world,
so it's probably something investing in.

A quick and dirty prototype of this that wouldn't require FD passing could
simply use DISPLAY=:99 as the "setup display".

Thoughts?

On Thu, Jan 17, 2019 at 3:41 AM Carlos Garnacho <carlosg@gnome.org> wrote:

> Hi Pekka,
>
> On Thu, Jan 17, 2019 at 10:04 AM Pekka Paalanen <ppaalanen@gmail.com>
> wrote:
> >
> > On Thu, 17 Jan 2019 09:47:05 +0100
> > Olivier Fourdan <ofourdan@redhat.com> wrote:
> >
> > > Hi,
> > >
> > > On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen@gmail.com>
> wrote:
> > > >
> > > For xrdb specifically, actually, the X11 resources are stored in a
> > > couple of properties on the root window ("RESOURCE_MANAGER" and
> > > "SCREEN_RESOURCES") so Xwayland /could/ set those on init, it's more
> > > the whole logic of merging resources from different files, optionally
> > > invoking a C preprocessor, etc. that would be painful in Xwayland
> > > IMHO.
> > >
> > > So if there was a way to (re)use xrdb to send the resources string to
> > > stdout instead of setting the property itself, Xwayland could possibly
> > > get values to set the properties and do that on startup before any X11
> > > client had a chance to connect.
> > >
> > > Maybe that would be simplereasier than having side-channels or
> > > interlocking in place at startup?
> >
> > Hi Olivier,
> >
> > maybe, but that is again a solution to just one specific issue, while I
> > believe there is a whole category of issues like this. The XWM init is
> > another.
> >
> > If someone starts a X11 window manager as the very first X11 client,
> > could that break the whole Wayland compositor's XWM thing completely?
> > Do we want to protect against that?
>
> In this concrete case, the compositor might also shot Xwayland down if
> it fails to acquire the WM selection.
>
> >
> > Is it worth to solve the whole category at once? I don't know.
>
> Maybe belonging in the category is Xsettings management, esp. those
> that affect UI. It might be visually jarring if the client gets to
> display with different theme/icons than the ones it'll eventually get.
> Again not sure how much of a practical problem this is, accounting
> that toolkits should be good about wayland support, and the outliers
> are probably not concerned about Xsettings.
>
> Anyhow, saying "what a compositor may want to run before launching a
> x11 client is compositor-dependent" doesn't help give any shape to the
> issue :).
>
> Cheers,
>   Carlos
>
> >
> >
> > Thanks,
> > pq
> _______________________________________________
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
On Sun, 20 Jan 2019 09:29:50 -0800
"Jasper St. Pierre" <jstpierre@mecheye.net> wrote:

> Hi,
> 
> Catching up on this thread. It's possible I missed something here, but
> here's my two cents.
> 
> Right now, the Wayland compositor sets up a "dummy" socket for the X11
> display. When a client connects, it launches Xwayland on-demand. I assume
> this socket handoff is done similar to the systemd approach, where FDs are
> inherited into execution context and their names passed by some convention
> like LISTEN_FDS.

Hi Jasper,

that is correct. IIRC the fds get named via command line arguments.

> Until Xwayland adds the socket to its own loop, the client is paused
> anyway. So there are no race conditions here -- the race condition only
> happens once Xwayland adds the socket. What if we had a special Wayland
> event like "add_listen_fd", using Wayland's FD passing, which would add a
> new FD to the listen loop of Xorg. With this, we can create a three-stage
> initialization process: 1. Create a special "setup" FD, pass it to
> add_listen_fd. 2. Run gnome-settings-daemon, xrdb, on this "setup" FD. 3.
> After initialization settles, we then pass the client-activated socket
> through "add_listen_fd", and the client will finish the handshake process.

That is very much the idea I presented, but I didn't specify how to
pass fds to Xwayland after its start-up.

> The implementation difficulty here is passing the special setup FD to
> clients -- we would have to modify Xlib to allow connecting to an X11
> socket by FD (using something like xcb_connect_to_fd), and we would have to
> ensure that this all inherits to children correctly if
> gnome-settings-daemon needs to launch clients during setup (I think glib
> forces O_CLOEXEC before spawning children now -- oops). But FD passing for
> initialization is already "the right way" to do things in a systemd world,
> so it's probably something investing in.
> 
> A quick and dirty prototype of this that wouldn't require FD passing could
> simply use DISPLAY=:99 as the "setup display".
> 
> Thoughts?

I think the DISPLAY=:99 approach would be sufficient if someone wants
to implement this. The setup socket has no special meaning after the
start-up sequence, so it could be used for normal apps as well, which
means that if someone e.g. starts a panel app from the setup script, it
won't hurt if that app then launches more X11 apps with the setup
socket.

If a Wayland compositor launches an arbitrary script to initialize
Xwayland server state, the compositor could take the exit of that
process to signify the setup from the script is complete. The
compositor could even launch the script only after its own XWM is ready.


Thanks,
pq