Category Archives: Wayland

Wayland Display Server Protocol

Wayfire Live Window Previews

2005 was the year of Compiz. 20 years later, we’re doing it all over again. Designed with the power user in mind, Wayfire continues to push the bar with astounding animations, effects and functionality. In today’s post, we’re talking about live window previews. The concept is that you have a window button in a taskbar and hovering over it yields a tooltip containing a live preview of the corresponding window. This is a sought after feature but there are many ways to skin this cat and wayland makes for an interesting ride. You can have the client tell the compositor where to render the tooltip preview but where’s the fun in that? You could have the client request a buffer stream and send the bits to the client so it can render them as it sees fit. So how did we do it? The latter seemed to be the more reasonable choice, so that’s how it started. Wayfire has the ability (for a plugin) to communicate with a client using ipc, side banding messages not on the wayland socket wire. The way this works is: On button enter, the client sends an ipc message with the view id. The wf-live-previews plugin receives this message and creates a view-sized headless output named “live-preview-#” where “#” is the view id. Then the plugin sets up rendering the view to the output. The client gets the new wl_output global and checks the name, then uses this to begin requesting frames for the hidden output using the standard wlr_screencopy protocol. Finally, it gets the frames and displays them (in this case) in a tooltip. And if that wasn’t enough, the client in question is a python panel called panorama-panel. It uses pywayland, pywayfire ipc and gtk4 in a python client, which make for a powerful combination. Now to drive the point home, is a video:

Wayfire Animation Updates

Wayfire is constantly improving and new interesting animations are constantly pushing the bar. This time, we introduce a new animation part of wayfire-plugins-extra extra-animations plugin. It is called melt, and has an interesting story. Long story short, it was created by an AI LLM. Spoiler alert: It was Google ‘AI Mode’. I fed it the current fire shader and asked it to make an improved version. It spit back a shader which I massaged into an instance that wayfire could consume. In addition to the distortion there was a lot of code to render a gradient of color to simulate some fire, but I felt the distorted surfaces were spot on for a wayfire open/close animation. So I ripped the gradient out and left it as a shader that melts the view to/from existence.

Additionally, a long time wayfire contributor Daniel Kondor filed this issue. At first I dismissed it because the squeezimize shader is quite difficult to work with in its current state. However I am really glad that someone brought this up because 1) it pushed me to improve squeezimize shader and 2) Daniel wrote a companion shader which allows the squeezimize animation to reasonably handle left and right minimize targets. Before, it only handled top and bottom panels. Of course all of this text can be boring and cumbersome, so here are some videos:

Melt Animation

Improved Squeezimize

Wayfire Animations

Wayfire is maturing nicely with an animation infrastructure that makes it relatively easy to create new animations. However, even though wayfire has the nice fire animation, it only has a few other basic ones. Recently, wayfire gained support for a new option type of ‘animation’. This type allows you to select an easing as well as duration. One animation that wayfire users have been talking about for years, is the classic magic lamp minimize animation. And secretly, I’ve been wanting to write this animation. After a comment from a user in wayfire chat about this animation being the only thing missing from their wayifre-dots setup, I figured it was time to try my hand at implementing the effect. I decided to call it ‘squeezimize’, and started coding.

At first, I rendered the view in a loop, scissoring the transformed surface into horizontal lines. This worked ok, but the sigmoid curve seemed to be lost in the math, and worst of all, the implementation was slow. After bouncing around some ideas to make it faster, it seemed the way forward was to write a fragment shader to render the effect in a single pass per frame. After a lot more math and coffee, I came up with this very thing. A simple fragment shader that requires minimum glsl version and only uses basic math. It does not use builtin shader functions other than clamp(). This means it’s fast. And, the shader renders better curves than the slower line by line proof of concept.

