Hi!, On Wed, Jan 16, 2019 at 12:40 PM Pekka Paalanen <[email protected]> wrote: > > On Wed, 16 Jan 2019 11:50:12 +0100 > Carlos Garnacho <[email protected]> wrote: > > > Hi!, > > > > On Wed, Jan 16, 2019 at 10:52 AM Pekka Paalanen <[email protected]> wrote: > > > > > > On Wed, 16 Jan 2019 09:56:59 +0100 > > > Olivier Fourdan <[email protected]> wrote: > > > > > > > On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan <[email protected]> > > > > wrote: > > > > > > > > > > Hi > > > > > > > > > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen <[email protected]> > > > > > wrote: > > > > > > > > > > > > On Tue, 15 Jan 2019 23:21:05 +0100 > > > > > > Carlos Garnacho <[email protected]> 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 <[email protected]> > > > > > > > --- > > > > > > > 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
