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
