== Understanding why 'root window' X under Wayland may matter
In a comment on [[my entry on how the X death watch has probably
started XDeathwatchStarts]], Christopher Barts said:
> There is XWayland, and apparently it will support handling
> the root window, not just application windows: [[
> https://wayland.freedesktop.org/xserver.html]]
>
> The missing piece of the puzzle is Xweston, which apparently allows
> you to run window managers for X on Wayland: [[
> https://github.com/ackalker/Xweston]]
When I read this, at first I was puzzled about how this could work
and why this was interesting, because I couldn't imagine that an X
window manager could manage Wayland windows ([[a view I've had for
some time ../linux/WaylandView]]). Then I actually read the Xweston
README and a little light turned on in my head. The important bit
from it is this:
> [...] Xweston should allow one to run Xwayland as a bare X server
> (i.e. taking over the root window) hosted by Weston.
What this would allow you to do is to use Wayland as the graphics
driver for the X server. Provided that the Wayland protocol and API
stay sufficiently static, this would mean that people wouldn't have
to write or update graphics drivers for X, and that changes in the
Linux (or Unix) graphics environment wouldn't require changes in
X. Both of these would be handled purely by updates to [[Wayland
compositors
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Wayland_compositors]].
(Wayland would also serve as the input driver for X, and hopefully
that side of things would also require fewer or no updates.)
At one level this is not too much different than how X sometimes
works today. For instance, for Intel's graphics hardware the X
server normally outsources most of this to OpenGL via [[glamour
https://www.freedesktop.org/wiki/Software/Glamor/]] and [[_modesetting_
http://jlk.fjfi.cvut.cz/arch/manpages/man/modesetting.4]] ([[as I
found out ../linux/XCoffeeLakeDriverQuestion]]). However, specific
X drivers can still be better than [[glamour]] and this still leaves
the [[_modesetting_]] driver to keep up with any changes in kernel
modesetting, DRM setup, and so on. Outsourcing all of that to Wayland
gets X a stable interface that hopefully performs well in general,
which obviously matters a bunch if there's no one really left to
keep updating X's graphics and modesetting drivers ([[which seems
to be part of the problem XDeathwatchStarts]]).
This doesn't deal with the other half of the problem of the X death
watch, which is the quality of support for X in toolkits like GTK
and programs like Firefox. Also, you'd (still) be restricted to X
programs only; as far as I can see, you wouldn't want to try to run
Wayland programs in this environment because they wouldn't integrate
into your X session (and there might be other problems). If there
start to be Wayland-only programs and toolkits, that could be a
problem.
PS: Xweston hasn't seen any development for a long time, so I suspect
that the project is dead. Probably a modern version would be built
on top of [[wlroots https://github.com/swaywm/wlroots]] in some
way, since that seems to have become the Wayland compositor starting
point of choice.
(A really energetic person could of course skip trying to turn
wlroots into an X server backend and simply implement their favorite
X window manager for Wayland using wlroots and then manage individual
windows from X programs in parallel with windows from Wayland
programs. Note that I don't know if all of the things that X window
managers can do are possible in Wayland.)
(This is one of the entries that I write because I finally worked
something out in my own head and I don't want to forget it later.
Hopefully I worked it out correctly and I'm not missing something.)