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

[Jasper St. Pierre]

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 at gnome.org> wrote:

> Hi Pekka,
>
> On Thu, Jan 17, 2019 at 10:04 AM Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> >
> > On Thu, 17 Jan 2019 09:47:05 +0100
> > Olivier Fourdan <ofourdan at redhat.com> wrote:
> >
> > > Hi,
> > >
> > > On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen at 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 at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20190120/2ff3401e/attachment.html>