Can I finally start using Wayland in 2026?

2026-01-04

2026년에는 드디어 Wayland를 사용할 수 있을까?

Wayland는 리눅스에서 그래픽 스택을 구현하기 위한 X 서버(X11, Xorg)의 후계자입니다. Wayland 프로젝트는 사실 2008년에 시작됐습니다. 제가 X11용 i3 타일링 윈도우 매니저를 만든 2009년보다 1년 전이죠. 하지만 지난 18년 동안(!) Wayland는 제 컴퓨터에서 한 번도 제대로 쓸 수 없었습니다. 낡은 소프트웨어에 머물고 싶지 않아 매년 Wayland로 옮겨보려 시도하는데, 이 글에서는 2026년 현재 제가 Wayland로 옮기지 못하는 이유를 정리합니다.

역사적 배경

처음 몇 년 동안 Wayland는 제 컴퓨터에서 실행조차 거의 되지 않았습니다. 운 좋게 뭔가 화면에 뜬다 해도, 데모 컴포지터인 Weston에서 장난감 같은 데모 앱 몇 개를 실행할 수 있는 정도였습니다.

2014년경 GNOME이 Wayland를 지원하기 시작했고, 몇 년 뒤 KDE도 뒤를 이었습니다. Firefox, Chrome, Emacs 같은 주요 애플리케이션들은 Wayland 도입이 훨씬 더뎠고, 아주 최근까지도, 그리고 geeqie처럼 지금도 여전히 실험적인 구현을 별도 플래그나 환경 변수로 직접 활성화해야 했습니다.

안타깝게도 드라이버 지원 상황은 수년간 열악했습니다. 제 8K 모니터를 지원하는 유일한 카드인 nVidia 그래픽 카드에서는 Wayland가 아예 동작하지 않거나, 심한 그래픽 깨짐과 충돌을 일으켰습니다.

2020년대에 들어 더 많은 배포판이 Wayland를 기본으로 전환하거나 심지어 X11 세션을 없애겠다고 발표했고, RHEL은 X 서버에 대한 기여를 점차 줄이고 있습니다.

Asahi Linux(Mac용, 자체 GPU 드라이버를 사용합니다!) 같은 최신 리눅스 배포판은 Wayland를 주력 데스크톱 스택으로 보고 있으며, X11은 최선을 다하는 수준에서만 지원합니다.

그래서 Wayland로 전환해야 한다는 압박은 점점 커지고 있습니다! 이제는 쓸 만할까요? 무엇이 아직 부족할까요?

Wayland 구동하기

하드웨어

테스트는 제 랩 PC로 진행했습니다. 2022년 하이엔드 리눅스 PC에서 조금 업그레이드한 버전입니다.

제 환경에 대한 자세한 설명은 stapelberg uses this: my 2020 desk setup에 정리해 두었습니다.

이 글에서 가장 중요한 것은 제가 Dell 32인치 8K 모니터(해상도: 7680x4320!)를 사용한다는 점이며, 제 경험상 이 모니터는 nVidia 그래픽 카드하고만 호환됩니다(가끔 다른 카드도 시도해 봅니다).

그래서 랩 PC와 메인 PC 모두 nVidia GPU를 탑재하고 있습니다:

랩 PC에는 nVidia GeForce RTX 4070 Ti가 들어 있습니다.
메인 PC에는 nVidia GeForce RTX 3060 Ti가 들어 있습니다.

(제 PC에 왜 더 오래된 카드를 쓰는지 궁금하실 수 있는데, 한 번 충돌이 있었을 때 GPU가 의심되어 4070에서 기존 3060으로 되돌렸기 때문입니다.)

nVidia 드라이버 지원

수년간 nVidia 드라이버는 Wayland에서 전혀 지원되지 않았습니다.

알려진 바에 따르면 nVidia는 Wayland가 사용하던 API 지원을 거부하고 자사의 EGLStreams 방식이 더 우수하다고 주장했습니다. 다행히 nVidia 드라이버 495(2021년 말)에서 GBM(Generic Buffer Manager) 지원이 추가됐습니다.

하지만 GBM 지원이 생긴 뒤에도 많은 Wayland 세션을 시작할 수는 있게 됐지만 제대로 동작하지는 않았습니다. 심각한 그래픽 깨짐과 아티팩트가 나타나 작업을 전혀 할 수 없었습니다.

깨짐 현상을 해결한 것은 explicit sync 지원이었습니다. nVidia 드라이버가 AMD나 Intel처럼 implicit sync를 지원하지 않기 때문에 Wayland(그리고 wlroots와 sway)에 explicit sync 지원이 필요했습니다.

Sway 1.11(2025년 6월)과 wlroots 0.19.0이 explicit sync를 지원하는 첫 버전입니다.

동작하지 않음: 8K 모니터의 TILE 지원

