On Tue, 14 Jan 2014 02:40:36 +0100
"Fernando C.V." <ferkiwi_AT_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 <dev_AT_frign.de>
Received on Tue Jan 14 2014 - 11:42:14 CET