So as a user of modern Linux distributions, what can I expect in the near future from display server changes? Will my everyday experience be affected in any way, or do X/Wayland/Mir work so deep under the hood that applications talk to abstraction layers that can be ported between the 3?
Ideally X/Wayland/Mir work so far under the hood that you won't notice anything. That said there will be changes if you've been using things like screen capture programs (x11vnc, ffmpeg to record your desktop, etc.). There's also the probability that when things first shift to a distro using Wayland/Mir for the first time, things WILL break, so unless you want to be a beta tester I'd avoid it for the first few months (or more) until things get more stable.
After that period of introduction though, what you should be able to expect is better ram/cpu usage for the display server (wayland's architecture makes it much easier to offload everything to the GPU, X has some warts that makes that very hard). Based on what I've seen there should also be better support for tear-free video playback and eventually possibly even proper NVIDIA Optimus support (and AMD's version) which should help a lot of people with battery life.
In the near future, probably nothing. Wayland is (probably) still years from getting adopted even by "bleeding-edge" distributions like Arch.
Your everyday experience shouldn't get affected, hopefully. Wayland removes a lot of legacy from X, but their end result is pretty much the same, "display some stuff on my screen". And XWayland should assure this, since you'll be able to run applications that don't support X on Wayland in a seamless way. Most applications use some toolkit anyway (gtk, qt) that are getting ported to Wayland, so the author of that applications shouldn't do any changes to make it work on Wayland (beside recompiling it).
At best, Wayland should be lighter than X, and it should fix tearing if you have some now (but this is already fixed by modern wm, at least on my computer).
Same for Mir (but I dunno about the security issues that Wayland fixes), but upstream doesn't seems willing to accept Mir-specific patches, so Canonical might end with having to patch applications/toolkit/drivers downstream (but the user shouldn't notice any difference anyway).
Why "years"? KDE and Gnome are close to enabling Wayland support during this year. The only unknown is when proprietary drivers will do it. Apparently Nvidia is working on it. So they might finish this year as well. Things look good so far.
Can you point to any commits on the Firefox tree or is your evidence limited to blog posts and mailing-list messages?
There are commits [1] on the Chrome tree designed to get Chrome working on Wayland, but for those commits to reach significant numbers of users will require the cooperation or at least the "non-interference" of the employer of most of the Chrome devs -- which is at this time an unknown.
I want Wayland to ship as soon as possible, I'm looking at the situation in the most "negative" way so that if it ship sooner than I believe, I'll be happy, and if it doesn't, I'll not be sad. (Wayland has been close to shipping for a lot of time now, remember when Shuttleworth wanted to ship it in 12.04 as a developer preview? The good old times when Canonical didn't suffer from NIH).
Gnome should ship with Wayland considered as stable with 3.14, and (as far as I know), there's no plain to ship KDE on Wayland before KDE5. XWayland still need works, and without it no distro will ship Wayland. The proprietary drivers still need to come out (Nvidia might be at work on them already, but for all we know it might still be just some drawing on a blackboard - and let's not forget about AMD, that will probably take quite a bit of time).
Also "normal" distro (Mint, openSUSE, Fedora...) will probably take their time as well to ensure that everything is working. I'd expect to see some kind of experimental preview, then a version with support to both (but with the default still being X) and then a version with Wayland (and an X failback).
Probably I'm just being negative here, and if everything happens faster than how I think it will, then great! Also, probably just a generic "years" feels too much, my expected timeframe is/was 2-3 years.
KDE5 is coming out in June, but initial release will not support Wayland in KWin. But it should come after as an update. I'm not sure about exact schedules though.
The basic idea is that most applications using popular toolkits (GTK and Qt) should work with very little modification - in a lot of cases it should just be a matter of an environment variable being set to tell the toolkit to use Wayland support code instead of X. The application itself shouldn't even need to be recompiled.
That covers most cases, but there are others. Some toolkits won't be ported immediately. Some applications use functionality that's tied to X even if they use a toolkit that supports Wayland. The compatibility solution is XWayland. This is a simple X server that can be launched on demand, allocates a Wayland buffer per X window and then renders into that buffer (this is similar to how XQuartz works on OS X, except with more on-demand activation).
So, other than bugs, things should be pretty transparent. There'll probably be some slight awkwardness in cross-X/Wayland interactions (clipboard semantics may not be identical, drag and drop behaviour may vary, that kind of thing) but nothing that most people will notice.
Mir ought to be in the same state, but right now XMir doesn't support the same kind of rootless behaviour as XWayland - instead, X applications all run inside one separate window. I'd expect that to be fixed before Mir is used as the default environment anywhere. Mir is also lagging behind Wayland in terms of getting upstream toolkit support - again I'd expect this to be something that's sorted out in future.
I hope drivers will catch up on EGL/Wayland support. Especially Nvidia one. Can't wait to start using Wayland based desktop (KDE should get in shape during this year).
Could someone in the know-how explain if this will help those who use X-dependent window managers. Will one be able to run wayland in the future, but yet use (say) fvwm? I've used fvwm for over 10 years and there is really nothing out there that gives its flexibility, so i'm wondering if once wayland is mainstream, the old window managers will become useless.
what kind of applications can we see with XWayland replacing X? Will headless applications be more common? What sort of things will be created with it?
23 comments
[ 2.2 ms ] story [ 62.1 ms ] threadWhat's the news (without sounding snarky), Confirming that nVidia's is being ignored in this decision?
It seems to explain many questions that where posted here the last time this was submitted.
After that period of introduction though, what you should be able to expect is better ram/cpu usage for the display server (wayland's architecture makes it much easier to offload everything to the GPU, X has some warts that makes that very hard). Based on what I've seen there should also be better support for tear-free video playback and eventually possibly even proper NVIDIA Optimus support (and AMD's version) which should help a lot of people with battery life.
Your everyday experience shouldn't get affected, hopefully. Wayland removes a lot of legacy from X, but their end result is pretty much the same, "display some stuff on my screen". And XWayland should assure this, since you'll be able to run applications that don't support X on Wayland in a seamless way. Most applications use some toolkit anyway (gtk, qt) that are getting ported to Wayland, so the author of that applications shouldn't do any changes to make it work on Wayland (beside recompiling it).
At best, Wayland should be lighter than X, and it should fix tearing if you have some now (but this is already fixed by modern wm, at least on my computer).
One of the biggest change that you shouldn't notice is security, X has tons of holes (every application can read/write into another application), which wayland fix (see here for more: http://mupuf.org/blog/2014/02/19/wayland-compositors-why-and...).
Same for Mir (but I dunno about the security issues that Wayland fixes), but upstream doesn't seems willing to accept Mir-specific patches, so Canonical might end with having to patch applications/toolkit/drivers downstream (but the user shouldn't notice any difference anyway).
There are commits [1] on the Chrome tree designed to get Chrome working on Wayland, but for those commits to reach significant numbers of users will require the cooperation or at least the "non-interference" of the employer of most of the Chrome devs -- which is at this time an unknown.
[1] https://github.com/01org/ozone-wayland/commits/master
Firefox Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627699
You can install a build on Fedora via this copr (like a PPA for Fedora): http://copr.fedoraproject.org/coprs/stransky/FirefoxGtk3/
Gnome should ship with Wayland considered as stable with 3.14, and (as far as I know), there's no plain to ship KDE on Wayland before KDE5. XWayland still need works, and without it no distro will ship Wayland. The proprietary drivers still need to come out (Nvidia might be at work on them already, but for all we know it might still be just some drawing on a blackboard - and let's not forget about AMD, that will probably take quite a bit of time).
Also "normal" distro (Mint, openSUSE, Fedora...) will probably take their time as well to ensure that everything is working. I'd expect to see some kind of experimental preview, then a version with support to both (but with the default still being X) and then a version with Wayland (and an X failback).
Probably I'm just being negative here, and if everything happens faster than how I think it will, then great! Also, probably just a generic "years" feels too much, my expected timeframe is/was 2-3 years.
See:
* http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Sche...
* http://blog.martin-graesslin.com/blog/2014/03/kde5-and-wayla...
AFAIK Fedora is planning to ship Wayland in version 21, scheduled for release later this year. Probably not as default, but still.
That covers most cases, but there are others. Some toolkits won't be ported immediately. Some applications use functionality that's tied to X even if they use a toolkit that supports Wayland. The compatibility solution is XWayland. This is a simple X server that can be launched on demand, allocates a Wayland buffer per X window and then renders into that buffer (this is similar to how XQuartz works on OS X, except with more on-demand activation).
So, other than bugs, things should be pretty transparent. There'll probably be some slight awkwardness in cross-X/Wayland interactions (clipboard semantics may not be identical, drag and drop behaviour may vary, that kind of thing) but nothing that most people will notice.
Mir ought to be in the same state, but right now XMir doesn't support the same kind of rootless behaviour as XWayland - instead, X applications all run inside one separate window. I'd expect that to be fixed before Mir is used as the default environment anywhere. Mir is also lagging behind Wayland in terms of getting upstream toolkit support - again I'd expect this to be something that's sorted out in future.