Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hope Wayland innards gets similar efforts to be explained and publicised with this same level of quality as this piece on venerable x11.


I'm trying: http://blog.mecheye.net/2014/06/xdg-shell/

Really, a big part of Wayland is that there isn't much there. It's not a ridiculously complicated system to explain with lots of extensions, you're just having clients pass image files around and get streams of messages for input. The easiest way to get a feel for the system is to use the built-in protocol dumper:

  $ WAYLAND_DEBUG=client weston-terminal
... or so... and that's it, that's the entire system.

If anybody has any more questions on Wayland internals, I'll certainly consider writing a series of articles on it.


Interesting, that's the most positive thing I've heard about Wayland so far (much simpler system).


What else have you heard about Wayland?


Guaranteed perfect frames. Compositor built in. Both awesome.

It's simple and slim, and therefore hopefully more performant.

And then there was some drama about client side windows decorations, that I didn't quite get.


The protocol doesn't specify decorations. It is up to the compositor. The reference one, Weston, was using client side (I think Mutter is doing that too) while Kwin is using server side.

It is a personal choice. And Wayland the windowing system doesn't care what you do - its decoration agnostic.


That's not necessarily true. If your toolkit and compositor don't agree on whether you're using client-side or server-side decorations, then you're going to see either double decorations or no decorations.

Most of the core Wayland team believes that client-side decorations is the technically superior approach for efficiency and accuracy reasons, and we're disappointed KDE is still pushing for server-side decorations.

There is currently no protocol to negotiate between the toolkit and compositor whether to use client-side or server-side decorations. And I can't see one being added in the near future, either.


It's not a ridiculously complicated system to explain

So I don't know much about the wayland architecture outside of the docs and Daniel Stone's linux.conf.au talk on it. It seemed like a clean and smart replacement to what X has become, after using it for a while have you run into any serious limitations or is everything still going along smoothly?

I've poked my head in a few times, but is there anywhere good to keep up on progress other than the mailing lists?


There's no serious limitations that I've ran into. I have a variety of very minor gripes with certain parts of the protocol, and there certainly are parts of it that are a bit underdeveloped, but we're moving forward on a lot of these.


Nice piece. And a quicky, can a compositor be a client of another?


Sure. Weston has a nested backend for this use case, and I'm told that KWin is going to do the same thing, because they don't want to fiddle with DRM/KMS directly.

http://cgit.freedesktop.org/wayland/weston/tree/src/composit...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: