Libweston Likely To Be Delayed To Wayland's Weston 1.9

[phoronix]

Phoronix: Libweston Likely To Be Delayed To Wayland's Weston 1.9

While Wayland 1.8 is coming along, along with the Weston 1.8 update, it looks like the libweston functionality will be staved off for another release...

http://www.phoronix.com/scan.php?page=news_item&px=Wayland-Libweston-1.9

[blackout23]

Glad that libweston still has a chance to be merged. That should make it easier for projects like MATE to implement a Wayland compositor now that they already have a version that is built on GTK3.

[rastersoft]

But then... what is the difference between libwayland and libweston?

[uid313]

Any interesting Wayland or Weston developments lately?
Anything cool new in upcoming 1.8 and 1.9?

[BlackStar]

But then... what is the difference between libwayland and libweston?

AFAIK:
libwayland = libX11
libweston = libcompiz

[blackout23]

But then... what is the difference between libwayland and libweston?

libwayland is a client API that is used by toolkits or for wayland demo applications that talk to the wayland compositor directly like the weston-terminal, weston-simple-egl etc. apps.
libweston is to build compositors.

[atldpk]

AFAIK:
libwayland = libX11
libweston = libcompiz

libwayland is a client API that is used by toolkits or for wayland demo applications that talk to the wayland compositor directly like the weston-terminal, weston-simple-egl etc. apps.
libweston is to build compositors.

This is incorrect. Libwayland is both a client-side and a server-side library.

You can think of libwayland as a big exercise message-passing. It is a library for efficiently passing messages between different processes. Oh, and it can create shared memory buffers.

That's it, mostly.

Weston uses uses libwayland enriched with some protocols (ie more definitions of messages you can send and what they mean) to implement a compositor: clients can send a message asking the compositor for a drawing buffer (e.g. a piece of general-purpose RAM, or more efficiently a piece of RAM on the GPU), and they can tell the compositor when they drew something new. The compositor interfaces with your graphics card and makes sure windows indeed appear on your screen.

However, there are many ways to make stuff appear on your screen - that is, how it obtains these drawing buffers: you can use drm, drm with kms, opengl, it can itself act as a wayland client (ie get its drawing buffers from another compositor), X11 client (same thing) (this is what happens if you launch "weston" as non-standalone), in plain RAM for use with remote desktop protocols...

And it would be a bit ridiculous if every compositor would have to re-implement these various ways to obtain drawing buffers. So this is the functionality that libweston exposes. So this saves some code duplication between compositors: they all obtain their buffers via weston code.