Slashdot Mirror
Wayland Isn't Ready For the Fedora 24 Desktop (phoronix.com)
An anonymous reader writes: There was much hope that Fedora 24 would be the first major Linux distribution using Wayland by default in place of an X.Org Server, that didn't pan out with Fedora 24 Workstation developers deciding not to use Wayland by default but it will remain a log-in time option. Fedora Wayland has made a lot of progress but functionality like on-screen keyboard, accessibility, remote displays, USB display hot-plugging, and other functionality is incomplete for the Fedora 24 timeline. At least there are many other Fedora 24 features that made it for this next release due out in June. Wayland will turn eight years old this year.
For Fedora, which underpins RHEL and other Enterprisey OSes, that's a major absence, even if Wayland's own developers don't consider it important.
I really hope Wayland's developers stop treating it as a minority application unworthy of serious consideration (even though it's supposedly on their long term roadmap) and actively start work on it. They have a proof of concept. They have X to show them how security can work in practice. It's time the work was done.
You are not alone. This is not normal. None of this is normal.
From what I've understood, VNC yes since it's essentially diff'd screen dumps with "damage areas" that are redrawn. In fact there's been some attempts at making a RDP-style remote capability that is slightly smarter because it knows the composition but not the contents of the window, like if you move a window the protocol knows it can just move rather than resend the contents. What you won't get is native X acceleration, meaning you can't actually send draw commands. Think like HTML, draw this box here with that text in this color.
That is also why Wayland at least in the reference implementation doesn't have server side decorations, it doesn't want to understand fonts, antialiasing, buttons, animation, themes and all that. It is only a pixel-pusher, it composites images other software has made. By itself it won't draw a window border, a minimize/maximize/close button, nothing. It made the project much easier without dependency on any graphics toolkit, but I think it might have been a mistake to present it like this is the norm and clients should/might have to write their own decorations.
I don't think applications should be forced to write their own decorations, it should be the norm that they can request decorations from the window system and that they'll take what they can get. The reference implementation should have been a wayland plug-in and might have been state of the art of the 1980s, a few fixed bitmaps and just "we expect actual environments like KDE, Gnome, even XFCE to come up with something more advanced this is basically a minimal placeholder". If you want to draw your own decorations that's something else.
Live today, because you never know what tomorrow brings
That's because most people who believe Wayland is the second coming are completely unqualified to even hold an opinion. However, those who object to Wayland and it's justification tend to do so based on technical knowledge and expertise.
Wayland is doomed to epic failure until they make serious changes. One of the biggest is remote windowing. They've finally acknowledged that this is in fact a serious issue and glaring deficiency with Wayland. They might actually garner broader support to make things better and reliable.
That is why we should have been putting effort into something 100% backwards compatible with X11... X12. All kinds of things COULD have been rolled in- compression, local cursor, broadcast, etc.