TL;DR: Wayfire has a new shader called squeezimize that renders a magic lamp effect. Yes it’s been done, time and time again, but because it’s a single pass shader with very little input, it’s low on resources. After writing squeezimize, I wrote two more animations for wayfire open/close windows, called zap and spin. Now for a video:

EDIT: There are now two more animations, in addition to the above, helix and blinds:

 

Decoration Adventures

Wayfire has decoration plugins and even a shadow plugin available. The shadow plugin works great, for square decorations at least. Adding rounded corners with shadows that hug them would be a nice addition. So, I set out to do that, and the results even surprised me.

I started hacking on pixdecor plugin, first porting it to work with latest wayfire, then adding compute shader support for decoration animations, patterns and overlay effects. Out of all the things, none of the effects had a need to render beyond the decoration area, into the shadow region. This basically meant making the rendering area larger, to have a place to scribble in some shadows. The concept is simple but implementing it required changing the code very carefully in many different places. Even after getting it right, changing some settings might make the decoration the wrong size or some other problem (like crashing). After shaking out the bugs for the shadow padding, it was time to shade some shadows.

I knew I wanted simple code that got straight to the point. After poking around a bit on shadertoy and not finding what I wanted, I decided to write the shader from scratch. Here’s the path I ended up with. First, the decoration is cleared using a clear color or otherwise filled in with an effect shader. Then, the overlay shader is applied. The overlay has eight conditionals, one for each side and one for each corner. For the sides, it measures the distance from the edge to the pixel color being written and mixes transparent with the shadow color, depending on how far away it is. The corner is the same recipe but it picks a single point in the corner and uses it to measure the corner and shadow radius. This means that even though the corners are rounded, the shadows follow the curvature. The other nice thing about the overlay is that is automatically anti-aliases the edges of the rounded corners by mixing, instead of just discarding pixels or other method that leaves jagged corner edges.

All of this, and everything is configurable in real time, from the border size to the corner radius and shadow radius, color, etc. It took some careful coding to make everything work together but in the end, it is working nicely, with great performance. Now, for the video:

Wayfire Smoke

A wayfire user decided to port weston smoke into wayfire and while it worked, it was quite slow, even at modest sizes. I patched weston smoke to be resizable but this only showed how slow the cpu-bound algorithm is. So, I decided to try my hand at making it faster, using a compute shader. At first, there was a single shader but realized that each loop needed its own shader. It was also slow at first but after tweaking the workgroups per dispatch and the workgroup size in each shader, the difference was multi-fold. It took some time to implement and optimize but it worked out pretty well. The code has been uploaded here. The performance improvement results are astounding and there isn’t much else to do than watch some comparison videos:

Original Weston Smoke Client:

Implementation in a Decorator:

Side by Side Standalone Clients:

Wayfire Ubuntu Packages

After more than a few requests for wayfire deb packages that work on ubuntu, I decided to try creating some. The result is a success. This is how I did it.

First, I started with the latest code. I will cover wayland and wayfire packages. There are others that are required, but these two are different in that wayland packages are already in ubuntu but there are none for wayfire.

For wayland, we will copy the debian directory, containing the interesting files for building a package from upstream, and place it in the upstream code directory.

$ git clone https://git.launchpad.net/ubuntu/+source/wayland wayland-ubuntu
$ git clone https://gitlab.freedesktop.org/wayland/wayland wayland-upstream
$ cp -r wayland-ubuntu/debian wayland-upstream

Next, we want to prepare the environment by installing the build dependencies.

$ sudo apt-get build-dep wayland
$ sudo apt install gcc g++ meson ninja debhelper dh-make

Finally we want to configure and build the packages.

$ dh_auto_configure --buildsystem=meson
$ dpkg-buildpackage -rfakeroot -us -uc -b

This results in the following packages:

