Honza's Blog

Moving to Sway

  • Mar 26, 2019

Již je to pár let, co jsem poprvé pocítil sílu dlaždicového window manager, konkrétně i3. Žel bohu, kvůli nedostatku času a zkušeností, jsem nebyl s to systém (kde na pozadí běžel Arch Linux) pořádně ukočírovat. Byl jsem tak nucen na čas přejít na kombinaci Gnome/Fedora. V této konfiguraci jsem setrval bezmála dva roky. Po celou dobu jsem však cítil touhu návratu k Arch Linux a i3. Nechtěl jsem však svůj návrat uspěchat a spíše vše do detailu pochopit. Proto jsem nejdříve zvolil kombinaci Gnome/Arch, na které jsem strávil půl roku. Následně jsem se rozhodl vyměnit i Gnome. Jenže to jsem ještě netušil, jakou proměnou si linuxový svět za těch pár let prošel. Jednou z nejvýraznějších změn je vydání stabilní verze nového display server protocol Wayland. i3 není (a nikdy ani nebude) připraven bežet na Wayland. Proto započaly práce na nový projektu s názvem Sway, který má být Wayland alternativou právě k i3. A právě přechodu z GNOME na Sway bude pojednávat tento článek.

Na tomto místě bych rád poděkoval Jakubovi Jančičkovi, přezdívanému též Kočička, za korekturu textu a zajimavé podměty na obohacení textu.

Ukázka Sway.

Přednáška na InstallFest 2020

Základní komponenty GUI na OS Linux

Tato kapitola se v původním textu nenacházela, avšak na přání korektora byla dodatečně přidána. Má zacíl seznámit čtenáře se základnímy principy fungovaní GUI na OS Linux. Poznamenejme ale, že problematika okolo display server protocol je podstatně složitější a mnohonásobně přesahuje znalosti autora. Proto prosím omluvte případné nepřesnosti v terminologii, popřípadě hrubé zjednodušení daného tématu.

Základním stavebním kamenem GUI je display server protocol, který slouží ke komunikaci mezi grafickým rozhraním aplikace a display server. Display server se pak stará o komunikaci s jednotlivými moduly v Linux kernel. Namátkou zmiňme například:

Základní komponenty [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface)

Pro lepší názornost uveďme jeden z typických příkladů putování signálu. Uživatel pomocí vstupního zařizení (například myši) klikne na tlačítko aplikace. Signál z myši je zachycen a zpracován v modulu evdev a je následně delegován do display server. Ten se na základě informací o rozložení oken rozhodne delegovat signál dále do konkrétní aplikace. Aplikace tak přijme signál, že bylo kliknuto na konkrétní tlačítko. Změní svůj stav, popřípadě i vyšle zpáteční signál s požadavkem o nové vyrendrování zpět do display server.

Po dlouhou dobu platil za standard protokol X Window System (také známý pod názvem X11), který na pozadí komunikuje s display server X.Org Server. Na diagramu níže vidíme, jak X.Org Server komunikuje se svými klienty. Všimněme si, že na rozdíl od jeho následníka, o kterém bude řeč za malý okamžik, striktně odděluje modul nazvaný Window manager. Jak již název napovídá, Window manager se stará o správu a rozložení jednotlivých oken aplikací. No a právě i3 je jednou z možných implementací Window manageru.

Ukázka X.Org Server komunikace, zdroj [wikipedia](https://en.wikipedia.org/wiki/Display_server#/media/File:X11_display_server_protocol.svg)

Na podzim roku 2008 se však skupina programátorů v čele s Kristian Høgsberg rozhodla vytvořit protokol nový. Pro pochopení takového kroku uveďme následující citaci:

What’s different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango, etc.), and there is very little left that has to happen in a central server process. …​ [An X server has] a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. …​ This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!), and the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we’ve been able to keep the X.org server modern by adding extension such as XRandR, XRender and COMPOSITE …​ With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we’ll never get there if [we] don’t plan for it.

— Kristian Høgsberg zdroj wikipedia

Nový protokol nazvali Wayland a jeho ukázkovou komunikaci můžeme vidět na dalším diagramu. Zmiňme tedy alespoň seznam hlavních změn oproti protokolu X11:

  • Organizace - došlo k výraznému zjednodušení a mnohdy dokonce i k úplnému odstranení některých funkcionalit. Zvýšila se tak přehlednost kódu a usnadnila budoucí modifikace.
  • Architektura - došlo ke sloučení Window serveru a samotného Display serveru.
  • Rendering - v X11 provádí rendering samotný X server. Na druhou stranu Wayland deleguje práci na jednotlivé své klienty.
  • Bezpečnost - Wayland striktně odděluje vstupní a výstupním komunikaci mezi jednotlivými klienty. V současné době tak například není možné sdílení plochy pomocí třetí aplikace (ať už přímo systémovou aplikací například v GNOME, nebo internetovým prohlížečem). Došlo tak k výraznému navýšení bezpečnosti. Explanation Každý display server který implementuje protokol Wayland se nazývá Wayland compositor. Display server Weston, je pak jeho ukázkovou implementací. Mezi další Wayland compositor se řadí právě Sway.

Přechod na Wayland je však postupný. Důvodů, proč někteří uživatelé nedají na stará dobrá Xka dopustit, je několik. Jmenujme například počáteční nestabilita celého protokolu, hlavně v prvopočátcích vývoje. Dalším důvodem může být z počátku velmi malá podpora Wayland protokolu napříč aplikacemi. Dnes již však máme několik let od vydání první stabilní verze a například Fedora již Wayland používá jako výchozí display server protokol.

Kompatibilita aplikací s novým protokolem byla (a bohužel stále je) jedním ze hlavních kamenů úrazu. Pro zpětnou kompatibilitu tak byl vytvořen patch XWayland, který umožňuje aplikací využívající protokolu X11, běžet na protokolu Wayland (odtud název XWayland). Zdůrazněme, že se jedná pouze o provizorní řešení, které sice umožňuje běh X11 aplikací na Waylandu, ale ani zdaleka nevyužívá všechny jeho možnosti. Jedním z nedostatků tohoto řešení je problém spjatý s High Dots Per Inch display, zkráceně HiDPI display. O tomto problému si více povíme v pozdější kapitole.

