Mir support for wayland

Weston

Weston — это эталонная реализация композитного менеджера Wayland. Написан на языке Си, сначала был опубликован под лицензией GPLv2, позже вышел под MIT. Weston изначально создавался под API ядра Linux, поэтому официально поддерживает работу только с ядром Linux из-за зависимости от KMS, GEM и udev.

Weston использует GEM для обмена буферов между графическим сервером и приложениями. Для рендеринга может использовать OpenGL, cairo и pixman.

Maynard

Maynard — графическая оболочка, которая была создана как плагин к Weston, аналогично тому, как GNOME Shell был создан как плагин к Mutter. Изначально Maynard проектировался для Raspberry Pi как легковесная графическая оболочка, поскольку в то время (2014 год) легковесные окружения рабочего стола, такие как LXDE, не поддерживали Wayland, а функциональные окружения типа GNOME и KDE были слишком ресурсоёмкими. Проект не ограничен платформой Raspberry Pi и может использоваться на обычных рабочих станциях. Оболочка отличается низким потреблением ресурсов, высокой производительностью, качественным оформлением и легковесностью.

How do I use QtWayland?

Run Qt applications as Wayland clients

When you build the QtWayland module, you should get a new platform plugin for wayland. To use it you must first already have a Wayland compositor running. This could be either the Weston reference compositor provided by the Wayland project, or a Qt example compositor provided by QtWayland. Regardless the only thing you need to do as an application developer to run your GUI application as a wayland client is tell the application to use the right platform plugin:

.application -platform wayland

export QT_QPA_PLATFORM=wayland
.application

Running example compositors

The QtWayland module provides a couple of example compositors that demonstrate how the Qt Wayland Compositor API works. These are built in the examples folder of the QtWayland module. You may need to explicitly build them (depending on how you configured Qt):

cd qtwayland
make sub-examples

These examples represent the server side of Wayland, so they do not use the wayland platform plugin, but rather whatever platform you need to run on. Generally this is going to be either eglfs, kms, or if you want to run in X11 xcb. You can also run a nested compositor if you run the compositor on the wayland platform plugin.

If you wanted to run the pure-qml compositor in X11 you would run the following:

cd qtwaylandexampleswaylandpure-qml
.pure-qml -platform xcb

And now that you have a Wayland compositor running, you can connect and display Wayland clients.

Creating your own compositor

Compositors can be implemented using QML, or you can use the C++ API if you need more low-level control.

• C++-based: See the minimal-cpp and qwindow-compositor examples.

The project file will need to use the compositor module (i.e. add in the .pro file QT += waylandcompositor).

GUI libraries

GTK 3

The package has the Wayland backend enabled. GTK will default to the Wayland backend, but it is possible to override it to Xwayland by modifying an environment variable: .

Clutter

The Clutter toolkit has a Wayland backend that allows it to run as a Wayland client. The backend is enabled in the package.

To run a Clutter application on Wayland, set .

SDL2

To run a SDL2 application on Wayland, set .

Note: Many proprietary games come bundled with old versions of SDL, which don’t support Wayland and might break entirely if you set . To force the application to run with XWayland, set .

winit

Winit is window handling library in Rust. It will default to the Wayland backend, but it is possible to override it to Xwayland by modifying an environment variable: .

Overview

What you’ll learn

In this tutorial, we will create a snap of a Wayland-native application to act as the graphical user interface (GUI) for an IoT or kiosk device. We will walk through the process and solve some common problems along the way. For the introduction to this tutorial series and the Mir display server please visit here.

What you’ll need

