Update On Wayland and X11 Support 315
Phoronix was at the Linux Foundation Collaboration
Summit and has two articles on the status of Wayland and X11
integration. The second talk was about the current
status of Wayland, and its impending release (version 1.0 is due
this summer). The developers also have an experimental GNOME-Shell
working on Wayland. There's a (kind of shaky) video of this
talk (attached, and at youtube for those wanting the html5
version). The first talk (by Keith Packard) covered X11
support on Wayland. It's basically ready to go, but window
management is implemented only as a hack right now. The next year
could be quite exciting for GNU/Linux and BSD users as distributions
begin including Wayland as an alternative to X.org.
Re:Why? (Score:5, Informative)
IIRC X11 has a lot of redundancy with stuff that's already in the Linux kernel. Weyland is a compositing window manager that removes those redundancies for better performance and code maintainability. Weyland loads X11 legacy support only as needed on an app by app basis. Benefits include Compiz working much better by bypassing X.
Comment removed (Score:5, Informative)
Re:Wayland vs X (Score:4, Informative)
Is this a joke? Here are some of the missing steps in the VNC "solution":
Re:Why? (Score:4, Informative)
You are correct - anything else IS eye candy. And many of us ARE happy with TWM and X Terminals - because those are the tools we need to do our jobs.
Re:Why? (Score:5, Informative)
As I understand it, X11 is horribly out of date.
It should be clear to anyone that there are some stone-age omissions in X:
- Basic transparency is either an ugly hack that glitches all the time (xcompmgr) or else a fairly extravagant system like compiz.
- Smooth fonts is an extra.
- Multiple displays is an extra.
- There are serious security flaws in areas such as screen locking. See this great series of points [jwz.org] by the author of xscreensaver.
Then, there's all this support for legacy technologies that don't affect 90% of Linux/BSD systems, let alone the potential general market.
All in all, X11 has fundamental weaknesses, doesn't reflect modern usage and is really too big to fix. Legacy support and compatibility are so important that problems can't be fixed.
I haven't been following Wayland too closely, but my understanding is that it will address these issues as fundamentals of the system. I hope it does address each of these issues, because they are important. Performance could certainly improve on X. Let's hope it does with Wayland.
I'm not that familiar with how display servers work either, so correct me if I'm wrong about anything. No need to rage, I'm not trollling anyone.
My prediction is that it will become fashionable to whine about Wayland, lots of people will resist it for a while, but in the end it will be the most suitable alternative and only the truly stubborn and those who need X for some reason will avoid it. See the history of PulseAudio for reference.
Sorry about the identical AC post below. I forgot to sign in.
Re:Why? (Score:4, Informative)
Especially any sort of OpenGL, which doesn't work over the network.
Wrong! OpenGL works over the network, in fact it was designed to.
Re:We're NOT talking (Score:4, Informative)
Re:Why? (Score:3, Informative)
I believe in things being as lean as possible and having to prove or justify any excess
This is pretty much the reason *for* Wayland -- whether you use Xorg or Wayland you have support for all the excess eyecandy (not that you have to use it), but Xorg is an exponentially growing pile of add-ons while Wayland has the features planned from day one, plus it's even smaller than that, because it lets the kernel do the heavy lifting of driver support.
Re:Why? (Score:5, Informative)
Because I used it for five years to run VariCAD on a server with no local video acceleration, displaying on client with Nvidia card, both running Debian.
Re:Why? (Score:5, Informative)
No, wayland uses a socket to communicate between the client and the compositor. It is not function calls. Many calls to the client library can be (and are) consolidated into a single block message sent to the compositor. Wayland was designed for this, by avoiding return values from the calls, so they can be asynchronous (this is where Windows fails badly, and Xlib (though not X itself) also did in many cases, because they failed to realize that some calls they thought would be rarely used and thus ok to stick a return value on are used extensively).
Re:I don't understand (Score:5, Informative)
In Wayland the client draws the window borders (and before you blurt out "but they will be different from each other and 'confuse the user'" be aware that nothing on X makes anything other than the window borders draw identically, but somehow there are all these applications where they draw their own scrollbars and buttons and text editors and they all look alike and fail to "confuse the user".)
X ICCCM window management was invented before there were shared libraries, so now there is a huge messy complex api built on top of the limited atom+value and signalling that existed in X11. Having written a toolkit (fltk) I can confirm that talking to the window manager literally takes 10 to 20 times as much code as if I drew the window borders myself. And we still have horrific problems where various window managers disagree on whether a window should vanish when the app loses focus and how "stay on top" should work, and we can't put the most trivial buttons or items in the window pulldown menu, something Windows allows and is making it increasingly difficult to port applications from Windows.
Wayland wisely has decided to scrap this mess by having the clients draw the borders.
Emulating X is trivial if you just work with the windows the X client knows about and repliate them on Wayland. The problem is that all that ICCCM stuff will need to be interpreted by something and draw window borders as well. It is not clear if this should be done by a local "act like xlib" library, or by a fake X server, or by an actual X11 window manager running on the fake X server. That's why window management is currently a "hack" because this has not been decided.
It was working in 2000, why not 2012? (Score:4, Informative)
My desktop machine at work now is getting a bit old so I'm actually posting this using firefox on a fairly fast cluster node via X. While that's not 3D some of the geophysics stuff my co-workers use involves a lot of 3D content, and I've played with Blender on some nodes during setup to see how they handle it. That's with Nvidia's accelerated driver in nearly every case.
By the way, what's the "modern CAD system"? I'm only familiar with the old stuff (I'm putting the most recent AutoCAD in that category since it hasn't really changed in years and is low end anyway) so you may have a point I'm not aware of.