Ukázka Wayland komunikace, zdroj [wikipedia](https://en.wikipedia.org/wiki/Display_server#/media/File:Wayland_display_server_protocol.svg)

Instalace a první kroky

Kompletní konfigurační soubory lze naléze v repozitáři Dotfiles.

Jak již bylo řečeno, na Sway jsem přecházel z GNOME, proto jsem jako display manager použil GDM. Následná instalace je pak snadná:

pacman -S sway

Výchozí nastavení pro Sway nalezneme v souboru /etc/sway/config. Před prvním spuštění Sway doporučuji řádně prostudovat právě toto nastavení, abyste se vyvarovali prvotnímu šoku. 😊

Rozložení klávesnice

V dřívějších verzích Sway bylo nutné vždy nastavit proměnné prostředí s daným rozloženým klávesnice, a to ještě před startem Sway. Tomuto přístupu již naštěstí odzvonilo, a tak můžeme nastavit rozložení klávesnice jednoduše spolu s nastavením Sway.

Jméno vstupního zařízení můžeme najít pomocí příkazu swaymsg -t get_inputs.

~/.config/sway/config

input 1:1:AT_Translated_Set_2_keyboard {
    xkb_layout us,cz(qwerty)
    xkb_options grp:win_space_toggle,caps:swapescape
}

Systémové nástroje

Sway je opravdu jen a pouze Wayland compositor, a proto je nutné doinstalovat spoustu systémových nástrojů, od lock manager začínaje a po ovládání hlasitosti konče. Nepřekvapivě, lze většinu z níže popsaných nástrojů nainstalovat pomocí pacman, a co nenajde pacman najde yay (ať žije AUR).

swaylock - Lock manager

Jak již název napovídá, lock manager je nástroj starající se o uzamykání PC. Nic víc, nic míň. Přijemným zjištěním pro mě bylo, že na rozdíl od různých lock managerů pro i3, funguje bezproblémově i při uspávání PC. Dříve se totiž stávalo, že se PC po probuzení načetl a pak teprve uzavřel, takže bylo někdy krátce (někdy déle) vidět, na čem uživatel právě pracuje.

~/.config/sway/config

set $lock_command 'swaylock -f -i ~/pictures/milky_way.jpg'

Od doby prvního vydání uplynolu již mnoho času a tak se komunita uživatelů postarala o nemalé množství různých verzí. Za zníňku stojí například swaylock-effects, který umí zobrazovat čas na zamčené obrazovce nebo vždy před uzavřením PC udělat screenshot a provést rozmazání obrazu. Takto znetvořená fotka se pak použije jako pozadí pro uzamykací obrazovku.

~/.config/sway/config

set $lock_command 'swaylock -f --screenshots --show-keyboard-layout --clock --indicator --indicator-radius 100 --indicator-thickness 7 --effect-blur 10x7'

swayidle - Idle manager

Chceme-li (a to vážně chceme), aby se PC automaticky při nečinnosti uzamklo, můžeme využívat swayidle. Konfigurace je ve skrze prostá:

~/.config/sway/config

exec swayidle -w \
             timeout 300  $lock_command \
             timeout 600 'swaymsg "output * dpms off"' \
                  resume 'swaymsg "output * dpms on"' \
             before-sleep $lock_command

swayidle uzavře PC i v případě, že je aktivní fullscreen mode. To může být (je) velmi otravné, obzvláště při sledování filmů a seriálů. Jedno z řešeních je pozdržet uzavření počítače pro určité aplikace v určitém módu, konkrétně:

~/.config/sway/config

for_window [app_id="firefox"] inhibit_idle fullscreen

Alternativně lze využít Idle Inhibitor Module lišty Waybar.

swaybg - Background

Od verze 1.1 byla správa nastavení pozadí plochy vyčleněna do samostaného programu swaybg.

~/.config/sway/config

exec swaybg --image ~/Pictures/f29.png --mode fill

waybar - Alternative Sway bar

Výchozí lišta sway je prakticky totožná s lištou, kterou známe z i3. Je zde však možnost přejít k alternativní, modulární a široce konfigurovatelné liště waybar. Veškeré nastavení nalezneme v adresáři ~/.config/waybar.

Ukázka Waybar.

Za zmínku stojí modul Idle Inhibitor, který zabrání swayidle v uzamknutí obrazovky.

V utilitce waybar doposud chybí modul pro zobrazování aktuálního rozložení klávesnice. Ten je možno dopsat manuálně.

~/.config/waybar/modules/kblayout:

#!/bin/bash
# See: https://github.com/Alexays/Waybar/pull/85

swaymsg -t get_inputs | jq -r \
    "first(.[]|select(.identifier == \"$1\" and .type == \"keyboard\")) \
    | .xkb_active_layout_name \
    | .[0:2] \
    | ascii_upcase"

swaymsg -mrt subscribe '["input"]' | jq -r --unbuffered \
    "select(.change == \"xkb_layout\")
    | .input
    | select(.identifier == \"$1\" and .type == \"keyboard\") \
    | .xkb_active_layout_name \
    | .[0:2] \
    | ascii_upcase"

~/.config/waybar/config:

...
    "custom/layout": {
        "format": " {}   ",
        "exec": "~/.config/waybar/modules/kblayout '1:1:AT_Translated_Set_2_keyboard'",
        "tooltip": false
    },
    "custom/layout_ext": {
        "format": " {}   ",
        "exec": "~/.config/waybar/modules/kblayout '1133:8208:Logitech_K800'",
        "exec-if": "swaymsg -t get_inputs | grep '1133:8208:Logitech_K800'",
        "tooltip": false
    }
...

Všimněme si, že každá připojená klávesnice může mít (má) vlastní rozložení klávesnice.

wl-clipboard - Clipboard manager

Pro správu systémové schránky z terminálu slouží utilita wl-clipboard. Tu navíc podporuje i projekt NeoVim, takže registry + a * fungují out of the box.

grim - Screenshot capture

Na zachycení obrazovky slouží utilita grim. Toto může být jedno z jejích použití:

~/.config/sway/config

bindsym Print exec bash -c "grim \"/home/juhlik/Pictures/Screenshot-$(date +%s).png\""

Vše lze elegantně zabalit do skriptu, který bude volán klávesou Print Screen. Více informací lze vyčíst z Dotfiles.

wf-recorder - Screen recorder

Pro natáčení obrazovky pak slouží utilita wf-recorder.

Sway aktuálně nepodporuje screen mirror. Pro prezentování lze v některých případech využít kombinaci pdfpc a tmux. Pokud je z nějakého důvodu (příkladem budiž seminář právě o Sway) toto řešení nedostatečné, lze využít wf-recorder spolu s Kernel modulem v4l2loopback. Ukázkové použití lze najít v Dotfiles.

slurp - Select a region

Nedílnou součástí grim a wf-recorder je pak slurp, který uživately dovolí zvolit geometrii zachycované obrazovky. Například:

grim -g "$(slurp)" screenshot.png

kanshi - Dynamic display configuration

Nástroj pro automatickou detekci připojeného monitoru. Syntaxe konfigurace je pak podobná jako pro sway. Soubor se při detekci změny prochází od shora dolů a aplikuje se první nastavení, které se shoduje s detekovanou konfigurací.

~/.config/kanshi/config

{
  output "Chimei Innolux Corporation 0x14F2 0x00000000" position 3000,1520 mode 1920x1080 scale 1.1
  output "Eizo Nanao Corporation EV2455 0x0000FF02" position 1080,1500 mode 1920x1200
  output "Acer Technologies H223HQ LF70D0028500" position 0,1080 mode 1920x1080 transform 270
}
{
  output eDP-1 mode 1920x1080 scale 1.1
}

mako - Notification daemon

mako je wayland alternativou k dunst. Je to jednoduchý notifikační daemon, který zobrazuje notifikace jednotlivých procesů. Jeho zpuštění je jednoduché:

~/.config/sway/config

exec mako

Nastavení je rovněž jednoduché modifikací souboru ~/.config/mako/config:

background-color=#0f1f26
border-color=#2B83A6
default-timeout=5000

Ukázka notifikace.

Pro rychlé testování notifikací může posloužit příkaz notify-send:

$ notify-send HELP 'I need somebody'

wshowkeys - Displays keypresses on screen

Pro prezentační účely se jistě hodí utilita wshowkeys, která zobrazuje právě stisknuté znaky na display. Zatím se mi ale nepovedlo správě zprovoznit.

$ wshowkeys -t 1 -a bottom -a left

Application launcher

S application launcher je to na Sway složitější. Zatímco u i3 můžeme sáhnout po dmenu nebo rofi, pokud chceme čistě Wayland řešení musíme si vypomoci fzf. Hotové řešení je k nalezení na Michel/my-scripts a jeho volání pak vypadá následovně.

~/.config/sway/config

bindsym $mod+d exec termite --name=launcher -e /home/juhlik/.scripts/sway-launcher.sh
    for_window [app_id="^launcher$"] floating enable

Ukázka application launcher.

Zazmíňku stojí také wofi, za kterým stojí jeden z hlavních vývojářů Sway.

alacritty - Terminal emulator

Zeptáte-li se 100 linuxáků na jejich používaný terminálový emulátor, dostanete 100 různých odpovědí. Mou bude alacritty. Jedná se o emulátor doporučený vývojáři Sway, který na rozdíl od většiny ostatních emulátorů má i GPU-akceleraci. Konfigurační soubor můžeš jako vždy najít na ~/.config/alacritty/alacritty.yml.

light - Control for brightness

Pracujeme-li na laptopu, můžeme pro správu hladiny podsvícení využít nástroj light. Jeho použití je velmi snadné:

~/.config/sway/config

bindsym XF86MonBrightnessDown exec light -U 5
bindsym XF86MonBrightnessUp exec light -A 5

pulseaudio a pavucontrol - Sound manager

Jako sound server můžeme využít například pulseaudio. Pro regulaci hlasitosti pak můžeme využít příkaz pulsemixer --change-volume +5, popřípadě pulsemixer --toggle-mute.

Pro správné fungování zvukového modulu ve waybar je nutné nainstalovat rovněž balíček pavucontrol.

Povšimněme si, že v Dotfiles je mnohem obsáhlejší script na ovládání zvukových výstupů.

redshift - Adjusts the color temperature

redshift je nástroj pro úpravu barvy obrazovky. Typické použití je snížení hladiny modrého světla ve večerních hodinách. Člověku pak méně bolí oči a lépe se mu usíná (pozor subjektivní názor!). Pro instalaci je nutné zvolit verzi z AUR konkrétně redshift-wlr-gamma-control-git.

Spuštění je pak možné pomocí příkazu redshift -l LATITUDE:LONGITUDE. Pokud nechceme zadávat souřadnice ručně, můžeme využít geoclue2. V takovém případě je nutná modifikace souboru /etc/geoclue/geoclue.conf a následný restart služby redshift.service.

tc/geoclue/geoclue.conf

[redshift]
allowed=true
system=false
users=

~/.config/sway/config

exec redshif

Zrcadlení obrazovky

Výhody, které dlaždicové prostředí přináší, se naplno ukáží při zapojení práci s více monitory. Jednoduchost prohazování otevřených oken, či celých ploch mezi monitory je prostě ohromující. Zde nelze zážitek předat písemnou formou a musí se vyzkoušet na vlastní prsty.

Jak již bylo několikrát řečeno, projekt Sway je mladý a ne vše se stihlo doposud naimplementovat. O jednom takovém nedostatku horoří Output mirroring issue #1666.

Jedno z možných řešení tohoto problému může být kombinace tmux spolu s pdfpc.

Někdy se ale bez zrcadlení neobejdeme (jako například u prezentace o Sway) a tehdy musí příjít na řadu důmyslnější trik. Využijeme kernel modulu v4l2loopback-dkms a budeme nahrávat požadovanou obrazovku pomocí wf-recorder a následně pořízený obraz přehrávat například pomocí FFplay.

Vše lze elegantně zabalit do skriptu, který bude volán klávesovou zkratkou. Více informací lze vyčíst z Dotfiles.

Modul do jádra můžeme přidat presistentně a to vytvořením souboru: /etc/modprobe.d/v4l2loopback.conf obsahující options v4l2loopback video_nr=8.

Prokletí HiDPI

Po velmi dlouhou dobu panovalo přesvědčení (alespoň tedy na straně výrobců monitorů), že FullHD rozlišení (1920x1080), je plně dostateční a není tak důvod jej z budoucnosti u domácích monitorů zvyšovat. Díky Bohu, že jsou tyto názory již dnes passé. Bežně se tak již můžeme setkat s rozlišením QHD (2560x1440) či dokonce 4K UHD (3840 × 2160). Těmto obrazovkám s vysokým rozlišením se v počítačovém žargonu říká High Dots Per Inch.

S náhlým příchodem HiDPI obrazovek však nastal, který jen málo kdo očekával. Stávající aplikace, potažmo display servery nebyly připraveny na překročení oné hranice 1920x1080. Nezřídka se stávalo (a s velkým zármutkem v srdci nutno přiznat, že doposud stává), že nekompatibilní aplikace byly buďto rozmazané (což je přesný opak toho, co měly obrazovky s vyšším rozlišením přinést), nebo obsah v nich "nesmyslně" malý a text prakticky nečitelný.

Aby došlo k nápravě tohoto problému, byla nutná modifikace jak na straně display serverů, tak na straně jednotlivých aplikací. A zde se obloukem vracíme k našemu počátečnímu povídá o GUI na OS Linux. Jak již bylo uvedeno Wayland přenechal odpovědnost za renderování na svých klientech, kdežto X11 je renderuje v samotném serveru. Proto přístup jak řešit problém s HiDPI je pro každý z těch serverů odlišný. To by nebyl až tak zásadní problém, kdyby všechny aplikace plně podporovali jak X11, tak Wayland. Bohužel tomu tak není. A XWayland tento problém sám o sobě nedokáže vyřešit.

V některých případech se místo neostrého zobrazení setkáváme s jiným problémem. Pokud pracujeme s více monitory, kde každý z monitorů má míti jiný škálovací faktor, stává se, že co je na jednom monitoru zobrazeno v normální velikosti, je na druhém buď enormě malé, nebo naopak enormě velké (v obojím případě nepoužitelné).

Někteří můžou namítnout, že některé aplikace běžící na kombinaci GNOME/Wayland, příkladem budiž GNOME Files, tento problém nemají. To je díky speciální implementaci GNOME, který tak vlastně zastupuje a přebírá práci, kterou má dělat samotný Wayland client. Autoři Sway se k tomuto přístupu vyhradili a neplánují jej do Sway implementovat.

Vlevo je Firefox v66.0.2 využívající protokol Wayland, vpravo je pak Chromium 73.0.3683.86 běžící na XWaylandu.

No a jaké je tedy řešení? Žádné…​ ☹️ Jedinou možností je čekat, až vyvojáři dané aplikace implementují plnou podporu protokolu Wayland. V drtivé většině případů, je nutný přechod na novější verzi GKT nebo QT.

V některých případech se stává, že aplikace podporuje jak X11, tak Wayland, ale ve výchozím nastavení je upřednostněno použití X11 (tedy XWayland). Je možné vynutit využití jednoho či oného protokolu modifikací proměnné prostředí GDK_BACKEND=wayland, popřípadě GDK_BACKEND=x11. Pokud ovšem vynutíme použití protokolu Wayland a aplikace jej nepodporuje, aplikace skončí s chybou. Proto nedoporučuji nastavovat GDK_BACKEND globálně, před spuštěním Sway.

Nejpalčivější problém, se kterým jsem se při přechodu setkal, byl s internetovým prohlížečem. Prakticky žádný Wayland doposud nepodporuje. První vlaštovkou budiž Firefox od verze 66, přičemž od verze 67 je již podpora relativně stabilní. Výchozí používaný protokol pro Firefox je opět X11. To můžeme změnit proměnnou GDK_BACKEND=wayland, nebo ještě lépe proměnnou MOZ_ENABLE_WAYLAND=1, která ovlivní pouze samotný Firefox.

Pokud potřebujete vždy před spuštěním Sway nastavit globální proměnnou prostředí, není nic snažšího než využít environment.d a modifikovat adresář ~/.config/environment.d/.

Zde uvádím alespoň krátký výčet aplikací, které doposud nemají nativní podporu protokolu Wayland:

  • Chromuim

  • JetBrains IDEs již fungují pouze je potřeba před spuštěním nastavit proměnné prostředí

export GDK_BACKEND=X11
export _JAVA_AWT_WM_NONREPARENTING=1
  • Inkskape je funkční od verze 1.

Odkazy

Závěr

Po několika letech čekání jsme se konečně dočkali první stabilní verze Sway. A i přes popsané problémy s HiDPI se jedná o funkčním a hlavně použitelnou alternativu k jiným uživatelským prostředím. Upřímně jsem byl až zaskočen, jak bezproblémový přechod to byl. Mnoho z výše popsaných aplikací stačí pouze nainstalovat a ony v základním nastavení dělají přesně to, co se od nich žádá. Na závěr si dovolím malou paralelu:

S dlaždicovým window managerem je to jako s Vimem, pokud se jej jednou okusíte, už není jiné cesty. Marně pak budete v jiném prostředí mačkat kombinaci Alt+Shift+q a dožadovat se zavření toho proklatého okna.

— Já Teď a tady

Change log:

  • Major changes 22/02/2020: Add links, wofi, screenshot and mirror script.
  • Minor changes 01/02/2020: Moved from termite to alacritty.
  • Major changes 15/12/2019: Preparation for SUT.
  • Minor changes 06/06/2019: Add kanshi and swaybg.
  • Minor changes 09/02/2021: Add lecture from IF 2020.
Search