• An Ubuntu desktop running any current release of Ubuntu, or an Ubuntu Virtual Machine on another OS.
• A ‘Target Device’ from one of the following:

  • A device running Ubuntu Core 18.This guide shows you how to set up a supported device. If there’s no supported image that fits your needs you can create your own core image.

  • A VM. You don’t have to have a physical “Target Device”, you can follow this tutorial using Ubuntu Core in a VM instead.

    Install the ubuntu-core-vm snap:
    sudo snap install —beta ubuntu-core-vm —devmode
    For the first run, create a VM running the latest Core 18 image:
    sudo ubuntu-core-vm init.
    From then on, you can spin it up with:
    sudo ubuntu-core-vm
    Which should show you a new window with Ubuntu Core running inside. Setting up Ubuntu Core on this VM is the same as for any other device or VM. See, for example, https://developer.ubuntu.com/core/get-started/kvm.

  • Using Ubuntu Classic You don’t have to use Ubuntu Core, you can use also a “Target Device” with Ubuntu Classic. Read this guide to understand how to run kiosk snaps on your desktop, as the particular details won’t be repeated here.

Deploy the snap on the device

Push the snap to your device:

using your device’s SSH username & IP address details.

We now have the .snap file on the device in its home directory. We need to install the snap, configure it to talk Wayland to mir-kiosk and run the application. In your ssh session to your device:

On your device, you should see the same graphical animations you saw earlier (and statistics logged to the journal). It will continue to run until you run “”.

Your device is now a kiosk! Rebooting will restart mir-kiosk and glmark2-example automatically.

Should you wish to share this snap, the next step would be to push your snap to the Snap Store.

Common Problem 1: Files are not where they’re expected to be!

One important thing to remember about snaps is that all its files are located in a subdirectory which maps to . To prove this, try the following:

This lands us inside a shell which exists inside the same snap environment the glmark2-wayland application will have. A quick “ls” tells us our theory is correct:

If binaries have paths to resources hard-coded in, then in a snap environment it will fail to locate those resources.

Here glmark2-wayland is looking for files within , which in actuality are located in :

This is extremely common when snapping applications, therefore there are a few approaches to solving this:

1. Your application may read an environment variable

Your application may read an environment variable that specifies where it should look for those resources. In that case, adjust your YAML file to add it with something like this:

In our case, glmark2-wayland has the path hard-coded in, so this is not going to work for us.

2. Changing the application

Sometimes you can edit/recompile the application to add the environment variable mentioned above. If it is your own code you are snapping, this is a good approach.

We could do this, but glmark2-wayland is not our own code and this adds an unnecessary maintenance overhead.

3. Using layouts for hard-coded paths

This snapd feature bind-mounts directories inside the snap into any location, so that the binaries’ hard-coded paths are correct. To use, append this to the YAML file:

Избегайте GTK+ 2 или Qt 4 приложений на Wayland

Большинство приложений Linux, с которыми вы общаетесь ежедневно, написаны для одного из двух графических наборов инструментов: GTK+ и Qt. Эти платформы выступают в роли клиентов для сервера отображения, запрашивая объекты, которые будут отображаться на вашем экране. Тем не менее, эти запросы должны быть поняты в первую очередь и это зависит от набора инструментов.

В результате на рабочих столах Wayland могут работать только некоторые типы программ. Например, программы GTK+ 3 также могут работать правильно. То же самое может быть написано в Qt 5 (инструментарий, на котором основан рабочий стол Plasma).

При этом, если вы попытаетесь открыть, скажем, приложение Qt 4, у вас будет хороший шанс его запустить. Wayland делает это, запуская X-сервер за кулисами, чтобы слушать приложения, которые он не может понять. Однако это может привести к более высокому использованию памяти и немного более низким скоростям. Плюс, есть некоторые вещи, которые этот подход просто не может сделать в данный момент.

Usage

Hardware requirements

It’s important firstly to check your hardware and make sure it’s compatible with your choice of desktop. The divide right now is strictly between two buffer APIs, GBM and EGLStreams. NVIDIA GPUs using the proprietary driver support EGLStreams, while all other graphics cards and driver combinations support GBM. A Wayland compositor needs to explicitly support one or both of these APIs in order to function.

As it stands, GNOME (using Mutter) supports both GBM and EGLStreams well. KDE Plasma (using KWin) supports GBM in all versions, and EGLStreams since Plasma 5.16. All other compositors only support GBM and will not function with the proprietary NVIDIA driver in use.

Desktops

GNOME

The Wayland session is built into GNOME and it should be an option in your display manager simply by having GNOME installed.

KDE

KDE Plasma requires the non-default plasma-workspace-wayland package to be installed. This is often enough for basic functionality, however you are recommended to read the detailed wiki section for , especially if you are using an NVIDIA GPU.

Others

Other Wayland compositors of interest may include Sway (a near drop-in replacement for i3) and enlightenment.

Applications

Introduction

GTK3 and Qt 5 applications using the system libraries should default to Wayland automatically. Some that use statically-linked versions of these, or which explicitly disable Wayland support for various reasons (e.g., KeePassXC), will require special flags or environment variables to be set.

Applications using X11 will work fine in Wayland via the Xwayland compatibility layer, however there may be input issues or other bugs introduced. When possible, using an application in its native Wayland mode is preferred.

GTK3

The GDK_BACKEND environment variable, when set to «wayland», will forcibly run a GTK3 application with the Wayland backend. Similarly, setting the environment variable to «x11» will force it to run with the X11 backend (useful for forcing applications to use Xwayland that have compatibility issues when operating in their native Wayland mode).

Note that some Electron applications (Slack, Element, Discord, etc.) may break when setting GDK_BACKEND to «wayland».

Qt 5

The qtwayland5 package will install the relevant platform plugin allowing Wayland apps to run natively with Qt.

You are recommended to set the environment variable QT_QPA_PLATFORM to «wayland,xcb» which will have applications prefer Wayland only use X11 as a fallback. You can, of course, set this to also be specifically either «wayland» or «xcb» if you want to force one.

The -platform wayland flag can also be used as a simpler means to force most Qt applications to use the Wayland backend.

SDL2

For games, applications, or other software that uses SDL2 as a toolkit, set the SDL_VIDEODRIVER environment variable to «wayland». Note that doing this on a system-wide basis isn’t recommended, as many proprietary applications use statically-linked versions of SDL2 that are older and may break when forcing the usage of Wayland.

Display Managers

GDM3

GDM (GNOME Display Manager) will automatically use Wayland when supported, except when using the proprietary NVIDIA driver, in which case it will fall back to X11 due to instability.

To use the X11 backend by default, uncomment the WaylandEnable=false line in the /etc/gdm3/daemon.conf file.

SDDM

Wayland support for SDDM itself is in progress, currently it uses X11 by default everywhere. SDDM is still capable of starting a Wayland session for a desktop however.

LightDM

There is little hope of LightDM obtaining native Wayland support, however it can still start a Wayland session for a desktop.

First Pass Snapping: Test on Desktop

For our first pass we will snap glmark2-wayland and run it in DevMode (i.e. unconfined) on our Ubuntu desktop.

This guide assumes you are familiar with creating snaps. If not, please read here first.

Create the snap directory by forking https://github.com/snapcrafters/fork-and-rename-me.

Inside the glmark2-example directory edit the “” file, and let’s try the following (SPOILER, won’t work immediately, read on for troubleshooting):

Building the snap

Create the snap by returning to the “glmark2-example” directory and running

You should be left with a “glmark2-example_0.1_amd64.snap” file.

Testing the snap

Run Miral-kiosk to launch a Wayland server, then install this snap and run it

(“dangerous” needed as local snap file being installed, and “devmode” required as we need to debug it)

Oh no! It fails with these errors:

We need to solve these.

Leave running while we work through the issues.

Troubleshooting

Slow motion, graphical glitches, and crashes

Gnome-shell users may experience display issues when they switch to Wayland from X. One of the root cause might be the set by yourself for Xorg-based gnome-shell. Just try to remove it from or other rc files to see if everything goes back to normal.

Remote display

