GNOME Bugzilla – Bug 719989
Prefer the wayland backend over the x11 one
Last modified: 2015-01-17 14:13:42 UTC
Right now, gdk tries the x11 backend first, and only if that fails, it tries the wayland backend. There are two situations with different consequences depending on whether gdk tries x11 or wayland first: If you're under X11, you want the x11 used. Having the x11 backend tried first means the x11 backend will be chosen. If the order was changed and wayland was tried first, it would normally fail and x11 would be chosen, which is good. However if you were running wayland on a different tty, or if you're running, say, weston as a window through its x11 backend, and you open a gtk+ application, the wayland backend will be chosen and it'll use the wayland backend, which would make it appear in the other tty or in the weston window, which is confusing. On the other hand, let's say you're running weston or gnome-shell-wayland. x11 is preferred over wayland (status quo). If you don't have XWayland, the x11 backend fails and you get the wayland backend, which is all good. But if you have XWayland, the x11 backend is going to work and will be preferred over the wayland backend, making apps that could run natively run through XWayland. If the wayland backend was preferred over x11, apps would run natively with the wayland backend. Those gtk+ apps that really need the x11 backend would just need to specify this with gdk_set_allowed_backends("x11"). I suppose that until wayland becomes more relevant for gtk+ we don't want the order changed, but eventually (particularly when gnome-shell-wayland becomes the recommended way to run gnome-shell and not just a beta product) we will need to change the ordering to favor the wayland backend over the x11 one.
Created attachment 263810 [details] [review] wayland: fail the backend init if WAYLAND_DISPLAY isn't set wl_display_connect() currently falls back to the wayland-0 socket if WAYLAND_DISPLAY isn't in the environment. This means that if a wayland compositor is running and you launch a GTK+ app from within X11, it may start running inside the wayland compositor. Avoid this by requiring WAYLAND_DISPLAY to be set.
Created attachment 263811 [details] [review] gdk: try the wayland backend before the x11 one If both the x11 and wayland backends are available, we want the wayland backend tried first, so that when running from a wayland compositor with XWayland support, the app runs natively with the wayland backend instead of through XWayland. This doesn't affect apps run from within X11 because there WAYLAND_DISPLAY will not be set and so the wayland backend initialization will fail.
(In reply to comment #0) > Right now, gdk tries the x11 backend first, and only if that fails, it tries > the wayland backend. > > There are two situations with different consequences depending on whether gdk > tries x11 or wayland first: > > If you're under X11, you want the x11 used. Having the x11 backend tried first > means the x11 backend will be chosen. If the order was changed and wayland was > tried first, it would normally fail and x11 would be chosen, which is good. > However if you were running wayland on a different tty, or if you're running, > say, weston as a window through its x11 backend, and you open a gtk+ > application, the wayland backend will be chosen and it'll use the wayland > backend, which would make it appear in the other tty or in the weston window, > which is confusing. With the attached patches, the x11 backend is chosen when launching apps from within x11 because the wayland backend initialization now fails as WAYLAND_BACKEND isn't set. This is desired and similar to what happens if you try to run an app without DISPLAY set. > On the other hand, let's say you're running weston or gnome-shell-wayland. x11 > is preferred over wayland (status quo). If you don't have XWayland, the x11 > backend fails and you get the wayland backend, which is all good. But if you > have XWayland, the x11 backend is going to work and will be preferred over the > wayland backend, making apps that could run natively run through XWayland. If > the wayland backend was preferred over x11, apps would run natively with the > wayland backend. Those gtk+ apps that really need the x11 backend would just > need to specify this with gdk_set_allowed_backends("x11"). With the attached patches, the wayland backend is preferred over the x11 one unless the app explicitly says that it needs the x11 backend. > I suppose that until wayland becomes more relevant for gtk+ we don't want the > order changed, but eventually (particularly when gnome-shell-wayland becomes > the recommended way to run gnome-shell and not just a beta product) we will > need to change the ordering to favor the wayland backend over the x11 one. So with the above patches, I think our behaviour is correct in all cases and we can proceed with this now.
We had 'prefer wayland' for a while during the 3.9 cycle, but we reverted it before 3.10. We are just not ready for it.
(In reply to comment #4) > We had 'prefer wayland' for a while during the 3.9 cycle, but we reverted it > before 3.10. We are just not ready for it. OK I've just seen commit 04d6d6 and the revert 1b93b5. I guess changing this is still desirable but perhaps only when wayland is mainstream for us (i.e. when we actually recommend gnome-shell/wayland). And when we do it, we should have clutter do the switch too.
(In reply to comment #4) > We had 'prefer wayland' for a while during the 3.9 cycle, but we reverted it > before 3.10. We are just not ready for it. I wonder about this. I use Gentoo, so it makes it quite easy to try things like this out. I've got my gtk+ built with wayland first, and patched clutter-gtk to default to the wayland backend if WAYLAND_DISPLAY is defined in the environment. I'm using GNOME 3.14.x with gnome-shell from git, git webkit-gtk is also patched for wayland-egl and epiphany (also from git) has a couple of local patches, quite frankly, it works very well! I'm not saying it's perfect, there are a few little regressions, but the only way these things are going to get noticed, and fixed, is if people try it, and the only way people are going to try it, is if they give gnome-wayland a spin and get wayland clients, rather than X11 clients through Xwayland. gnome/gtk wayland bugs in general aren't going to get picked up, in particular, very few clients are actually specifying their supported GDK backends, so if they *really* depend on X11, they need to say so. This isn't goinig to get noticed if the default backend is X11 even on Wayland. I was actually quite surprised how well it all worked, the biggest usability bug I've encountered is with gnome-terminal input, which doesn't always send the input stream to the correct terminal window! I'll open a new bug for this if I can't find an existing one. Okay, maybe 2013 was too early; one year later, I think it's time...
I'm trying this again