이제 nVidia 드라이버 자체는 Wayland에서 동작하게 됐지만, 안타깝게도 제 환경에서 Wayland를 쓰기에는 여전히 충분하지 않았습니다. 제 Dell UP3218K 모니터는 MST(Multi Stream Transport)와 TILE 지원이 포함된 DisplayPort 1.4 연결 두 개가 필요합니다. 이 조합은 지난 8년 넘게 X11에서는 아무 문제 없이 동작했습니다.

GNOME은 이 모니터를 네이티브 해상도인 7680x4320@60으로 정상적으로 설정하지만, sway에서는 모니터가 잘못해서 두 개의 별도 모니터로 표시됩니다.

이런 동작의 이유는 wlroots가 TILE 속성(2019년의 이슈 #1580)을 지원하지 않기 때문입니다. 다행히 2023년에 기여자 EBADBEEF가 초안 머지 리퀘스트 !4154를 보내 TILE 속성 지원을 추가했습니다.

하지만 TILE 패치를 적용해도 모니터는 여전히 제대로 동작하지 않았습니다. 모니터 오른쪽 절반이 그냥 검게 표시됐습니다. grim으로 스크린샷을 찍으면 전체 화면이 보이므로 출력 문제로 보였습니다. 2025년 8월부터 EBADBEEF와 몇 차례 의견을 주고받았지만(살펴봐 주셔서 감사합니다!), 원인을 찾지 못했습니다.

한 분기가 지난 뒤, 코딩 어시스턴트인 Claude Code(집필 시점 기준 Opus 4.5)로 복잡한 문제를 디버깅한 경험이 좋았기 때문에 다시 한 번 시도해 보기로 했습니다. 이틀에 걸쳐 여러 테스트를 실행하며 문제를 좁혀 나갔고, Claude가 소스 코드(sway, wlroots, Xorg, mesa 등)를 분석하고 제가 직접 실행할 수 있는 테스트 프로그램을 만들도록 했습니다.

결국 Wayland와는 독립적인 최소 재현 프로그램을 만들었고, 이를 통해 SRC_X DRM 속성이 nVidia에서는 동작하지 않지만(예를 들어 Intel에서는 동작합니다!) 그렇다는 것을 보여줄 수 있었습니다. nVidia 포럼에 동영상과 함께 버그 리포트를 올렸고 nVidia 엔지니어가 한 번 살펴봐 주길 바라고 있습니다!

중요한 것은, 이제 버그가 확인됐으니 Claude에게 우회 방법을 구현하도록 했다는 점입니다. 화면의 오른쪽 절반(SRC_X=3840)을 다른 버퍼로 복사한 뒤, 그 버퍼를 SRC_X=0으로 표시하는 방식입니다.

그 패치를 적용하자 드디어 처음으로 8K 모니터에서 Sway를 사용할 수 있게 됐습니다! 🥳

참고로 GNOME이 네이티브 해상도를 성공적으로 설정한다고 해서 GNOME에서 모니터를 쓸 만하다는 뜻은 아닙니다! GNOME은 타일형 디스플레이를 지원하긴 하지만 개별 타일의 업데이트가 동기화되지 않아 화면 중앙에서 심한 티어링이 발생합니다. X11에서 본 어떤 현상보다 훨씬 심합니다. GNOME/mutter 머지 리퀘스트 !4822에서 이 문제가 해결되길 기대하고 있습니다.

소프트웨어: NixOS

2025년 동안 저는 모든 컴퓨터를 NixOS로 전환했습니다. 선언적인 접근 방식 덕분에 이런 테스트를 하기에 정말 좋습니다. 시스템을 이전 버전으로 안정적으로 되돌릴 수 있기 때문입니다.

NixOS 25.11 설치에서 Wayland/sway 세션을 사용할 수 있도록 NixOS 설정 파일(configuration.nix)에 다음 내용을 추가했습니다:

# GDM display manager (can launch both X11/i3 and Wayland/Sway sessions)
services.displayManager.gdm.enable = true;
services.displayManager.gdm.autoSuspend = false;

# enable GNOME (for testing)
services.desktopManager.gnome.enable = true;

programs.sway = {
  enable = true;
  wrapperFeatures.gtk = true;
  extraOptions = [ "--unsupported-gpu" ];
};

또한 environment.systemPackages에 Wayland 관련 프로그램들을 추가로 넣었습니다:

environment.systemPackages = with pkgs; [
  # …
  foot          # terminal emulator
  wtype         # replacement for xdotool type
  fuzzel        # fuzzy matching program starter
  wayland-utils # for wayland-info(1)
  gammastep     # redshift replacement
];

이 설정을 활성화하면 실행 중인 X11 세션이 있을 경우 종료된다는 점에 유의해야 합니다.

확실하게 하기 위해 설정을 변경한 뒤 전체 시스템을 재부팅했습니다.

실험 결과

이 설정으로 Wayland 세션에서 하루 종일 작업해 보았습니다. 실제로 일을 해보려 하면 가벼운 테스트에서는 드러나지 않는 문제들이 드러납니다. 하루 대부분을 Wayland 문제를 고치는 데 썼습니다 😅. 아래 섹션에서는 제가 배우고 관찰한 내용을 설명합니다.

데스크톱: i3 → sway

수년 전 Wayland가 더 널리 알려졌을 때, 사람들이 i3 이슈 트래커에 i3를 Wayland로 포팅할 계획이 있느냐고 물었습니다. 저는 아니라고 답했습니다. 제 컴퓨터 어디에서도 실행조차 되지 않는 환경으로 어떻게 프로그램을 포팅할 수 있겠습니까? 또, 전업으로 일하고 있었기 때문에 얼리어답터가 되어 Wayland 개발에 영향을 줄 시간도 없다는 것을 알고 있었습니다.

이런 입장이 계기가 되어 Drew DeVault가 2016년경 Sway 프로젝트를 시작했습니다. Sway는 i3의 Wayland 버전을 지향합니다. 저는 Sway를 경쟁자로 보지 않습니다. 오히려 사람들이 i3 프로젝트를 그토록 좋아해서 다른 환경을 위해 비슷한 프로그램을 만드는 수고까지 마다하지 않았다는 사실이 놀랍고 멋지게 느껴졌습니다! 정말 기분 좋은 칭찬이죠! 😊

Sway는 i3 설정 파일과 호환되는 것을 목표로 하며, 실제로 대부분 호환됩니다.

궁금하신 분들을 위해 Sway 기본값에서 제가 변경한 내용을 공유합니다. 주로 제가 사용하는 NEO 키보드 레이아웃에 맞춰 키 바인딩을 옮기고, 예전에는 제 ~/.xsession 파일에서 설정하던 input/output 블록을 구성한 것입니다:

Sway 기본 설정에서 변경한 내용

--- /home/michael/src/sway/config.in	2025-09-24 19:08:38.876573260 +0200
+++ /home/michael/.config/sway/config	2025-12-31 15:50:38.616697542 +0100
@@ -9,19 +9,76 @@
 # Logo key. Use Mod1 for Alt.
 set $mod Mod4
 # Home row direction keys, like vim
-set $left h
-set $down j
-set $up k
-set $right l
+set $left n
+set $down r
+set $up t
+set $right d
 # Your preferred terminal emulator
 set $term foot
 # Your preferred application launcher
-set $menu wmenu-run
+set $menu fuzzel
+
+font pango:Bitstream Vera Sans Mono 8
+
+titlebar_padding 4 2
+
+# Make Xwayland windows recognizeable:
+for_window [shell="xwayland"] title_format "%title [Xwayland]"
+
+workspace_layout stacking
+
+# Open two terminal windows side-by-side on new workspaces:
+# https://github.com/stapelberg/workspace-populate-for-i3
+exec ~/go/bin/workspace-populate-for-i3
+
+exec gammastep -l 47.31:8.50 -b 0.9
+
+input * {
+   xkb_layout "de"
+   xkb_variant "neo"
	repeat_delay 250
	repeat_rate 30
+}
+
+input * {
+	accel_profile adaptive
+	pointer_accel 0.2
+}
 
 ### Output configuration
 #
-# Default wallpaper (more resolutions are available in @datadir@/backgrounds/sway/)
-output * bg @datadir@/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill
+output * bg /dev/null fill #333333
+output * scale 3
 #
 # Example configuration:
 #
@@ -33,14 +90,41 @@
 #
 # Example configuration:
 #
-# exec swayidle -w \
-#          timeout 300 'swaylock -f -c 000000' \
-#          timeout 600 'swaymsg "output * power off"' resume 'swaymsg "output * power on"' \
-#          before-sleep 'swaylock -f -c 000000'
+exec swayidle -w \
+         before-sleep '~/swaylock.sh' \
+         lock '~/swaylock.sh'
 #
 # This will lock your screen after 300 seconds of inactivity, then turn off
 # your displays after another 300 seconds, and turn your screens back on when
 # resumed. It will also lock your screen before your computer goes to sleep.
+bindsym $mod+l exec loginctl lock-session
+
+  # Notifications
+  bindsym $mod+period exec dunstctl close
 
 ### Input configuration
 #
@@ -63,11 +147,13 @@
     # Start a terminal
     bindsym $mod+Return exec $term
 
     # Kill focused window
-    bindsym $mod+Shift+q kill
+    bindsym $mod+Shift+x kill
 
     # Start your launcher
-    bindsym $mod+d exec $menu
+    bindsym $mod+a exec $menu
 
     # Drag floating windows by holding down $mod and left mouse button.
     # Resize them with right mouse button + $mod.
@@ -142,12 +228,11 @@
     bindsym $mod+v splitv
 
     # Switch the current container between different layout styles
-    bindsym $mod+s layout stacking
+    bindsym $mod+i layout stacking
     bindsym $mod+w layout tabbed
-    bindsym $mod+e layout toggle split
 
     # Make the current focus fullscreen
-    bindsym $mod+f fullscreen
+    bindsym $mod+e fullscreen
 
     # Toggle the current focus between tiling and floating mode
     bindsym $mod+Shift+space floating toggle
@@ -156,7 +241,7 @@
     bindsym $mod+space focus mode_toggle
 
     # Move focus to the parent container
-    bindsym $mod+a focus parent
+    bindsym $mod+u focus parent
 #
 # Scratchpad:
 #
@@ -192,37 +277,25 @@
     bindsym Return mode "default"
     bindsym Escape mode "default"
 }
