Re: swc library to implement dwm under Wayland (was Re: [dev] gtk3 support for surf?)

From: Hadrian Węgrzynowski <hadrian_AT_hawski.com>
Date: Tue, 14 Jan 2014 20:41:40 +0100

Dnia 2014-01-14, o godz. 11:42:14
FRIGN <dev_AT_frign.de> napisał(a):

> 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.

EGL as API is quite lean. There could be small implementation not
depending on Mesa 3D.

Is there another problem with 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.

I am just curious:
1. Can Wayland clients use just simple blitting without special kernel
infrastructures?
2. Can Wayland Compositor work without special kernel infrastructures?
3. Are Wayland clients using evdev or is it just for server?
4. Does anybody know how good is pixman library (AFAIK software renderer
used by Weston)?

> -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, ...)!

I like to think that, we could make up compositor from few buildng
blocks, but I don't know Wayland that much to know is this viable.

> In the end, you just give up and implement it yourself, forcing you to
> maintain thousands of LOC, risking bugs and wasting your time.

$ find swc -iname "*.[ch]" -exec cat '{}' \; | wc -l
8350
$ find tinyxserver -iname "*.[ch]" -exec cat '{}' \; | wc -l
235126

> -3) Window decorations:
> It was noted before, but window decorations are not trivial with
> Wayland.

It is true, but in case of dwm decorations are relativly trivial.

> -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).

That is cool nevertheless.

> Let's see what the future will bring us, but it now is all about
> making a decision.

Even if Suckless Wayland Compositor can be successfully implemented
suckless most probably will not abandon X11 for the foreseeable
future, which I think is good.

Truth is - we can talk, but only written code matters.

With regards,
Hadrian Węgrzynowski.
Received on Tue Jan 14 2014 - 20:41:40 CET