I switched to Wayland (and you should too)

Summary of the subtitles (technical focus)

• Switching from X11 to Wayland: The speaker describes moving from X11 to Wayland on Linux and calls it a “really awesome experience.” The main benefits are that it eliminated/mitigated common X11 problems such as:

  • Screen tearing
  • Buggy external monitor behavior
  • Applications crashing when moving windows between monitors
  • Various compositor/wallpaper-related issues

• Wayland basics: Wayland is presented as a modern replacement for the old X11 windowing system—removing long-standing “technical debt” accumulated over decades.

• Why they switched (their expectation): They previously avoided Wayland because they thought it only mattered if you used fancy window managers like Hyprland (with animations). They say they don’t care about animations and instead want “quick and precise” window behavior.

---

Using Wayland without changing workflow: Sway as the key product choice

• Window manager: i3 → Sway (Wayland version)

  • The speaker previously used i3 with XFCE services.
  • They wanted the same workflow on Wayland and recommend Sway because it’s essentially:
    • “i3, but for Wayland”
  • Drop-in compatibility: They claim you can use an i3 config file with Sway, with caveats: some X11-specific components won’t work and need Wayland alternatives.

• Status/feature parity with i3: Their Sway experience is described as “pretty indistinguishable from i3,” including:

  • Pane navigation and resizing
  • Tabbing mode
  • Workspace switching quickly

---

Sway configuration details (tutorial-like highlights)

• Single Sway config file: Their configuration is organized in one file.
• Modifier keys + bindings: The overall approach matches i3 (modifier key, direction keys, terminal and browser).
• Multi-monitor setup (Wayland-specific): They configure outputs using Sway’s output directives, specifying:
  • Output name
  • Resolution
  • Position/layout
• Built-in features that replace X11 tooling: They emphasize they don’t need external tools like “picom / fet / XR stuff” because Sway includes related functionality. They also mention utilities/areas such as:
  • swayidle
  • touchpad handling
  • other configuration-driven features
• Bindings/modifiers for apps:
  • Terminal launches (including a shortcut for “hardware acceleration”)
  • Browser shortcut
  • Screenshot shortcut

---

Wayland app launcher compatibility (ROI on Wayland)

• dmenu vs wmenu: They note the default launcher in Wayland environments is Wofi (“Wmenu instead of Dmenu”), because Dmenu is X11-based.
• Their approach: They use Rofi-style launchers via Wayland-compatible forks, such as:
  • a ROfi fork that supports Wayland, and/or
  • Woi (described as a port of Rofi to Wayland)
• Config compatibility: They claim Rofi configuration syntax can be reused without changes, making migration easier.

---

Waybar replacement for i3 status bar

• Waybar under Sway: They install Waybar and customize it using CSS to resemble i3bar. They reference documentation (available via a link in the video description).
• UI changes / extra space: They enable a setup with no title bars, using Waybar to display title info, which they describe as providing “more real estate.”

---

Optional visual effects: SwayFX

• No “flashy animations” by default: They reiterate that Sway itself is relatively minimal (few fancy effects).
• SwayFX for animations: They mention SwayFX to add “Hyperland-style effects” to Sway, implying you can add effect commands to a Sway config for portability.

---

Screenshot and utility tooling (dependency list)

They name external utilities used alongside Sway/Wayland:

• slurp for taking screenshots
• grim for capturing/processing and saving screenshots
• wl-color-picker to pick colors and return hex codes

They describe this as “not too crazy,” and mention that looking things up on the Arch Wiki repeatedly provided Wayland-compatible options.

---

Addressing the concern: “Wayland can’t run X11 apps” (their rebuttal)

• They claim this concern is false:
  • They report no issues running X11-only applications on Wayland.
• Example given: Their own project supposedly X11-only (via an app windowing library that supports only X11) still works perfectly.
• Performance note: They mention there may be a small performance dip in general, but in practice they see equal or better smoothness and compatibility.

---

Installation guidance (Arch-specific)

• On Arch Linux:
  • Install Wayland
  • Install XWayland (called “XWayland” in the subtitles as “XW Wayland”) to run X11 apps
  • Install Sway
• NVIDIA note: They say the setup can be harder on NVIDIA and may require switching to open-source Nvidia drivers (nouveau).
  • Their own setup: they booted Sway using:
    • unsupported GPU tag (within Sway) to use proprietary NVIDIA drivers
  • They report it worked fine for them.

---

Overall review / takeaways

• Main conclusion: Wayland is “absolutely worth it” because it:
  • Removes many X11 bugs (tearing, crashes, compositor issues, wallpaper issues)
  • Does not harm workflow thanks to Sway
  • Reduces the need for ongoing system tinkering after configuration
• Stability claim: They acknowledge Wayland can be “unstable” generally / due to fast changes, but say it has been stable and reliable for them.

---

Main speakers / sources

• Main speaker: The YouTube video narrator (primary author describing their own Wayland + Sway experience).
• Mentioned sources/tools (not speaking):
  • Sway (window manager)
  • Wayland / X11 concepts
  • i3 configuration compatibility
  • Waybar (status bar)
  • Waybar documentation (referenced for setup)
  • Arch Wiki (referenced for alternatives)
  • XWayland
  • SwayFX
  • slurp / grim / wl-color-picker (utilities)
  • ROfi / Woi / Wofi (launcher-related tools)
  • nouveau (open-source Nvidia drivers, mentioned as a possibility)