
Writing a Wayland Compositor, Part 1: Hello Wlroots - ddevault
https://drewdevault.com/2018/02/17/Writing-a-Wayland-compositor-1.html
======
niftich
When I'm unfamiliar with the internals of a piece of software, it can seem
like black magic; but it's illuminating to see something you didn't know break
down into familiar steps. When the rationale behind the steps and the secret
sauce -- business logic -- between them is explained incrementally, my
understanding of the system grows even more, so I love posts like this.

However, can you say a few words about why one would want to a write an
alternate Wayland compositor professionally (i.e. reasons other than learning
and exploration) -- as in: does the protocol offer places where meaningful
feature differentiation can be achieved, while still achieving full
compliance?

The existence of something like 'wlroots' to me is an indicator that
prospective Wayland compositors are, by necessity of supporting the Wayland
architecture, more similar than different. Is that accurate?

~~~
Sir_Cmpwn
wlroots is designed to support many different user interaction paradigms. Many
Wayland compositors do share the same nuances, sure, but many do not. In
addition to the typical desktop experience, you can use wlroots to make a
compositor which arranges windows in 3D space for VR, or make a compositor
that runs a phone interface, or a dashboard for a car, or any number of other
use-cases.

Even within the desktop paradigm, there's a lot of variance and room for
compositors to specialize, but it's more subtle.

~~~
katastic
I'm still waiting for someone to make a wayland compositor that compares to
compiz. One super important feature I use every day is being able to invert a
SINGLE window and not the entire screen.

For all the "omg it's slow" posts about compiz and x-server, it's fast enough
to run on my netbook with a 5-watt processor.

~~~
virtualwhys
> One super important feature I use every day is being able to invert a SINGLE
> window and not the entire screen

While it's not per window inversion, for years I've been using the tiny
(100KB) and wondrous _xcalib_ package for screen inversion*

Should note that in order to get per screen inversion working I need to use
Nvidia's Xinerama extension (without this extension inversion happens across
all screens).

* bound to alt-o/alt-i hotkeys with _xbindkeys_. Here's the _.xbindkeysrc_ if anyone's interested.
    
    
        # invert screen 0
        "xcalib -i -a -s 0"
          m:0x8 + c:32
    
        # invert screen 1
        "xcalib -i -a -s 1"
          m:0x8 + c:31

~~~
osivertsson
With xcalib I never got inversion working on all screens, only the first one
(Intel graphics).

However, XRandR Invert Colors [1] has worked flawless with multi-monitor
setups.