libwayland-bin_1.19.90-1_amd64.deb
libwayland-client0_1.19.90-1_amd64.deb
libwayland-cursor0_1.19.90-1_amd64.deb
libwayland-dev_1.19.90-1_amd64.deb
libwayland-egl1_1.19.90-1_amd64.deb
libwayland-egl-backend-dev_1.19.90-1_amd64.deb
libwayland-server0_1.19.90-1_amd64.deb

For wayfire, the process is similar but we need to generate the debian files. Install dependencies manually, by satisfying meson first.

$ git clone https://github.com/WayfireWM/wayfire && cd wayfire
$ dh_make --createorig -p wayfire_0.8.0
$ dh_auto_configure --buildsystem=meson
$ dpkg-buildpackage -rfakeroot -us -uc -b
$ ls ../*.deb
../wayfire_0.8.0-1_amd64.deb

Here is a PPA containing all the packages needed for wayfire on Ubuntu >=20.04. To install wayfire:

$ sudo add-apt-repository ppa:soreau/wayfirewm
$ sudo apt-get update
$ sudo apt install wayfire wayfire-plugins-extra wf-shell wcm xwayland

Launch wayfire by running it from X or tty, or simply logout and select the Wayfire session.
To remove completely:

$ sudo apt install ppa-purge
$ sudo ppa-purge ppa:soreau/wayfirewm

Wayfire

Usually I blog about compiz after a release but I wanted to share something different. There is a C++ wayland/wlroots compositor by Ilia Bozhinov in the works that has many compiz-like features. It’s called Wayfire and it has quite a few bells so far. It functions on a plugin based system much like compiz and the API is fairly nice. I’ve written wcm,  a configuration GUI for wayfire inspired heavily by ccsm. There are videos on the website at wayfire.org you can view to see the basics. It will only work with drivers offering gbm however, which basically means it works with open source drivers. Wayfire and wlroots are very much in development so the bleeding edge may not work but when it does, it’s fire.
General build guide for ubuntu 18.04:

1) Install dependencies from packages.

$ sudo apt install git python3-pip pkg-config libwayland-dev autoconf libtool libffi-dev libxml2-dev libegl1-mesa-dev libgles2-mesa-dev libgbm-dev libinput-dev libxkbcommon-dev libpixman-1-dev xutils-dev xcb-proto python-xcbgen libcairo2-dev libglm-dev libjpeg-dev libgtkmm-3.0-dev xwayland

2) Install meson and ninja.

$ pip3 install meson ninja; . ~/.profile

3) Export prefix, PATH and PKG_CONFIG_PATH variables.

$ export prefix=/opt/wayfire
$ export PATH=$prefix/bin:$PATH
$ export PKG_CONFIG_PATH=$prefix/lib/pkgconfig:$prefix/share/pkgconfig:$prefix/lib/x86_64-linux-gnu/pkgconfig

4) Create the installation directory and change user and group so we can install the software as user. Also create a src directory to hold the source code.

$ sudo mkdir $prefix; sudo chown $USER:$USER $prefix
$ mkdir ~/src; cd ~/src

5) Clone the source we will need.

$ git clone https://gitlab.freedesktop.org/wayland/wayland
$ git clone git://anongit.freedesktop.org/wayland/wayland-protocols
$ git clone git://anongit.freedesktop.org/xcb/libxcb
$ git clone https://github.com/swaywm/wlroots
$ git clone https://github.com/WayfireWM/wayfire
$ git clone https://github.com/WayfireWM/wf-shell
$ git clone https://github.com/WayfireWM/wcm

6) Build the source code.

$ cd ~/src/wayland && ./autogen.sh --prefix=$prefix --disable-documentation && make && make install
$ cd ~/src/wayland-protocols && ./autogen.sh --prefix=$prefix && make && make install
$ cd ~/src/libxcb && ./autogen.sh --prefix=$prefix && make && make install
$ cd ~/src/wlroots && meson build --prefix=$prefix && ninja -C build && ninja -C build install
$ cd ~/src/wayfire && meson build --prefix=$prefix && ninja -C build && ninja -C build install
$ cd ~/src/wf-shell && meson build --prefix=$prefix && ninja -C build && ninja -C build install
$ cd ~/src/wcm && meson build --prefix=$prefix && ninja -C build && ninja -C build install

7) Copy config files in place and modify them a bit.

$ cp ~/src/wayfire/wayfire.ini.default ~/.config/wayfire.ini
$ cp ~/src/wf-shell/wf-shell.ini.example ~/.config/wf-shell.ini
$ sed -i 's/env XDG_CURRENT_DESKTOP=GNOME gnome-control-center/wcm/' ~/.config/wf-shell.ini

Optionally set a background image in ~/.config/wf-shell.ini from your system.

8) Save this script as /usr/local/bin/wayfire.

#!/bin/bash

prefix=/opt/wayfire
log_file=/tmp/wayfire.log

export PATH="$prefix"/bin:$PATH
export XDG_DATA_DIRS="$prefix"/share:$XDG_DATA_DIRS
export GTK_THEME=Adwaita:dark
export GDK_BACKEND=wayland
export QT_QPA_PLATFORM=wayland
export LD_LIBRARY_PATH="$prefix"/lib:"$prefix"/lib/x86_64-linux-gnu/
exec "$prefix"/bin/wayfire "$@" &> "$log_file"

8b) Make it executable.

$ sudo chmod +x /usr/local/bin/wayfire

9) Run it.

$ /usr/local/bin/wayfire

9b) Open an application. Either run a native terminal,

WAYLAND_DISPLAY=wayland-0 GDK_BACKEND=wayland terminator

or an X11 one.

DISPLAY=:1 xterm

10) Optionally switch to tty to use the drm backend. Make sure your user is part of the video group to run as user.

sudo adduser $USER video

11) Optionally create /usr/share/wayland-sessions/wayfire.desktop to login from lightdm.

[Desktop Entry]
Version=1.0
Name=Wayfire Session
Comment=Use this session to run Wayfire as your desktop environment
Exec=/usr/local/bin/wayfire
Type=Application

Firefox nightly should work as a native browser. Ctrl+Alt+Bckspc to log out. Any questions should be asked in #wayfire on irc.freenode.net or an issue filed on github for the relevant component. To remove the compiled packages and source, remove /opt/wayfire/, ~/src/, /usr/local/bin/wayfire and /usr/share/wayland-sessions/wayfire.desktop. Checkout wayfire.org for more information.

Wayland Wobbly Whistles

I found some time and inspiration to resume working toward wobbly wayland surfaces. After making decent progress, it’s time for another blog entry.

Effects such as wobbly windows are argued by some to be a blatant waste of time for both developers and users. However, many still enjoy wobbling their windows despite the controversy. Some power users claim that the mindless wobbling is a welcome brain rest during other tasks. Critics aside, the effect continues to live on in different forms and implementations.

In this iteration, I decided to port the original compiz plugin to wayland surfaces. First, I isolated the code to identify the algorithm inputs and bound the output to a more easily portable format. Then I worked on massaging it into the compositor code, creating a rudimentary plugin API. In the process, the zoom code was also isolated in it’s own plugin. For the moment, plugins aren’t loaded automatically and must be specified in the config file.

Surprisingly, the model positioning code is the most complicated issue because the plugin must render such that the surface position is synced with the compositor when the wobbling cycles are complete. One annoying positioning problem was related to a combination of rotating and resizing but I managed to track down the core issue and fix this case.

The way opaque and blend regions are handled requires duplicate rendering; one with the opaque rbgx shader and another pass for blended rgba. Since wobbly requires additional arbitrary vertices, it’s not really feasible to draw two different regions. For now, it uses the usual rgba shader if the blend region is not empty and the rgbx shader otherwise.

Further plans include writing an interface to talk to the compositor from a GUI and more compiz-like plugins. Check back later for more updates.