• There was a merge of FreeRDP into Weston in 2013, enabled via a compile flag. The package has it enabled since version 6.0.0.
• AUR is a transparent proxy for Wayland applications, with a wrapper command to run over SSH

Input grabbing in games, remote desktop and VM windows

This change in input grabbing breaks current applications’ behavior, meaning:

• Hotkey combinations and modifiers will be caught by the compositor and won’t be sent to remote desktop and virtual machine windows.
• The mouse pointer will not be restricted to the application’s window which might cause a parallax effect where the location of the mouse pointer inside the window of the virtual machine or remote desktop is displaced from the host’s mouse pointer.

Wayland solves this by adding protocol extensions for Wayland and XWayland. Support for these extensions is needed to be added to the Wayland compositors. In the case of native Wayland clients, the used widget toolkits (e.g GTK, Qt) needs to support these extensions or the applications themselves if no widget toolkit is being used. In the case of Xorg applications, no changes in the applications or widget toolkits are needed as the XWayland support is enough.

These extensions are already included in , and supported by 1.20.

The related extensions are:

Supporting Wayland compositors:

• wlroots supports relative-pointer and pointer-constraints

Supporting widget toolkits:

GTK since release 3.22.18.

Issues with the Xorg

As discussed above, the design of the Xorg doesn’t allow the applications to have GUI-Level isolation. This implies that if the system has multiple GUI applications running, like Word Office, any of your favourite editor, or something else, then there is no isolation among them. It is easy to log keystrokes of all processes of the same user using the command xinput.
The command generates the log of all key-presses. Any kind of isolation is not possible, even using SELinux since any keystrokes passed to the X Server are available for any arbitrary program.
To see the issue in action you can use the xinput command available for systems running Xorg. First run the following command to list the devices on your system:

As can be seen in the above image the keyboard has the id of 14. Now run the following command to get the key presses:

Replace the id with the id of the device, in our case it is 14. After running the command open another terminal and start typing commands there. You will be able to see the recorded key logs on the initial terminal, just like shown in the image below.
Try running the sudo command, loggin in as root using su, you will observe that the password you type is also shown.

Screencast software

See also and Wikipedia:Comparison of screencasting software.

Screencast utilities allow you to create a video of your desktop or individual windows.

Byzanz — Simple screencast tool that produces GIF animations.

Deepin Screen Recorder — Screen recorder application for Deepin desktop.

FFcast — FFmpeg-based screencast tool written in Bash.

Green Recorder — Simple yet functional desktop recorder for Linux systems.

Kazam — Screencasting program with design in mind. Handles multiscreen setups.

OBS — Video recording and live streaming application.

Peek — Simple screencast tool that produces GIF, APNG, WebM or MP4 animations.

RecApp — User friendly screencaster written in GTK. Using free GStreamer modules and not depend on FFmpeg.

RecordItNow — Plugin based desktop recorder for KDE.

RecordMyDesktop — Easy to use utility that records your desktop into the ogg format with a CLI, GTK or Qt interface. (inactive development)

screencast — Command line interface to record an X11 desktop using FFmpeg, having support for offline recording and live streaming.

Screencast — Simple screencast recorder designed for elementary OS.

SimpleScreenRecorder — Feature-rich screen recorder written in C++/Qt5 that supports X11 and OpenGL.

VokoScreen — Simple screencast GUI tool using GStreamer.

XVidCap — Application used for recording a screencast or digital recording of an X Window System screen output with an audio narration.

Common Problem 2: Unable to connect to Wayland server

This error message is not too helpful, but an important thing to check is if the Wayland socket can be found. If not, glmark2-wayland cannot create a surface/canvas.

The convention is that the Wayland socket directory is specified by the environment variable. The default name for the socket is but it can be different (specified by ).

Generally, is set to where is the user id.

• Ubuntu Desktop: miral-shell creates the Wayland socket at , where is your user id.
• Ubuntu Core: Mir-kiosk runs as root on Core, thus the Mir-kiosk snap’s Wayland socket is located at