[1] [https://github.com/zoltanp/xrandr-invert-
colors](https://github.com/zoltanp/xrandr-invert-colors)

------
georgewsinger
For Wayland-based 3D VR Compositor in the works:
[http://GitHub.com/SimulaVR/Simula](http://GitHub.com/SimulaVR/Simula)

Good Wayland tutorials are rare in the wild. A guide like this would have been
helpful when starting this projec several months ago. :]

~~~
mncharity
When it is useful to point at the future? And when not?

Looking back, did all the discussion of whether PCs had a role in homes
actually accomplish anything? Or all the "well, there's only the Vatican
archive so far, but the WWW is going to be _big_!" conversations? Or about
tablets and phones?

People often don't picture design spaces and their critical constraints; and
don't track tech changes and their impact on those constraints; and say so
many silly things.

So here we are again, this time with VR/AR.

GNOME, KDE, Qt? Well, I guess Motif still exists. And MUMPS.

It was clear in the early 1990's that tablets would be a thing a decade later
(eg, DEC was showing a prototype and nice year-vs-performance/size/cost
curves), and that mice wouldn't be sufficient. We ended up writing a lot of
Java (from 1995) and Objective-C (1985) and C++ (1985). And fought Microsoft
over JavaScript. But a lot of known programming language features, which would
have helped us, we didn't get to use.

I really wish our programming languages today, were a little further along
towards not sucking. Because we're about to rewrite the world again.

But when/where is it worth taking the time to discuss such?

~~~
shmerl
_> So here we are again, this time with VR/AR._

Until OpenXR will be ready, there won't much movement in this regard.

See: [https://www.khronos.org/openxr](https://www.khronos.org/openxr)

~~~
mncharity
> Until OpenXR will be ready, there won't much movement in this regard.

Maybe. I can't comment on the market economics. But I've learned to be very
careful about attributing XR design space constraints. Because such care is
often skipped. And I suspect it matters.

When Varjo says their high-resolution HMD users will need dual Optimuses,
there's an implicit assumption that users will be running Autodesk monsters.
When Valve says Vive and WMR require 90 fps and low-variance latency and a gtx
1060, they're assuming immersive gaming.

In contrast, I normally run my HMDs at 30 fps on an old laptop with integrated
graphics. Using a full-screen web browser as compositor, and a little WebVR-
like hack. How? It's remote desktop not gaming; with a ducktaped-on camera for
passthrough AR (helps with low-fps tolerance); and no lens correction (also
helps); and mixed-resolution 3D rendering; and desktop windows not
participating in the 3D rendering. And it's ok.

Different VR/AR "markets" have _very very_ different constraints. Silly
example: Vive HMDs have an table of their measured OLED-pixel brightnesses.
Because individual pixels vary. And the Valve render compensates for that.
Because otherwise, as you turn your head, you would notice the pattern. For
Valve, that would be a "horrible" (quote) immersion-breaking visual artifact.
Gasp. But for me, meh. I don't pretend the screen on my laptop is my desk, and
I see no reason to pretend the screen on my face is my office. Sometimes you
want to fix annoyances, but sometimes you simply want to get used to them.

So yes, XR stacks can be crazy hard. But they can also be pretty easy. And
people with markets that require the hard, often speak as if the easy didn't
exist.

But does that matter? Let's imagine Xmas 2018 gets us inexpensive laptops with
discrete GPUs, and an HMD with 2k-pixel-square/eye and rectangular subpixels
(for subpixel rendering). And let's say that's still without eye tracking.
From the perspective of "hard", that's merely a larger market for low-end VR
gaming. But from the perspective of "easy"... that may be tipping point on
software dev being better done in XR than on physical monitors.

So I look forward to OpenXR. And it seems likely that movement, in some
directions, really does have it as a blocking dependency. But as with so many
other suggestions of VR hardware and software blockers, perhaps some
transformational disruptive change may be possible without it.

------
mwcampbell
Is there any advantage to using OpenGL even if one isn't interested in 3D
effects in either the compositor or applications? IIUC, the Weston reference
compositor has a back-end that doesn't require OpenGL but just uses the
framebuffer device and pixman. Wouldn't that be faster on systems that don't
have 3D hardware, or that don't have free drivers for that hardware (e.g. some
ARM boards)?

~~~
Sir_Cmpwn
We don't just paste pixels on the screen, we composite them. This involves
alpha blending, projecting the scene onto an orthographic output projection,
and more. Even in two dimensions, OpenGL is very useful here. On systems
without suitable hardware, you should be able to use OpenGL in software (via
mesa) and it will still be very fast here.

~~~
mwcampbell
Ah, thanks for that clarification; I'm pretty ignorant about graphics. Good to
know that Mesa will be fast in this case. I tried running full-blown GNOME on
an ARM board (Wandboard) without proper driver support for the GPU, and GNOME
Shell used ~40% of a CPU at idle. I'm guessing that something like Sway, even
though it uses OpenGL, is less demanding.

~~~
emersion
Even with software rendering, a wlroots compositor should use 0% when idle
thanks to damage tracking (ie. only redrawing parts of the screen that
changed).

------
braderhart
I believe that Sway will be the key to mass Linux desktop adoption, once
someone wraps it into a modern distro like Arch.

Unfortunately work on kmscon has discontinued. I'm currently using rxvt-
unicode. I've been looking at exploring alacritty.

Is there any chance you'll be building your own console emulator? I've had
this idea floating around, that in addition to supporting ANSI escape codes,
of a terminal that supports a lightweight markup language for UI. I saw your
recent activity regarding Vulkan support.

Your WM has just about all the components necessary to build these kickass
graphical "console" applications.

~~~
eikenberry
> I believe that Sway will be the key to mass Linux desktop adoption...

I'm curious what the basis of this thinking is. Sway looks like a nice i3-like
tiling window manager for Wayland, but I don't see how such a piece of
software would make so much of a difference.

~~~
braderhart
I used Windows primarily for over 20 years. I experimented with dwm back in
2006 and really enjoyed the idea. Something clicked in my brain a while back
and I tried Arch Linux. It took a lot, and I mean a lot of stubbornness on my
part (and on Arch) for me to figure out how to get a minimalist desktop with
just about everything working. Now that I do though, it is very easy and
simple to understand. I really don't need any bloat and my OS is pretty much
portable at this point, and I have great software to do pretty much everything
I want.

My computer isn't terrible, but it is much older. I've got external monitors
connected to it. Using i3 just feels natural at this point. I definitely feel
more efficient. I have everything integrated that on Windows requires
compatibility layers.

My passwords are stored using Pass, so I can even use latest encryption. I use
browserpass for password integration. I've got integrations in rofi for Chrome
tabs. I mean, the simplicity and speed make using a computer exciting and
enjoyable for me.

If I were using a VR or AR device, I don't want to manage location of items. I
like technology helping me and not getting in the way. This is what I think a
properly optimized and configured desktop could be like, and I haven't ran
into any issues. I can even watch YouTube and other streaming services
natively and with graphics acceleration using mpv and youtube-dl.

With this framework, we won't need Android for mobile and Vulkan integration
isn't too far away. I feel like with a little creative thinking, that tiling
window managers can be whatever you want them to be.

Take this for example,

[https://i.redd.it/lcz6566yfwsz.png](https://i.redd.it/lcz6566yfwsz.png)

Or this,

[https://imgur.com/a/VBQML#fIjDknv](https://imgur.com/a/VBQML#fIjDknv)

Now take GTK/Gnome or Qt/KDE + X11, which are a strong learning curve for UI
development, and bloated upon dependencies galore (some of this is just poor
packaging) and evaluate how much of that codebase is actually producing
quality applications to win the Desktop space for Linux.

You have 2 (some would argue 3 or more) commercial Linux distros that have
been unable to do so, and now partner with Microsoft. I see developers
flocking towards JavaScript because that is being pushed as the solution for
UI development.

There is a reason that Linux desktop is failing, and I believe that tiling
window managers help solve that.

No offense to Mozilla or Chrome teams, but damn your browsers are bloated and
unnecessary. I can't wait for chopsui or whatever else the right scripting
language is to come along and sweep it all up, because that is what will
happen. Sorry Microsoft, but your 4GB OS will be blown away by something that
will probably clock in at less than 1GB with Wayland/Vulkan.

Now wrap that into container isolation, and you've got yourself a policy
framework.

~~~
jhasse
"But it can't proberly open .docx and play PUBG"

~~~
braderhart
If you have an integrated and separate card for gaming, then you can do just
about anything, including running Mac inside Linux:

[https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...](https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF)

~~~
jhasse
I doubt that any of that has anything to do with the reasons that there's no
"mass Linux desktop adoption".

And I wouldn't count Linux running Windows in a VM most of the time as a
"Linux desktop".

~~~
braderhart
What do you consider some reasons then?

I really don't recommend running a Windows or Mac VM simply for compatibility,
because then you lose out on a bunch of perks, but you can. I mean you can use
something that is free and the source code is available for rich and poor
people alike, and the web is full of information and communities to help you
get started and prosper from your new open source skills and education. Or you
can pay for spyware and then pay more to supposedly protect yourself from
spyware, while installing more spyware to make you safer, and then you will
need adware for that spyware, and then some additional apps to make sure that
you only install OS-approved spyware.

~~~
jhasse
> What do you consider some reasons then?

Too often users need to use the terminal.

~~~
braderhart
Well, you had to admit that with auto-complete, it is pretty cool to just type
a couple letters and tab your way to heaven. Have you tried Rofi? There are
some descent themes, but in all honesty the terminal is great. It is a text-
based dynamic solution which makes it extremely versatile and compatible.

What is more natural than just typing and tabbing to what you want? That is
some simple voice navigation stuff as well, or once you get to VR, then tab-
complete can be like auto-suggest.

Have you seen Vim with perfect horizontal, vertical windows, and re-scaling? I
have, and it is glorious! Once you add proper icon font support and Airline,
it is hard to beat... yes, Neovim is probably better.

However, it is a matter of time before chopsui or another UI toolkit comes
along that will essentially wrap around all these great terminal applications
in a way that will create the layouts and styling that web users are mostly
used to. I hope instead though that, it is more general, and that information
is decoupled from design. Instead, I hope that sites will be able to request
to change layouts, and that we will build better decentralized marketplaces
for developers.

------
craftyguy
I'm really looking forward to using wlroots with sway! Thanks for all of your
great work Drew!

------
shmerl
Is there something like xinput for Wayland? I tried switching to Wayland
session in recent KDE Plasma 5.12.0, but lost the setting that emulated middle
click with left + right clicks, that I was setting with xinput.

~~~
jcrben
I was just looking at a similar topic yesterday - trying to find a Wayland-
compatible replacement to tools such as xdotool or xcape (see e.g.
[https://askubuntu.com/questions/956640/equivalent-to-
xdotool...](https://askubuntu.com/questions/956640/equivalent-to-xdotool-for-
wayland/977801#comment1630814_977801)).

People keep saying this was "decided" for security, but usually with no
sources cited. I wasn't able to find a firm decision and discussion/roadmap.
Instead it seems more like it was viewed as "handling this in a secure way is
hard, let's skip trying to figure it out". Which is pretty sad, since as far
as I can tell users didn't really get much in the way of tangible benefits
from Wayland aside from security (altho the KWin maintainer points to Wayland
being easier to test automatically [https://blog.martin-
graesslin.com/blog/2018/01/kwinx11-is-fe...](https://blog.martin-
graesslin.com/blog/2018/01/kwinx11-is-feature-frozen/)).

I found a RFC on a mailing list: [RFC] Interface for injection of input events
([https://lists.freedesktop.org/archives/wayland-
devel/2017-Ma...](https://lists.freedesktop.org/archives/wayland-
devel/2017-March/033514.html)) where the xdotools maintainer chimed in with
some thoughts. But it seems to have died quick.

I then scoured the Wayland freedesktop bugs
([https://bugs.freedesktop.org/describecomponents.cgi?product=...](https://bugs.freedesktop.org/describecomponents.cgi?product=Wayland))
and one of the closest things I could find to a discussion of related issues
was an open bug "Add an API for taking screenshots and recording screencasts"
([https://bugs.freedesktop.org/show_bug.cgi?id=98894](https://bugs.freedesktop.org/show_bug.cgi?id=98894))
which has to deal with similar security challenges.

Ultimately I, along with other automation-minded folks, will be sticking with
x11 until this is figured out. macOS also has a decent automation story, with
tools like Hammerspoon, Automator, and so on.

I've got a fair bit of other notes on the topic which I can share with anyone
interested - for example I saw "Some way to inject automated libinput events?"
([https://bugs.freedesktop.org/show_bug.cgi?id=99800](https://bugs.freedesktop.org/show_bug.cgi?id=99800))
where the person was actually trying to tune a gamepad.

Also see
[https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_...](https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_done_on_wayland_still/)
where people are saying that Wayland is further fracturing the Linux desktop
world.

~~~
eikenberry
A while back I looked into Wayland and what was missing that I would need to
replicate my current setup. Here's the list I came up with...

    
    
        openbox - window management
        xinput - trackball/input configuration, disable touchpad
        xbindkeys
        setxkbmap - control/cap-lock manipulation
        redshift
        Xresources/xrdb - urxvt & general X settings
        xdotool - script-able window movement
        xclip/sselp - script-able copy-n-paste
        zenity - scripting gui things
        xset - dpms, screen blank, keyboard auto-repeat, mouse movement rate
        conky - system info
        dunst - notifications
        unclutter - no pointer
        xsslock/xtrlock - screenlock
        xrandr - display config
        urxvt - terminal/shell access
    

Most of these had no Wayland equivalents that I could find. I have no plans on
switching anytime soon.

~~~
Sir_Cmpwn
Much of this doesn't have a 1:1 equivalent tool, but is workable anyway. This
comment got really long so I moved it into a gist:
[https://gist.github.com/SirCmpwn/594040cb476f93c503715d4635b...](https://gist.github.com/SirCmpwn/594040cb476f93c503715d4635ba27f5)

~~~
eikenberry
Wow. Thanks for the detailed reply. I'll add that to my notes. I'm curious to
see how this plays out with wlroots and how people will build on it to bring
the something like variety of window manager X has to Wayland.

Using Xwayland for a significant number of things makes me curious about how
much overhead it adds. The only article I found was from 2014 and it showed it
adding significant overhead. Anyone know of any newer data?

~~~
shmerl
I don't think it should add a lot of overhead. Performance wise it shouldn't
be any worse than regular X.

~~~
eikenberry
The article I mentioned in case you were curious.

[https://www.phoronix.com/vr.php?view=20956](https://www.phoronix.com/vr.php?view=20956)

~~~
shmerl
Thanks. I should run some Witcher 3 in Wine benchmarks with XWayland.

Though currently TW3 suffers from low performance regression in general, so it
won't be very conclusive.

Also, I suspect some of it can be compositor specific.

------
robert_foss
What a nice tutorial, thanks for putting the effort in!

------
eximius
Somewhat off topic, but still highly relevant:

Sir_Cmpwn, now that your stretch goal in your crowdfunding campaign has been
reached, what will you do? Do you have ideas for a new goal?

I expect a fair portion of the traffic came from this post. So if you have
ideas for them, comment below?

~~~
Sir_Cmpwn
Thanks for asking! We honestly weren't expecting to get this far this fast, so
our plans are a bit nebulous. We're trying to figure out how to schedule for
an additional dev to come out to Philly as a new stretch goal. More details
later, I'm heading to bed.

