[gentoo-amd64] Re: Wayland and X-Window

[Duncan]

Frank Peters posted on Fri, 18 Oct 2013 21:36:09 -0400 as excerpted:

> Up and coming, like it or not, from the Freedesktop project is the
> X-Window replacement called Wayland.  Gentoo is already involved with
> Wayland although it is still considered experimental.
>
> My concern is whether or not Wayland will totally supplant X-Window or
> will it exist as an option to X-Window.  That is, when Wayland becomes
> finally ready for prime time, will we all be forced to adopt it with no
> alternative or will the standard X-Window also be a choice?

Good question.  Note that it can actually be seen as two separate 
questions, one in general, and one as it applies to gentoo, specifically.

For the general case, from all I've read, all the informed sources seem 
to expect the two to coexist together for some time, if I were to guess, 
I'd say three years or so minimum, and likely far longer in some distros, 
particularly those like gentoo and debian that support platforms running 
more than just the Linux kernel and general GNU-based userland.  Given 
that the BSDs tend to move at a somewhat slower pace than Linux and some 
of the wayland technology is currently most developed on Linux, it'll 
likely be longer, I'd guess at least five years and very possibly a 
decade or more, on them.

It's also worth noting that with some of the enterprise distros having 
support terms of nearing a decade, even if/when "current" linux drops 
xorg, support will still be around for xorg (on those old distros) for a 
(relatively) very long time.

Of course the picture is rather more complex than that simple top-of-the-
fold summary implies.

* "xwayland" is an xserver run as a wayland client.  There are already 
xwayland patches for xorg that make it run as a wayland client instead of 
directly, and now that xorg-server 1.15 has been delayed in ordered to 
add more features, the xwayland patches could well make it.  This will 
provide the X-protocol backward compatibility for wayland, so it can 
continue to run X apps that haven't been ported to wayland yet.

(In the original plans I remember reading that the plan was for this to 
work both ways, such that wayland could be run as an X client, as well, 
but I haven't read anything about that lately so I don't know what the 
status is on that.)

