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

Olivier Fourdan ofourdan at redhat.com
Thu Jan 17 08:47:05 UTC 2019


Hi,

On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Wed, 16 Jan 2019 14:05:01 -0500
> Adam Jackson <ajax at 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


More information about the xorg-devel mailing list