<div dir="ltr"><div>Hi,</div><div><br></div><div>Catching up on this thread. It's possible I missed something here, but here's my two cents.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>A quick and dirty prototype of this that wouldn't require FD passing could simply use DISPLAY=:99 as the "setup display".</div><div><br></div><div>Thoughts?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 17, 2019 at 3:41 AM Carlos Garnacho <<a href="mailto:carlosg@gnome.org">carlosg@gnome.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Pekka,<br>
<br>
On Thu, Jan 17, 2019 at 10:04 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote:<br>
><br>
> On Thu, 17 Jan 2019 09:47:05 +0100<br>
> Olivier Fourdan <<a href="mailto:ofourdan@redhat.com" target="_blank">ofourdan@redhat.com</a>> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote:<br>
> > ><br>
> > For xrdb specifically, actually, the X11 resources are stored in a<br>
> > couple of properties on the root window ("RESOURCE_MANAGER" and<br>
> > "SCREEN_RESOURCES") so Xwayland /could/ set those on init, it's more<br>
> > the whole logic of merging resources from different files, optionally<br>
> > invoking a C preprocessor, etc. that would be painful in Xwayland<br>
> > IMHO.<br>
> ><br>
> > So if there was a way to (re)use xrdb to send the resources string to<br>
> > stdout instead of setting the property itself, Xwayland could possibly<br>
> > get values to set the properties and do that on startup before any X11<br>
> > client had a chance to connect.<br>
> ><br>
> > Maybe that would be simplereasier than having side-channels or<br>
> > interlocking in place at startup?<br>
><br>
> Hi Olivier,<br>
><br>
> maybe, but that is again a solution to just one specific issue, while I<br>
> believe there is a whole category of issues like this. The XWM init is<br>
> another.<br>
><br>
> If someone starts a X11 window manager as the very first X11 client,<br>
> could that break the whole Wayland compositor's XWM thing completely?<br>
> Do we want to protect against that?<br>
<br>
In this concrete case, the compositor might also shot Xwayland down if<br>
it fails to acquire the WM selection.<br>
<br>
><br>
> Is it worth to solve the whole category at once? I don't know.<br>
<br>
Maybe belonging in the category is Xsettings management, esp. those<br>
that affect UI. It might be visually jarring if the client gets to<br>
display with different theme/icons than the ones it'll eventually get.<br>
Again not sure how much of a practical problem this is, accounting<br>
that toolkits should be good about wayland support, and the outliers<br>
are probably not concerned about Xsettings.<br>
<br>
Anyhow, saying "what a compositor may want to run before launching a<br>
x11 client is compositor-dependent" doesn't help give any shape to the<br>
issue :).<br>
<br>
Cheers,<br>
  Carlos<br>
<br>
><br>
><br>
> Thanks,<br>
> pq<br>
_______________________________________________<br>
<a href="mailto:xorg-devel@lists.x.org" target="_blank">xorg-devel@lists.x.org</a>: X.Org development<br>
Archives: <a href="http://lists.x.org/archives/xorg-devel" rel="noreferrer" target="_blank">http://lists.x.org/archives/xorg-devel</a><br>
Info: <a href="https://lists.x.org/mailman/listinfo/xorg-devel" rel="noreferrer" target="_blank">https://lists.x.org/mailman/listinfo/xorg-devel</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">  Jasper<br></div>