* Wayland is already using mesa as one of its OpenGL backends backends 
(with others available where hardware isn't able to run OpenGL/EGL), 
rendering to OpenGL/EGL.  So currently X-based apps that speak OpenGL/EGL 
should continue to run as well, using xwayland for the X-protocol stuff 
they do, and mesa (or other OpenGL/EGL implementations) where they 
already speak OpenGL directly.

So there shouldn't be too much problem with people being stranded with X 
apps they can no longer run, because xwayland, a modified xorg-server, 
will be available for wayland, and X clients can talk to it as they 
always have to xorg, and to mesa or other opengl/egl implementation 
directly where they are already bypassing X using them.


* On the flip-side, it's worth noting that the wayland/weston devs and 
xorg devs are generally the same people.  After wayland gets going, their 
focus is going to be almost entirely on it, and while xorg may still be 
"supported", don't expect many new features, and at some point, drivers 
for new hardware and the like will probably dry up too, altho legacy 
hardware will of course continue to be supported and to work in existing 
form for rather longer.  (This is of course for the Linux side.  The BSDs 
will likely continue support for somewhat longer as well, altho just as 
with KMS vs UMS, they'll likely eventually be forced to adapt, as in 
general they simply don't have the developer power to continue xorg 
development at its current level.)

* In practice, much like the story we're seeing play out with systemd, 
while xorg will remain around for some time and existing features will 
probably continue to work in general as they always have, just as the 
various alternative init systems are, it's likely many of the newer 
features will only function as designed and/or will only be "supported" 
on wayland.  And, as we're seeing with gnome and systemd already, I 
predict they'll be dropping support for anything but wayland/weston 
sooner rather than later, basically leaving the non-linux platforms and 
those who aren't ready to make that change out in the cold, at least as 
far as gnome goes.  Just as we're seeing with systemd, distros such as 
gentoo who want to continue to support gnome with xorg will be able to do 
so for a couple releases, but at some point upstream gnome's code base 
will have diverged significantly enough that it'll force distros into 
only supporting wayland/weston for their gnome users, as well.

* However, just as kde has announced that they plan to continue support 
for the BSDs and for Linux without systemd, and at least currently, 
that's what they're doing, kde will continue to support xorg, too.

* Again as with systemd, other gtk-based desktops will continue to 
function for awhile with xorg, but just as the BSDs aren't able to 
support the xorg code base on their own, the other desktops won't be able 
to support continued gtk development, at least not to the same level and 
at the same speed, on their own, and they'll ultimately have to either go 
wayland-only as well, or jump off of gtk, to qt or the like, again, as is 
already happening due to gnome/gtk's growing systemd dependence.

* I don't know enough about enlightenment to be able to intelligently 
comment/predict for it. 

* Again, the few x-protocol-only apps and basic wms such as the *box 
family and icewm, should continue to "just work" within the X domain, 
regardless of whether they're running on xorg-server on the kernel and 
hardware directly, or whether they're running on xorg-server as xwayland 
on wayland, since AFAIK, they're pretty basic x-protocol in their 
requirements.

So in the general case, basically what you should see is that with the 
exception of gnome and to a lessor extent the other gtk-based desktops 
and apps, existing xorg functionality should continue to be maintained, 
at least for existing hardware, for quite some time.  But expect new 
features and new hardware support to eventually dry up and blow away, as 
the new-feature/new-hardware focus will now be on wayland.  Still, even 
if it's via xwayland and mesa, existing xorg/opengl/egl-based apps should 
continue to function, as xwayland and mesa will continue to provide 
backward compatibility support for x-protocol/opengl/egl.


For the gentoo-specific case, given the above and the systemd precedent, 
I think what's likely to happen there should already be pretty clear.  
Gentoo isn't dropping openrc support any time soon (the horizon remains 
unchanged, in practice about two years out minimum, even if they were to 
decide to drop it today, and there's absolutely NO hint of that) and it's 
extremely unlikely they'll drop xorg support either, at least not with a 
warning lead time of multiple years, for very much the same reasons 
including the fact that unlike systemd and (I think) wayland, gentoo (and 
debian) run on more than just Linux, so alternatives much remain 
supported as long as those non-linux platforms remain supported.

Again, the parallels to the systemd situation are very high.  Those 
running gnome are likely to find themselves with another tough choice, 
gnome and systemd/wayland or give up gnome in ordered to keep openrc/
xorg.  Gnome upstream always /has/ been the "there's only one true way, 
ours, and if you don't see it, well, you're just lost", type, and that's 
unlikely to change.

gentoo/kde will very likely follow their upstream and continue providing 
support as well, helped by the fact that the qt toolkit they're built on 
continues to provide very wide support, including for the BSDs as well as 
(GNU/)Linux, and for MSWindows and various mobile OSs such as Android 
(definitely non-gnu/Linux).  In fact, that's one of the reasons we're 
already seeing some of the other formerly gtk-based desktops switch to qt-
based, as with both systemd and wayland and with gnome dominating gtk 
development, they see the writing on the wall.

And as with the general case, the pure x-protocol and opengl/egl based 
apps and toolkits should continue to "just work" on either "legacy" xorg, 
or via xwayland, as gentoo really has no reason to throw roadblocks in 
the way, where there shouldn't be any upstream.  At worst, just as 
gentoo's doing today only adding one more reason to the pile, gentoo 
(along with other distros in similar circumstances) will maintain 
"trivial" patches as necessary to keep them working on gentoo.  It's when 
the patches get more than trivial that things become a problem, but 
that's generally due either to deliberately uncooperative upstreams, or 
to upstreams simply disappearing and their packages eventually dying "of 
natural causes" due to pure bitrot.

> Another concern centers around all of the udev/dbus stuff which I have
> so far successfully managed to completely avoid.  A second question then
> is how much will Wayland be dependent on udev?  Will it be an option or
> mandatory?

*THAT* is a very good question -- unlike the above, one I don't have an 
answer for.

To the extent that my experience and knowledge /does/ provide an answer, 
it's this observation:  Udev functionality tends to remain in general 
optional as for the most part it's simply "plug-n-play" type 
functionality like detecting new hardware and autoloading modules and 
automounting storage drives when they appear.  As long as you continue to 
be comfortable doing things the "manual" way, which you'd seem to be, 
udev continues to be optional, and my best guess is that it will 
/continue/ to be so with wayland, of course with the obvious trade-off, 
that you'll likely have to do the wayland equivalent of providing an 
xorg.conf, since my best guess is that wayland will very likely depend on 
udev to autoconfigure.

Dbus, OTOH, is I'd say an entirely different story.  There are already X-
based (and possibly some non-X-based as well) apps that communicate only 
via dbus.  Presently, these are reasonably easily avoided, since the only 
apps able to make a sufficiently solid assumption about dbus being 
available are the automation/autoconfig type apps, and you're already 
avoiding those to avoid udev.  However, with wayland there will be a MUCH 
STRONGER assumption that dbus will be available, since part of the whole 
purpose of wayland is to be able to drop legacy compatibility from wayland 
and its new protocol and only implement that via xwayland and the like, 
so unlike with the x-protocol, the compatibility layer can be dropped as 
soon as there's no further clients requiring it.

Thus, while it's ONLY a guess, it's a best-guess, wayland itself may well 
require or at least assume dbus, and it's very-to-extremely-likely that 
wayland clients will assume dbus to the level of hard-requirement as well.

But there's two bright sides to that:

1) As above, existing x-protocol and opengl/egl clients should continue 
to work with few if any changes as they run on top of xwayland which will 
be providing the compatibility layer they require.  So if you're getting 
along without it now as you say you are, you shouldn't have to worry 
about existing x-based apps, and will only need it for new apps and/or 
apps ported to wayland, presumably with new features added in the 
process.  If you're content with existing functionality, therefore, you 
should be fine until existing apps die of old-age and bit-rot.

2) There's a project already well underway that will make dbus a kernel 
provided service, since the kernel is in the best position to enforce the 
necessary security as well as to be able to make the necessary bandwidth 
guarantees, both of which have been proven to be major challenges with 
the existing userland based implementation.

Thus, it's very likely that at some point you'll enable (or disable) the 
dbus kernel feature much as you enable (disable) any other kernel feature 
today, and the currently required userland baggage that provides the 
feature currently will no longer be required. 

Of course a kernel-feature-dbus means that unlike today, dbus should be 
available from very early userspace stage, without forcing an initr* or 
other similarly cumbersome workaround.

Whether that addresses your personal concerns about dbus I don't know, 
but it should certainly go quite some distance to address the security, 
bandwidth and simply hassle issues associated with dbus today, so it's 
very possible that it will.

Of course, while given the people involved I'd put the chances of kernel-
dbus happening at well above 50%, I'm *NOT* sure of the status of 
existing patches, if any, which means AFAIK while the plans are already 
quite concrete and I believe there's /some/ code already, AFAIK it's 
still close enough to vaporware status that it's not yet a given, and 
things could well still change.  But kernelspace-dbus (or at least 
something looking and functioning similar enough that existing userspace 
shouldn't have to be /entirely/ rewritten to use it) is definitely the 
plan, anyway, I do know that much.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman