Re: Waylands et Mir ?

C'est vrai que c'est pas évident (je ne suis pas du tout un spécialiste des histoires de piles graphiques)... De ce que je comprends néanmoins, c'est via openGL que les compositeurs communiquent avec le matériel:

Wayland Rendering

One of the details I left out in the above overview is how clients actually render under wayland. By removing the X server from the picture we also removed the mechanism by which X clients typically render. But there's another mechanism that we're already using with DRI2 under X: direct rendering. With direct rendering, the client and the server share a video memory buffer. The client links to a rendering library such as OpenGL that knows how to program the hardware and renders directly into the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and when and where it has rendered new content into it.

Ça colle avec ce que j'avais par ailleurs lu quand je m'étais penché sur l'avenir des WMs. Donc tu aurais à moitié raison, c'est bien au compositeur de communiquer avec le matos, mais via un standard qui est openGL, et qui est visiblement impliqué dans la communication avec Wayland, si j'en crois les deux dernières entrées de la FAQ:

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.