Hi FRIGN,
I tried to respond to most of your points as best I could.
On Tue, 14 Jan 2014 11:42:14 +0100, FRIGN <dev_AT_frign.de> wrote:
> > 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.
Sure, many compositors will use EGL, but that doesn't make it a
requirement. In swc I am using wld to perform both server-side
compositing as well as client-side drawing (as in st). wld includes
hardware accelerated rendering for Intel, and uses the same protocol
extension as Mesa does to pass buffers to the server. This has several
benefits:
- If none of your applications use Mesa or EGL, it is not required.
- If your system uses a GPU that wld does not support, but you have
applications which use EGL/OpenGL, those applications will have
accelerated rendering like normal, and only the final copy to the
scanout buffer will be done in software (which, from my testing,
is quite fast).
- Applications built using wld will remain compatible with other
Wayland compositors which do use EGL.
Additionally, software rendering using pixman will work for nearly all
systems, and is fast enough from my experience.
> 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).
Both of these are just implementation details of the compositor. They
suit my needs fine, so I won't be looking into supporting fbdev or
non-evdev devices. Though I should note, it probably wouldn't be too
difficult at all to support these, but it adds unnecessary bloat at this
point.
> 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.
I agree that Mesa should not be a hard requirement for a functioning
window system. However, it makes sense to utilize it if it is available
on the system.
> 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.
That 3D-maze compositor is a proof-of-concept and should be regarded as
such. If anything, it just illustrates the flexibility granted to the
compositor.
> -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 don't think this is a valid argument. You could say the same thing for
X11: you need to implement these things for every X server you implement
as well.
> 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.
I believe that the Wayland API will settle down after a while (in fact,
it has been easy to keep up with and recently it hasn't changed much at
all).
> -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.
In swc, I just draw borders for all windows. The window manager can
specify a border width and color for each window, just like in X. My st
and dmenu ports do nothing in terms of borders/window decorations (same
as they currently work in X).
Now, as far as other applications go, Gtk+ currently draws these massive
decorations around everything when running under Wayland. Given that the
Qt/KDE guys want to use server-side decorations, I'm sure that there
will be some setting you can disable to get rid of the borders (maybe
there already is, I haven't looked into it).
I'm in agreement that Weston is not the way to go. I think it would be
quite difficult to add server-side borders to the existing Weston
code-base, and would almost certainly not be accepted upstream.
> -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.
I don't think it is so important to make a decision as much as to be
aware of all the possibilities.
Also, while I'm happy that swc is getting attention, it is perhaps
happening just a little too early; don't expect to be able to try it out
right now, I have a lot of changes pending in my working tree which I
hope to get committed over the next few days. Additionally, there are a
couple of final things I need to finish up (mainly VT switching).
--
Michael Forney <mforney_AT_mforney.org>
Received on Tue Jan 14 2014 - 22:11:20 CET