-bindsym $mod+r mode "resize"
+#bindsym $mod+r mode "resize"
 
 #
 # Status Bar:
 #
 # Read `man 5 sway-bar` for more information about this section.
 bar {
-    position top
 
     # When the status_command prints a new line to stdout, swaybar updates.
     # The default just shows the current date and time.
-    status_command while date +'%Y-%m-%d %X'; do sleep 1; done
+    status_command i3status
 }

Sway에서 다음과 같은 문제들을 겪었습니다:

이전과 동일한 libinput 설정을 어떻게 해야 하는지 모르겠습니다. X11에서 사용하던 설정은 xinput-list-props-mx-ergo.txt를 참고해 주세요. Sway에서 제공하는 accel_profile 설정은 제가 이전에 사용하던 것과 일치하지 않는 것 같습니다.
마우스 커서/포인터가 왠지 버벅거리는 느낌이 듭니다?! 트랙볼을 움직였을 때 반응이 더 느리게 오는 것 같고, 화면에서 움직임도 덜 부드럽습니다.
Simon Ser는 현재 nVidia 드라이버에서 하드웨어 커서 지원이 동작하지 않기 때문일 수 있다고 추측합니다.
Xwayland 스케일링 미지원: Xwayland를 통해 실행된 프로그램은 흐릿하게(기본값) 보이거나 이중 스케일링됩니다(Xft.dpi: 288 설정 시). 이는 Sway 특유의 제약입니다. KDE는 2022년에 이 문제를 수정했습니다. Sway 이슈 #2966을 보면 Sway 개발자들은 왠지 이 방식을 선호하지 않는 것 같지만, 제 입장에서는 매우 아쉽습니다. Xwayland로 오래된 프로그램을 실행하는 하위 호환 옵션이 사실상 제게는 쓸모가 없기 때문입니다.
가끔 키보드 단축키가 두 번 실행되는 것처럼 보입니다! 예를 들어 스택에 쌓인 다섯 개의 Chrome 창 중 첫 번째에 포커스를 두고 그 창을 다른 워크스페이스로 옮기면, 한 개가 아니라 두 개의 창이 옮겨집니다. 다음과 같은 메시지도 보입니다(단축키 중복 문제와 정확히 연관은 없지만):
```
[ERROR] [wlr] [libinput] event0  - https: kinT (kint36): client bug: event processing lagging behind by 32ms, your system is too slow
```
…그런데 이건 좀 이상합니다. 제 하이엔드 리눅스 PC가 절대 느린 사양이 아니기 때문입니다.

GTK: 글꼴 크기

GIMP나 Emacs 같은 GTK 프로그램을 처음 실행했을 때 모든 글꼴이 너무 크게 표시되는 것을 발견했습니다! 아직 초기화해야 할 스케일링 관련 설정이 남아 있었던 것입니다:

gsettings reset org.gnome.desktop.interface scaling-factor
gsettings reset org.gnome.desktop.interface text-scaling-factor

디버깅 팁: dconf dump / 명령으로 GNOME 설정을 확인할 수 있습니다(~/.config/dconf에 저장됩니다).

GTK: 백엔드

geeqie 같은 일부 프로그램은 명시적으로 export GDK_BACKEND=wayland 환경 변수를 지정해야 하는 것 같습니다. 그렇지 않으면 Xwayland로 실행됩니다. 이상하네요.

글꼴 렌더링

X11과 Wayland 사이에 글꼴 렌더링이 다르다는 것도 알게 됐습니다! 예를 들어 Chrome 브라우저의 탭 제목과 주소 표시줄에서 차이가 보입니다:

처음에는 Wayland가 기본적으로 다른 font-antialiasing과 font-hinting 설정을 쓰는 것인가 생각해 다음 설정(기본값은 font-antialiasing=grayscale, font-hinting=slight)으로 여러 가지 실험을 해봤지만, 예전처럼 렌더링되도록 만들 수는 없었습니다:

gsettings set org.gnome.desktop.interface font-antialiasing 'rgba'
gsettings set org.gnome.desktop.interface font-hinting 'full'

업데이트: Wayland에서는 GTK3가 ~/.config/gtk-3.0/settings.ini 설정 파일을 무시하고 dconf만 사용한다는 점을 알려주신 Hugo님께 감사드립니다! 다음 dconf 설정을 지정하자 글꼴 렌더링이 일치하게 됐습니다:

gsettings set org.gnome.desktop.interface font-name 'Cantarell 11'

화면 잠금: swaylock

가장 당연한 i3lock 대체제는 swaylock입니다.

두 프로그램의 구조 차이를 금방 마주하게 됐습니다:

i3lock은 화면 잠금 창을 보여줍니다. i3lock을 종료하면 화면 잠금이 해제됩니다.
swaylock을 종료하면 Red Screen Of Death 상태가 됩니다.
이 상태에서 벗어나려면 swaylock을 다시 시작해 잠금을 해제해야 합니다. 명령줄에서 swaylock 프로세스에 SIGUSR1을 보내 잠금을 해제할 수도 있습니다.

이 동작은 매우 놀라웠지만, (Wayland) 설계상 의도된 것입니다! 자세한 내용은 Sway 이슈 #7046을 참고하세요. 그리고 ext-session-lock-v1 Wayland 프로토콜의 다음 인용을 보세요:

“컴포지터는 렌더링을 중단하고 일반 클라이언트에 입력을 제공해서는 안 됩니다. 대신 컴포지터는 모든 출력을 불투명한 색상으로 비워 일반적인 내용이 완전히 가려지도록 해야 합니다.”

그러니 테스트용으로 SSH를 통해 swaylock을 시작할 때는 Ctrl+C로 그냥 취소하지 말고 반드시 잠금을 해제해야 한다는 점을 기억하세요. 그리고 절대 충돌하지 않기를 바라야 합니다.

예전에는 모니터를 끄는(입력 시 다시 켜지는) 래퍼 스크립트로 i3lock을 실행했습니다:

#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.

revert() {
    xset dpms 0 0 0
    pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM
xset +dpms dpms 15 15 15
(sleep 1 && xset dpms force off) &
pactl set-sink-mute @DEFAULT_SINK@ 1
i3lock --raw 3840x2160:rgb --image ~/i3lock-wallpaper-3840x2160.rgb -n 
revert

Wayland에서는 DPMS 동작을 swayidle로 다르게 구현해야 합니다:

#!/bin/sh
# Turns on DPMS, mutes all output, locks the screen.
# Reverts all settings on unlock, or when killed.

swayidle -w \
  timeout 5 'swaymsg "output * dpms off"' \
  resume 'swaymsg "output * dpms on"' &
swayidle=$!

revert() {
    kill $swayidle
    pactl set-sink-mute @DEFAULT_SINK@ 0
}
trap revert SIGHUP SIGINT SIGTERM

pactl set-sink-mute @DEFAULT_SINK@ 1
swaylock --image ~/i3lock-wallpaper-3840x2160.jpg
revert

i3 IPC 자동화

i3 윈도우 매니저는 IPC 인터페이스(프로세스 간 통신)를 통해 확장할 수 있습니다.

저는 이 인터페이스를 사용하는 작은 도구 몇 개를 사용합니다.

Sway에서 이 도구들을 사용할 때 다음과 같은 문제들을 발견했습니다:

go.i3wm.org/i3/v4 Go 패키지를 사용하는 도구는 현재 특수 소켓 경로 훅이 필요합니다. 전환을 쉽게 하려면 패키지에서 투명하게 처리하도록 포함하는 것이 좋을 것 같습니다.
Sway 설정에서 exec로 시작한 도구가 Sway를 종료(swaymsg exit)하고 새 세션에 로그인한 뒤에도 예상과 달리 계속 실행됩니다!
제 workspace-populate-for-i3가 동작하지 않았습니다:
- Sway는 i3의 레이아웃 저장/복원을 구현하지 않습니다. Drew가 2017년에 이 기능은 “이득에 비해 너무 복잡하고 편법적이다”고 결정했기 때문입니다. 아쉽네요. 제가 좋아하던 레이아웃 몇 개를 다른 방식으로 다시 만들어야 합니다.
- Sway는 [con_id] 조건으로 워크스페이스 노드를 매칭하지 않습니다. 이를 수정하는 풀 리퀘스트 #8980(5일 전에 독립적으로 게시됨)이 있습니다.
제 wsmgr-for-i3는 부분적으로 동작했습니다:
- 워크스페이스 복원(wsmgr restore)은 동작했습니다.
- Sway의 rename workspace 명령 구현은 대상 이름에서 워크스페이스 번호를 가져오지 않는 것 같습니다.

터미널: foot

X11에서는 rxvt-unicode(URxvt) 터미널 에뮬레이터를 사용합니다. 빠르고 미니멀한 외관 외에도 놓치고 싶지 않은 편의 기능이 몇 가지 있습니다:

스크롤백(= 명령 출력)에서의 역방향 검색
키보드 단축키로 스크롤백에 있는 URL 열기
동일한 작업 디렉터리에서 새 터미널 창 열기
셸에서 터미널 제목 업데이트하기

이전 실험에서는 Alacritty나 Kitty를 시도해 봤지만 둘 다 만족스럽지 않았습니다.

anarcat의 블로그 글 “Wayland: i3 to Sway migration” 덕분에 정말 괜찮아 보이는 선택지인 foot 터미널 에뮬레이터를 알게 됐습니다!

URxvt 설정에 맞추려고 foot.ini 설정 파일을 만들기 시작했지만, 나중에 일부 색상이 일치하지 않는 것을 발견했습니다(녹색/빨간색 배경의 일부 텍스트 줄이 다르게 보였습니다). 이유가 무엇인지 아직 더 살펴보지 않았습니다.

foot을 사용하면서 다음과 같은 문제들을 발견했습니다:

Ctrl+Enter를 누르면(실수로 꽤 자주 누르는 것 같습니다) 이스케이프 시퀀스가 발생하는데, URxvt는 Ctrl+Enter를 그냥 Enter처럼 처리합니다.
이는 셸(Zsh를 사용합니다)에서 우회할 수 있습니다. 자세한 내용은 foot 이슈 #628을 참고하세요.
마우스로 URL 일부를 더블클릭하면 URL이 선택되긴 하지만(예상대로), https: 스킴 접두사 없이 선택됩니다! 마우스를 쓰고 싶을 때는 꽤 성가십니다.
Ctrl을 누른 채로 선택하면 이를 우회할 수 있는데, 그러면 foot이 포인터 아래의 내용을 다음 공백 문자까지 모두 선택합니다.
foot에서 screen(1)을 시작하면 screen 세션 안에서 실행되는 프로그램에서 색상 지원이 되지 않습니다. 아마도 terminfo 관련 문제인 것 같습니다…? GNOME 터미널에서도 같은 문제를 재현할 수 있습니다. 하지만 URxvt나 xterm에서는 제대로 동작합니다.
텍스트를 선택하면 줄 전체가 아니라 줄 안의 텍스트만 하이라이트됩니다. 제가 쓰던 다른 터미널 에뮬레이터들과는 다르지만, 이를 변경할 수 있는 옵션은 보이지 않습니다.
다음은 “kthreadd” 오른쪽을 트리플클릭한 뒤의 foot 스크린샷입니다:
하지만 echo 출력 줄을 트리플클릭하면 줄 전체가 아니라 내용만 하이라이트됩니다:

텍스트 에디터: Emacs

Emacs의 Wayland 지원은 상당히 실망스럽습니다. Emacs 표준 버전은 X11만 지원하므로 Sway에서는 Xwayland로 실행됩니다. Sway가 Xwayland에서 스케일링을 지원하지 않기 때문에 Emacs가 흐릿하게 보입니다(위/배경 창):

네이티브 Wayland 지원(아래/전경 창)은 pgtk Emacs 버전(NixOS에서는 emacs-pgtk)에서만 제공됩니다. pgtk는 원래 별도 브랜치였지만 Emacs 29(2023년 7월)에서 병합됐습니다. pgtk는 X11에서 문제가 있는 것 같아(X11에서 Emacs-pgtk를 시작하면 경고가 표시됩니다) 현재로서는 두 버전을 따로 유지해야 합니다…

안타깝게도 pgtk의 텍스트 렌더링은 네이티브 X11 텍스트 렌더링과 다르게 보입니다! 줄 높이와 글자 간격이 달라 보입니다:

왜 다른지 잘 모르겠습니다! 예전과 동일하게 맞추는 방법을 아시는 분이 계실까요?

텍스트 렌더링 차이 외에도 저에게 가장 큰 문제는 입력 지연입니다. Emacs-pgtk는 Emacs보다 체감상 훨씬 느립니다(반응성이 떨어집니다). 이 문제는 Reddit에서 여러 차례(스레드 1, 스레드 2) 그리고 Emacs 버그 #71591에서 보고됐지만 해결책은 없는 것 같습니다.

Emacs를 원격으로 실행하는 방법도 찾아야 합니다. 지금까지는 SSH를 통한 X11 포워딩을 사용해 왔는데(광케이블 연결에서는 지연이 낮고 잘 동작합니다). waypipe를 한 번 살펴봐야 할 것 같은데 아직 기회가 없었습니다.

브라우저: Chrome

Chrome을 시작해 chrome://gpu 디버그 페이지를 확인하면 상태가 좋아 보입니다:

하지만 브라우저 창을 옮기고 크기를 조절한 뒤 얼마 지나지 않아 GPU 프로세스가 다음과 같은 메시지와 함께 죽고, 예를 들어 WebGL이 더 이상 하드웨어 가속되지 않습니다:

ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Scanout|Rendering|Texturing
ERROR:ui/gfx/linux/gbm_wrapper.cc:405] Failed to create BO with modifiers: Invalid argument (22)
ERROR:ui/ozone/platform/wayland/gpu/gbm_pixmap_wayland.cc:95] Cannot create bo with format=RGBA_8888 and usage=Texturing
ERROR:gpu/command_buffer/service/shared_image/shared_image_factory.cc:981] CreateSharedImage: could not create backing.
ERROR:gpu/command_buffer/service/shared_image/shared_image_manager.cc:397] SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a non-existent mailbox.
ERROR:components/viz/service/gl/exit_code.cc:13] Restarting GPU process due to unrecoverable error. Context was lost.
R:gpu/ipc/client/command_buffer_proxy_impl.cc:321] GPU state invalid after WaitForGetOffsetInRange.
ERROR:content/browser/gpu/gpu_process_host.cc:1005] GPU process exited unexpectedly: exit_code=8704

