4 ms·

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

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?

simcop2387 12y ago
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.
Spittie 12y ago
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-how-to-handle/ 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).
- shmerl 12y ago
  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.
  - hollerith 12y ago
    Most users of Linux on the "desktop" are more dependent on a web browser than on KDE or Gnome, so the drivers are not the only unknown.
    - shmerl 12y ago
      GTK and Qt are shaping up well too. Firefox is working on switching to GTK 3. And XWayland can help for those who lag behind.
      - hollerith 12y ago
        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. [1] https://github.com/01org/ozone-wayland/commits/master https://github.com/01org/ozone-wayland/commits/master
        abrowne 12y ago
        Regarding Firefox Gtk3: Firefox Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627699 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/ http://copr.fedoraproject.org/coprs/stransky/FirefoxGtk3/
mjg59 12y ago
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.

simcop2387 12y ago

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.

Spittie 12y ago

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-how-to-handle/ 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).

shmerl 12y ago
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.
- hollerith 12y ago
  Most users of Linux on the "desktop" are more dependent on a web browser than on KDE or Gnome, so the drivers are not the only unknown.
  - shmerl 12y ago
    GTK and Qt are shaping up well too. Firefox is working on switching to GTK 3. And XWayland can help for those who lag behind.
    - hollerith 12y ago
      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. [1] https://github.com/01org/ozone-wayland/commits/master https://github.com/01org/ozone-wayland/commits/master
      - abrowne 12y ago
        Regarding Firefox Gtk3: Firefox Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627699 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/ http://copr.fedoraproject.org/coprs/stransky/FirefoxGtk3/

mjg59 12y ago

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.