Un articulo muy interesante que explica el estado actual de XOrg y por que
razon se esta desarrollando Wayland
http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1
Es un poco largo y consta de cuatro partes, pero no es denso y es bastante
facil de entender.
Creo que esto es mejor para entender
Wayland FAQ
a.. Why fork the X server?
b.. What is the license?
c.. Why duplicate all this work?
d.. What is the drawing API?
e.. Is wayland replacing the X server?
f.. Why not extend the X server?
g.. What is wrong with X?
h.. What about the overhead of running X on wayland?
i.. Is Wayland network transparent / does it support remote rendering?
j.. How to download and build Wayland?
k.. Why wasn't D-Bus used instead of the Wayland IPC mechanism?
l.. How can I replace Wayland's Window Manager?
m.. Why does Wayland use EGL and GLES2?
Why fork the X server?
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.
What is the license?
Wayland is licensed under the MIT license with some example code under the
GPL.
Why duplicate all this work?
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.
What is the drawing API?
"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, 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. As long
as you have a userspace driver library that will let you render into a
sharable buffer, you're good to go.
Is wayland replacing the X server?
It could replace X as the native Linux graphics server, but I'm sure X will
always be there on the side. I imagine that Wayland and X will coexist in
two ways on a Linux desktop: Wayland is a graphics multiplexer for a number
of X servers. Linux today typically only uses one X server for GDM and the
user session, but we'll probably see that move to a dedicated GDM X server,
an X server for user sessions (spawning more on the fly as more users log
in) and maybe a dedicated screensaver/unlock X server. Right now we rely on
VT switching to move between X servers, and it's horrible. We have no
control over what the transitions look like and the VT ioctls are pretty
bad. Wayland provides a solution here, in that it can host several X servers
as they push their root window to Wayland as surfaces. The compositor in
this case will be a dedicated session switcher that will cross-fade between
X servers or spin them on a cube.
Further down the road we run a user session natively under Wayland with
clients written for Wayland. There will still (always) be X applications to
run, but we now run these under a root-less X server that is itself a client
of the Wayland server. This will inject the X windows into the Wayland
session as native looking clients. The session Wayland server can run as a
nested Wayland server under the system Wayland server described above, maybe
even side by side with X sessions. There's a number of intermediate steps,
such as running the GNOME screen saver as a native wayland client, for
example, or running a composited X desktop, where the compositor is a
Wayland client, pushing the composited desktop to Wayland.
Why not extend the X server?
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. I'm not deluding myself that any general purpose
desktop Linux distribution will stop shipping X as we know it or as a
Wayland client anytime soon. Nor should they, there will still be X
applications to run and people expect that from a Linux desktop. 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.
What is wrong with X?
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. Getting
to a point where the X server is a compatibility option instead of the core
rendering system will take a while, but we'll never get there if don't plan
for it.
What about the overhead of running X on wayland?
If you're running a fullscreen X server, which pushes its root window buffer
to Wayland there is little overhead. If the X server root window is
transformed (i.e. scaled down or spinning on the side of a cube) the Wayland
compositor will have to do an extra copy to get the pixels on screen. But
once the animation finishes and the X server buffer fills the entire screen,
the Wayland compositor can change the video scanout to source from the X
server buffer and retreat into the background. The X server uses the
standard X.org DDX drivers, renders directly to its pixmaps and its root
window, and the path from X to hardware is exactly as a native X.org server.
Is Wayland network transparent / does it support remote rendering?
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.
How to download and build Wayland?
See the build instructions.
Why wasn't D-Bus used instead of the Wayland IPC mechanism?
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.
How can I replace Wayland's Window Manager?
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.
This may sound like a lot of work, but one of the key points about Wayland
is that the boilerplate code to a Wayland compositor is comparable or less
than the X boilerplate involved in becoming an X window manager and
compositor. Bringing up EGL and GLES2 on the Linux KMS framebuffer and
reading input from evdev can be done in less than a thousand lines of code.
The Wayland server side library provides the protocol implementation and
makes it easy to put the pieces together.
Why does Wayland use EGL and GLES2?
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 we're using
GLES2 for now. Longer term, we'll need a way to use full GL under Wayland.
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que est� limpio.
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l