물론 하드웨어 가속 없이 브라우저를 사용하는 것은 특히 고해상도에서 매우 답답합니다. Chrome을 --disable-gpu-compositing 옵션으로 시작하면 GPU 프로세스가 종료되는 문제를 우회할 수 있는 것 같지만, 그래도 X11에서만큼 부드럽게 느껴지지는 않습니다.

저에게 또 다른 큰 문제는 Sway가 Chrome 창을 닫았던 워크스페이스에서 다시 열지 않는다는 점입니다. _NET_WM_DESKTOP EWMH 아톰을 추적하고 복원하는 지원은 i3에는 2016년 1월에, Chrome에는 2016년 5월에, Firefox에는 2020년 3월에 추가됐습니다.

저는 보통 5개 이상의 워크스페이스와 그보다 더 많은 Chrome 창을 동시에 열어 두기 때문에, 매일(업무용 컴퓨터를 부팅할 때) 10개가 넘는 Chrome 창을 일일이 정리해야 하는 것은 매우 성가십니다.

Simon Ser는 이 문제가 새로운 Wayland 프로토콜(xdg-session-management, 머지 리퀘스트 !18)로 해결될 것이라고 말했습니다.

화면 공유

저는 원격 근무를 많이 하기 때문에 화면 공유는 기본 중의 기본 기능입니다. 거의 매일 브라우저에서 다양한 상황과 요구에 맞춰 화면 공유를 사용합니다.

X11에서는 Chrome에서 다음과 같은 경험을 합니다. “Window” 탭을 클릭하면 제 창들의 미리보기가 보입니다. 창을 선택하고 확인하면 그 창 내용이 공유됩니다:

Wayland/sway에서 화면 공유를 동작하게 하려면 xdg-desktop-portal과 xdg-desktop-portal-wlr(후자는 sway가 사용하는 wlroots 전용)을 설치해야 합니다.

이 패키지들을 설정한 뒤 제가 본 동작은 다음과 같습니다:

Chrome 탭을 공유할 수 있습니다.
모니터 전체를 공유할 수 있습니다.
특정 창을 공유할 수 없습니다(모니터 전체가 하나의 창처럼 표시됩니다).

이는 xdg-desktop-portal-wlr(및 기타)의 제약이며, 예정된 Sway 1.12 릴리스에서 해결될 예정입니다.

직접 시도해 보기 위해 NixOS 설정을 git 버전의 sway와 wlroots를 사용하도록 변경했습니다. “Window” 탭을 클릭하면 창을 선택해야 하는 선택기가 나타납니다:

창을 선택한 뒤에는 Chrome에서 해당 창 내용만 미리보기로 보입니다:

확인한 뒤에는 또 다른 선택기가 나타나 창을 다시 선택해야 합니다. 특히 두 번째 단계에서 미리보기된 창과 선택한 창 사이에는 아무런 연결이 없습니다. 다른 창을 선택하면 그 창이 공유됩니다:

이제 해당 창이 화면 공유됩니다(기능 자체는 동작하네요, 좋습니다!). 하지만 아쉽게도 저해상도로 공유되어 동료들에게 텍스트가 흐릿하게 보입니다.

이 문제를 xdg-desktop-portal-wlr 이슈 #364로 보고했는데, 잘못된 스케일 팩터가 적용된 것이 원인인 것 같습니다. 해당 이슈에 제시된 패치는 제 환경에서는 동작합니다.

하지만 큰 틀에서 보면 전체 흐름 자체가 잘못된 것 같습니다. Chrome의 “Window” 탭을 클릭했을 때 별도의 선택기가 나타나서는 안 됩니다. 모든 창의 미리보기가 보여야 합니다. 별도의 선택기가 아니라 Chrome 안에서 창을 선택할 수 있어야 합니다.

스케일링 결함