However inside each snap’s environment, is a custom subdirectory. To see this, this command gives a shell inside the same snap environment your application lives:

This reveals a problem with the Wayland socket not being in the right location for the application snap.

The solution we use is to symlink the Wayland socket into the in-snap (and to be safe, ensure the directory exists before adding the link):

“” will show the AppArmor denial:

Let’s test it:

Yikes! What’s happened?

Once again: files are not where they’re expected to be! Don’t forget, we’re in the snap environment still. All the libraries glmark2-wayland needs are not in the usual places — we need to tell it where.

Run these commands to set the linker paths and executable paths to commonly required locations in the snap environment (snapd does this before running your snap):

Note: you should add any additional library paths that the binary requires.

Snapcraft creates a script in that contains the command specified to run. Have a look at

It is this script which is called when you do “snap run …”. As we are still in the snap environment, we get the same result by running it:

Oh, still fails with a bunch of errors like

Courage! This is progress, we’re almost done in fact. There’s just one more thing to fix…

First Pass Snapping: The Final Bits

We need to set up the symlink of the Wayland socket into the $XDG_RUNTIME_DIR directory, and set the libgl environment variable before executing the binary inside the snap. The easiest option is using a utility maintained by the Mir team to make this easy. Add the following to the .yaml in the section:

…and change in the snapcraft.yaml file to use the it supplies. Like this:

We can ask snapcraft to set the environment variables to fix graphics by adding an section to the .yaml:

We can also enable strict confinement and see if everything works. Due to the care we took above, it does. Your own application may require more tweaking to function fully confined however.

The working YAML file:

Rebuild the snap and install it

Inside the Mir-on-X window, you should see the same graphical animations you saw earlier, and statistics printed to your console. The difference is that this time they are coming from your fully snapped application!

Основные принципы

The Wayland display server protocol relys on EGL

По мнению разработчиков, Wayland является «работой над ошибками» X.org, которые накопились за четверть века его развития. Кардинальное отличие от X.org заключается в том, что Wayland лишь управляет буферами (плоскостями) окон и возлагает всю отрисовку их содержимого на инструментальные пакеты (GTK, Qt и так далее). API рисования (drawing API) полностью отсутствует. Все версии протокола строго определены, а само версионирование продумано. У X.org есть серьёзная проблема с версиями разных расширений, часто перекрещивавшимися или дополняющими, вместо того чтобы быть самодостаточными и исключающими. Функцию композиции буферов осуществляет референтный композитный менеджер Weston, использующий как OpenGL ES, так и программную отрисовку. В состав Wayland также входит унифицированный протокол устройств ввода, предоставляющий одну виртуальную клавиатуру, одну виртуальную мышь и один tablet-интерфейс — разделяемые всеми приложениями. Wayland знает о состояниях устройств ввода и способен запоминать их: X.org не сохраняет состояния устройств (stateless-протокол), но может быть настроен через файлы конфигурации.

О Wayland его создатель отзывается так: «Wayland — новый графический сервер, который выполняет только крошечную часть функций Х, которые мы действительно используем, когда запускаем композитный рабочий стол. Wayland, по сути, — буферный менеджер (подобно DRI2 для X.org), обработчик входных данных. Весь рендеринг выполняется на клиентской стороне — так, как сегодня работает OpenGL, а задание режимов и другие аппаратные установки выполняются в ядре. Такой подход значительно упрощает организацию сервера».

Wayland использует уже существующие в ядре Linux технологии, такие как Kernel mode-setting (KMS), Direct Rendering Manager (DRM) и Graphics Execution Manager (GEM).

Разработка

Альянс GENIVI

Автомобильный консорциум GENIVI, чья цель создать платформу для IVI индустрии, поддерживает Wayland.

Maliit

Maliit, фреймворк системы ввода, работает под Wayland.

Mesa

Mesa имеет встроенную поддержку Wayland.

Sailfish OS

Первый телефон Jolla использует Wayland.

Tizen

