Linux: say what the XWayland compositing gate actually tests

DISPLAY and WAYLAND_DISPLAY are both set in a native Wayland session as
well, because GNOME and KDE run Xwayland as part of the session and export
DISPLAY for it whether or not this process is an X client. The pair means
XWayland is available in the session, not that GTK picked X11 for this
process, so "(an XWayland session)" reads as more than the condition
establishes.

Say what the pair means, and name the case the fallback actually covers:
the X11 backend inside a Wayland session, which is what the forced
GDK_BACKEND=x11 above produces in a build without EGL.

Comment only; behaviour is unchanged.
This commit is contained in:
Lam Wei Lun
2026-10-14 21:51:24 +08:00
parent 2b736dd268
commit 7ef09349b6
+7 -3
View File
@@ -1217,9 +1217,13 @@ int CLI::run(int argc, char **argv)
// WebKit2GTK accelerated compositing could fail under XWayland
// on WebKit releases before 2.42. Disable it only then, and only
// when both DISPLAY and WAYLAND_DISPLAY are set (an XWayland
// session). Disabling it also turns off threaded scrolling, so on
// newer WebKit it only costs performance.
// when both DISPLAY and WAYLAND_DISPLAY are set. Those two mean the
// session offers XWayland, not that GTK picked X11 for this
// process: a native Wayland app inherits both. The default path
// runs X11 here only in a build without EGL, which is what the
// forced GDK_BACKEND=x11 above produces. Disabling compositing also
// turns off threaded scrolling, so on newer WebKit it only costs
// performance.
{
const char* display_env_wk = ::getenv("DISPLAY");
const char* wayland_env_wk = ::getenv("WAYLAND_DISPLAY");