출력 스케일링이 활성화된 상태에서 매우 성가신 결함도 발견했습니다. 창 사이(탭 또는 스택 컨테이너 안)나 워크스페이스 사이를 전환할 때 (일부!) 창의 내용이 “튕기는” 현상이었습니다.

이 현상을 처음 발견한 것은 foot 터미널 에뮬레이터에서였으며, 동작은 다음과 같습니다:

워크스페이스를 변경하거나 스택 또는 탭 컨테이너 안에서 포커스를 전환해 다른 foot 터미널로 포커스를 옮깁니다.
새 foot 터미널은 텍스트 내용이 약간 어긋난 채로 나타납니다.
수 밀리초 안에 foot의 텍스트가 올바른 위치로 튕겨 올라갑니다.

이 창으로 포커스를 옮긴 직후 내용이 몇 픽셀 움직이는 순간을 iPhone으로 촬영했습니다:

나중에는 Chrome 창도 전환 직후 잠시 흐릿하게 보이는 현상을 발견했습니다.

제 추측으로는 Sway가 보이지 않는 창에 대해 스케일 팩터를 1로 설정하기 때문에, 포커스를 전환할 때 애플리케이션이 스케일 3 콘텐츠 버퍼를 제공하기 전까지는 스케일 1 콘텐츠 버퍼가 보이는 것 같습니다.

알림: dunst

dunst는 Wayland를 네이티브로 지원합니다. dunst 1.13을 사용해 봤는데 별다른 문제를 발견하지 못했습니다.

선택기: rofi

rofi는 v2.0.0(2025-09-01)부터 Wayland에서 동작합니다.

저는 rofi와 rofimoji를 이모지 선택기로 사용합니다. 텍스트 입력은 xdotool 대신 wtype이 잘 동작하는 것 같습니다. 별다른 문제는 발견하지 못했습니다.

스크린샷: grim?

평소에 사용하던 maim(1) 대신 grim(1)을 시도해 봤지만, 캡처할 창을 선택하는 grim의 -T 플래그는 사용하기가 꽤 번거롭고(게다가 1배 스케일로 캡처됩니다).

혹시 좋은 대안을 아시는 분이 계실까요?

결론

드디어 제 환경에서 Wayland 세션을 동작시키는 데 어느 정도 진전을 이뤘습니다!

이번 Wayland/sway 실험에 대한 결론을 내리기 전에 먼저 말씀드리자면, 저는 X11/i3에서의 경험이 정말 만족스럽습니다. 일상적인 컴퓨터 사용에서 티어링이나 다른 아티팩트, 결함을 전혀 보지 못합니다. 컴포지터를 사용하지 않기 때문에 입력 지연도 매우 좋습니다. 예전에 직접 만든 키보드로 X11의 Emacs에서 측정했을 때 약 763μs 정도였습니다(출력 지연 별도). 자세한 내용은 kinX: latency measurement (2018)을 참고하세요.

그래서 제 관점에서 보면, 기존에 완벽하게 동작하던 스택(제 기준에서)에서 Sway로 옮기는 것은 단점만 가져옵니다. 이전에는 없던 새로운 그래픽 결함이 보입니다. 가장 많은 시간을 보내는 프로그램(Chrome과 Emacs)의 체감이 확연히 나빠졌습니다. 구현 방식이 다르거나 아예 프로그램을 교체해야 하기 때문에 수많은 새로운 버그를 마주하게 됩니다.

처음으로 Wayland 경험이 기존과 동등한 수준에 도달할 수 있을 것 같다는 느낌이 들지만, 현실적으로는 아직도 몇 주, 어쩌면 몇 달의 작업이 더 필요할 것입니다. 제 경험상 디버깅 세션은 그래픽 카드를 교체하고 모니터 배선을 다시 하며 버그를 좁혀가야 하므로 금세 몇 시간이 걸립니다. 안타깝게도 이 수많은 문제를 고치는 데 많은 시간을 기여할 여유가 없어, 당분간은 X11/i3를 계속 사용할 예정입니다.

제게 Wayland/Sway 세션이 일상용으로 준비됐다고 말할 수 있는 시점은 다음과 같은 조건이 충족될 때입니다:

Sway에서 일부 키 바인딩이 가끔 두 번 실행되는 현상(“유령 키 입력”)이 더 이상 발생하지 않을 때
Sway에서 창이나 워크스페이스를 전환할 때 결함이 더 이상 보이지 않을 때
Chrome이 지속적으로 하드웨어 가속될 때
Chrome 창이 시작 시 이전 워크스페이스로 복원될 때
Emacs가 다음 중 하나를 만족할 때:
- Xwayland로 실행되면서 Sway가 스케일링을 제대로 지원할 때
- 또는 pgtk 변종에서 입력 지연 문제가 해결되고 어떻게든 텍스트를 예전과 동일하게 렌더링할 수 있게 될 때