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 sto 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áě 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.

overview
Figure 1. Ukázka Sway.

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:

500
Figure 2. Základní komponenty GUI, zdroj wikipedia.

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 endev 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 Windows 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.

1000
Figure 3. Ukázka X.Org Server komunikace, zdroj wikipedia

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.

Každý display server který implementuje protokol Wayland se nazývá Wayland compositor. Display server Weston, je pak jeho ukázkovou implementací. Mezi další Wyaland 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.

1000
Figure 4. Ukázka Wayland komunikace, zdroj wikipedia

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 yaourt (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.

Pokud máte výkonný PC, můžete si napsat script, který vždy před uzavřením PC udělá screenshot a provede rozmazání. Takto znetvořená fotka se pak použije jako pozadí pro uzamykací obrazovku.

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
set $lock_command 'swaylock -f -i ~/Pictures/milky_way.jpg'
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ů. Alespoň částečné řešení si popíšeme v kapitole Waybar.

wl-clipboard - Clipboard manager

Abychom byli schopni využívat registry + a * v NeoVim, je potřeba nejdříve nainstalovat utilitu wl-clipboard.

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

termite - Terminal

Zeptáte-li se 100 linuxáků na jejich používaný terminál, dostanete 100 různých odpovědí. Mou bude termite.

Pro správné fungování SSH připojení je na vzdáleném systému vždy nutné:

  1. Nastavit export TERM=xterm-color (nejlépe přidáním do ~/.profile)

  2. Přidat termite.terminfo: wget https://raw.githubusercontent.com/thestinger/termite/master/termite.terminfo && tic -x termite.terminfo

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
application launcher
Figure 5. Ukázka application launcher.

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\""

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.

waybar
Figure 6. Ukázka Waybar.

Za zmínku stojí nově přidaná podpora tzn. idle inhibitor, který zabrání swayidle v uzamknutí obrazovky.

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ů.

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
notification
Figure 7. Ukázka notifikace.

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.

/etc/geoclue/geoclue.conf
[redshift]
allowed=true
system=false
users=
~/.config/sway/config
exec redshift

swaybg - Background

Added 06/06/2019. Nastavení pozadí plochy bylo přemístěno z konfiguračního souboru sway do samostaného programu swaybg.

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

kanshi - Dynamic display configuration

Added 09/06/2019. Nástroj pro automatickou detekci připojeného monitoru. Zatím nevyzkoušeno.

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.

hidpi browsers
Figure 8. 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:

  • JetBrains IDEs (PyChar, CLion and others)

  • Chromuim

  • Inskape

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 Win+Shift+q a dožadovat se zavření toho proklatého okna.

— Já
Teď a tady