Tizen поддерживал Wayland в IVI setups до 2.x версий включительно, а начиная с версии 3.0 по умолчанию использует Wayland.

Планируемая поддержка

Ubuntu

Canonical, владелец Ubuntu, наняла Сэма Спилсбери, главного разработчика Compiz. Он будет перемещать зависимости от X11 в отдельный плагин. Canonical планирует портировать Compiz на OpenGL ES, что требуется для работы с Wayland.

Fedora

Fedora поставляет Wayland начиная с семнадцатой версии. Разработчик Fedora Маттиас Класен опубликовал в марте план, согласно которому Wayland должен стать оконной системой по умолчанию в Fedora 21. Fedora 20 предоставляет предварительную реализацию GNOME 3.10 на Wayland.

GNOME

В марте разработчики GNOME анонсировали свои планы о полной поддержке Wayland через год. GNOME 3.10 имеет начальную поддержку.

KDE

KWin, оконный менеджер KDE, получил поддержку OpenGL ES в версии 4.7. В январе главный разработчик KWin Мартин Грэсслин начал работать на Blue Systems, где одна из главных его целей добиться полной поддержки Wayland. Экспериментальная поддержка Wayland уже есть в KWin 4.11.

Raspberry Pi

Raspberry Pi Foundation работает совместно с Collabora над улучшением производительности и потребления оперативной памяти, однако не намереваются сменить X11 на Wayland до конца 2013.

Тулкиты

• Clutter полностью поддерживает Wayland.
• полностью поддерживает Wayland.
• GTK+ 3.10 (вышел 23 сентября 2013 года) полностью поддерживает Wayland 1.2, включая декорирование на стороне клиента, требуемое для Weston.
• Qt 5 полностью поддерживает Wayland, включая декорирование на стороне клиента, что требуется для Weston (а не KWin).
• Экспериментальная поддержка Wayland добавлена в SDL в версии 2.0.2.

Testing Wayland

To test Wayland, you will need to have a compatible compositor installed. A Wayland compositor combines the roles of the X window manager, compositing manager and display server. Most major desktops support Wayland well, but for testing purposes, weston is the reference implementation of the concept.

You can test Weston directly from a regular X session simply by installing the weston package and then running weston in a terminal session. This will start a Wayland window in your regular X session where you can test things.

You can also test GNOME’s mutter Wayland compositor directly:

mutter --nested --wayland

Then further Wayland clients will show up in that window. Try, for example, starting gnome-terminal.

Композитор — это необходимость

Композиция — это метод, который помогает предотвратить разрыв экрана и артефакты. Это делается путем сохранения копий вашего дисплея в памяти, обычно с помощью вашей видеокарты. Таким образом, даже если приложения перестают отвечать на запросы, вашему серверу отображения все равно будет с чем работать. Компоновка также обеспечивает анимацию окон и тени.

Wayland разработан, чтобы сделать этот процесс намного более эффективным, чем X, сделав его обязательным. X имеет композитинг в качестве дополнительной функции, через расширение под названием Xcomposite. Но из-за того, как это реализовано, это занимает немного больше времени по сравнению с Wayland.

При этом, композитинг может привести к некоторым проблемам

Композиция приводит к немного более низкой производительности программ, таких как игры. В X большинство рабочих столов выключают композитинг, когда приложение работает в полноэкранном режиме. Но многим Wayland-композиторам все еще нужно это реализовать. Если вы заинтересованы в использовании графически увесистых программ на рабочем столе Wayland, это очень важно иметь в виду

First Pass Snapping: Notes

Why did we step through that process instead of simply presenting the working .yaml?

Because snapping applications can reveal lots of hard-coded paths and assumptions that applications make, which snap confinement will break. It is good to understand the steps needed to debug and solve these problems.

There can be many, many environment variables and support files that need to be set up inside snaps, for applications to run correctly. Thankfully much of this work has already been done and automated in the snapcraft-desktop-helpers project, which we will be using in a follow-up tutorial.