On Tue, 14 Jan 2014 02:40:36 +0100 "Fernando C.V." <ferk...@gmail.com> wrote:
Hi Fernando, > I believe most of the implementation details are up to the compositor, > Wayland is just a protocol. > At least in archlinux, the wayland package has only 2 dependencies: > libffi and expat Yes, that's true. However, you need to stress here that Wayland is just the protocol implementation for communication between clients and server and glue-code between clients and EGL-calls. It doesn't pull in the big libs itself, but _implicates_ a compositor (server) using EGL to communicate with Mesa 3D. On the client side, same applies. You can't do Wayland without EGL. Now, where's the problem? -1) Compositor's demands: Not everyone has a full drm-kms-setup. Hell, I don't even use evdev on my devices (It's more secure when you strip out the Event Interface from the Kernel). The biggest factor here probably is Mesa 3D. You just don't want this overhead if you don't intend to spend most of your time playing around with 3D-effects and burning windows. Given the direction the mainstream-Linux-desktop is going, Wayland is the appropriate answer. However, having looked into the topic a bit deeper, I basically found the Wayland-Compositor-Client model to be very similar to what you get implementing a GUI into a video-game[1] combined with several util-functions to set _basic_ things up. Yeah, I know Wayland doesn't require OpenGL(ES), but guess what most compositors build upon. -2) Code-rot: The Wayland protocol itself may be very lean, but that's not where the big overhead comes from. It rather is the fact you need to rewrite trivial features like evdev for each new compositor you chose to develop. I know, there are libs, but who guarantees they're still around in a few years _and_ compatible with the still rather "dynamic" Wayland-API? Why not just write a Weston-plugin then? Because Weston sucks (PAM, overengineered, too many features for dwm, ...)! In the end, you just give up and implement it yourself, forcing you to maintain thousands of LOC, risking bugs and wasting your time. -3) Window decorations: It was noted before, but window decorations are not trivial with Wayland. There's no problem with forcing the clients to shut up and just take the borders the compositor tells them to take (afaik). However, Weston is a liberal scumbag allowing the clients to to whatever they want. Kwin is a good example for the opposite. There's no clear way to change this setting if you're just a Weston plugin. Thus, there's just another reason not to go for it, as writing a compositor yourself proves to be a magnificient chore. -4) Sucklessness What should we do then? My advice would be to take a look at tinyx[2] and tinyxlib[3], which is relatively small and fitting the purpose well (dwm runs on it). Let's see what the future will bring us, but it now is all about making a decision. Cheers FRIGN [1]: <http://www.youtube.com/watch?v=_FjuPn7MXMs> [2]: <https://github.com/idunham/tinyxlib> [3]: <https://github.com/idunham/tinyxserver> -- FRIGN <d...@frign.de>
