It's not an X server and not a fork. It's a protocol between a compositor and its clients. The compositor sends input events to the clients. The clients render locally and then communicate video memory buffers and information about updates to those buffers back to the compositor.
Wayland is licensed under the MIT Expat license.
Wayland is not really duplicating much work. Where possible, Wayland reuses existing drivers and infrastructure. One of the reasons this project is feasible at all is that Wayland reuses the DRI drivers, the kernel side GEM scheduler and kernel mode setting. Wayland doesn't have to compete with other projects for drivers and driver developers, it lives within the X.org, mesa and drm community and benefits from all the hardware enablement and driver development happening there.
"Whatever you want it to be, honey". Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents. The current test clients use either Cairo software rendering, Cairo on OpenGL or hardware-accelerated OpenGL directly. Additionally, media frameworks can share their buffers directly with the server. As long as you have a userspace driver library that will let you render into a shareable buffer, you're good to go.
Mostly, yes. User sessions are able to run under Wayland today, via a number of compositors: Weston itself as well as Enlightenment, GNOME Shell, KDE, and a number of others under development. With most toolkits having Wayland ports, as well as frameworks such as GStreamer and SDL, it's perfectly possible to run a purely native Wayland session as your desktop.
That being said, there are some clients which rely on X11, and always will be. To that end, Xwayland provides a plugin for Wayland compositors, running a real X server. This gives legacy clients a real and compliant X11 platform to run on, displayed side by side with native Wayland clients in your Wayland session.
Because for the first time we have a realistic chance of not having to do that. It's entirely possible to incorporate the buffer exchange and update models that Wayland is built on into X. However, we have an option here of pushing X out of the hotpath between clients and the hardware and making it a compatibility option. What's different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango, etc) and there is very little left that has to happen in a central server process.
The problem with X is that... it's X. When you're an X server there's a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. For example, core fonts; this is the original font model that was how your got text on the screen for the many first years of X11. This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!). Also, the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extensions such as XRandR, XRender and COMPOSITE and to some extent phase out less useful extensions. But we can't ever get rid of the core rendering API and much other complexity that is rarely used in a modern desktop. With Wayland we can move the X server and all its legacy technology to an optional code path.
Most modern desktops already use an external compositing manager: when the X server decides it needs to update content, it informs this external process (usually your window manager), and allows it to control the rendering entirely. Using Xwayland is just the same as this, but more efficient because the compositing manager doesn't have to go back through the X server to display the content it rendered.
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
This doesn't mean that remote rendering won't be possible with Wayland, it just means that you will have to put a remote rendering server on top of Wayland. One such server could be the X.org server, but other options include an RDP server, a VNC server or somebody could even invent their own new remote rendering model. Which is a feature when you think about it; layering X.org on top of Wayland has very little overhead, but the other types of remote rendering servers no longer requires X.org, and experimenting with new protocols is easier.
It is also possible to put a remoting protocol into a wayland compositor, either a standalone remoting compositor or as a part of a full desktop compositor. This will let us forward native Wayland applications. The standalone compositor could let you log into a server and run an application back on your desktop. Building the forwarding into the desktop compositor could let you export or share a window on the fly with a remote wayland compositor, for example, a friend's desktop.
As of 2020, there are several projects that use these methods to
provide GUI access to remote computers. The compositor Weston
provides an RDP backend. GNOME has a
remote desktop server that supports VNC.
WayVNC is a VNC
server that works with compositors, like
Sway, based on the wlroots library.
Waypipe
works with all Wayland compositors and offers almost-transparent
application forwarding, like ssh -X.
I wanted to preserve some important properties from the X protocol: the ability to queue up an event or request by just memcpy'ing into the protocol out-buffer. That's what wl_connection_write does. Furthermore, it lets us memcpy several messages into the buffer and only write it all before we go back to blocking in the main loop. Second, everything is explicitly asynchronous, which is a really powerful feature in a protocol.
The Wayland architecture integrates the display server, window manager and compositor into one process. You can think of Wayland as a toolkit for creating clients and compositors. It is not a specific single compositor or window manager. If you want a different window manager, you can write a new one. A 'libweston' effort is underway in order to allow new environments to reuse Weston's codebase and mechanics, whilst providing their own look and feel.
EGL is the only GL binding API that lets us avoid dependencies on existing window systems, in particular X. GLX obviously pulls in X dependencies and only lets us set up GL on X drawables. The alternative is to write a Wayland specific GL binding API, say, WaylandGL.
A more subtle point is that libGL.so includes the GLX symbols, so linking to that library will pull in all the X dependencies. This means that we can't link to full GL without pulling in the client side of X, so Weston uses OpenGL ES to render. This also enables Weston to run on GPUs which don't support the full OpenGL API.
As detailed above, clients are however free to use whichever rendering API they like.