XWayland in XOrg

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).

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).

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.

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.

It's committed rather than having merely been posted for review.