Liệu cuối cùng có thể dùng Wayland vào năm 2026?

• Wayland là stack đồ họa kế nhiệm X11, được khởi động từ năm 2008, nhưng tác giả cho rằng trong suốt 18 năm qua vẫn không thể dùng nó đúng nghĩa trên hệ thống của mình
• Tính đến năm 2025, nhờ driver nVidia hỗ trợ GBM và explicit sync, việc khởi chạy cơ bản đã khả thi, nhưng việc chuyển đổi hoàn toàn vẫn khó khăn do các vấn đề như chưa hỗ trợ TILE cho màn hình 8K
• Sway 1.11 và wlroots 0.19.0 đã có những tiến bộ kỹ thuật quan trọng, nhưng vẫn còn nhiều trở ngại khi dùng thực tế như độ trễ đầu vào, lỗi đồ họa và vấn đề scaling của Xwayland
• Các ứng dụng quan trọng như Chrome và Emacs vẫn cho thấy các vấn đề như giảm hiệu năng, khác biệt trong kết xuất và tăng tốc phần cứng không ổn định
• Nhìn chung, Wayland “cuối cùng cũng đã ở trong tầm với để dùng thực tế”, nhưng với công việc hằng ngày thì tổ hợp X11/i3 vẫn ổn định hơn

---

Bối cảnh lịch sử của Wayland

• Wayland là dự án kế nhiệm X server (X11, Xorg) bắt đầu từ năm 2008, và tác giả đã phát triển trình quản lý cửa sổ xếp ô i3 cho X11 vào năm 2009
• Ban đầu chỉ có thể chạy compositor demo Weston, đến năm 2014 GNOME, sau đó là KDE bắt đầu hỗ trợ Wayland
• Các ứng dụng lớn như Firefox, Chrome, Emacs chỉ có thể dùng Wayland thông qua cờ thử nghiệm
• GPU nVidia trong thời gian dài либо không hoạt động trên Wayland, либо gây lỗi đồ họa, và vấn đề tương thích với màn hình 8K cũng kéo dài
• Gần đây, các bản phân phối lớn như Fedora, RHEL, Asahi Linux đã chọn Wayland làm stack desktop mặc định hoặc duy nhất, làm tăng áp lực chuyển đổi

Cấu hình môi trường chạy Wayland

• Hệ thống thử nghiệm sử dụng nVidia RTX 4070 Ti (PC trong phòng lab) và RTX 3060 Ti (PC chính)
• Từ driver nVidia 495 (2021) đã có hỗ trợ GBM, và tính năng explicit sync được triển khai trong Sway 1.11 (2025) và wlroots 0.19.0
• Tuy nhiên, do Sway chưa hỗ trợ thuộc tính TILE của màn hình 8K Dell UP3218K, màn hình bị hiển thị tách thành hai phần
  • Thông qua bản vá của EBADBEEF và phân tích của Claude Code, tác giả phát hiện lỗi thuộc tính SRC_X DRM và đã thành công hiển thị toàn màn hình bằng bản vá обход
• GNOME có hỗ trợ TILE nhưng lại gặp xé hình nghiêm trọng ở giữa màn hình
• Trong môi trường NixOS 25.11, tác giả cấu hình song song GDM, GNOME, Sway và bổ sung các công cụ dành riêng cho Wayland như foot, fuzzel, wayland-utils

Kết quả thử nghiệm: môi trường Sway

• Sway tương thích với phần lớn cấu hình i3, và tác giả đã điều chỉnh bố cục bàn phím NEO cùng các thiết lập input/output
• Các vấn đề chính:
  • Con trỏ chuột bị trễ và chuyển động không mượt (nghi do nVidia không hỗ trợ hardware cursor)
  • Không thể scaling ứng dụng Xwayland, dẫn đến hiển thị mờ hoặc bị phóng đại kép
  • Một số phím tắt bị thực thi hai lần (ghost key press)
• Các ứng dụng GTK ban đầu bị lỗi cỡ chữ quá lớn, nhưng đã khắc phục bằng gsettings reset
• GTK3 chỉ dùng cấu hình dconf, nên cần đặt font-name trong dconf để kết xuất khớp nhau
• swaylock khác với i3lock ở chỗ khi thoát sẽ rơi vào trạng thái “màn hình đỏ”, chỉ có thể gỡ bằng SIGUSR1
• Các công cụ tự động hóa dựa trên i3 IPC chỉ tương thích một phần do khác biệt đường dẫn socket, tiến trình còn tồn tại và không hỗ trợ khôi phục layout

Kiểm thử các ứng dụng chính

• Terminal foot khá nhẹ, nhưng có các vấn đề như khác biệt màu sắc ở một số chỗ, xử lý Ctrl+Enter, chọn URL và lỗi màu với screen
• Emacs bản mặc định chạy trên Xwayland nên hiển thị bị mờ, còn bản pgtk thì có độ trễ đầu vào và khác biệt khoảng cách chữ
• Chrome bị crash tiến trình GPU khiến tăng tốc phần cứng ngừng hoạt động, đồng thời khi khôi phục cửa sổ thì không giữ được thông tin workspace trước đó
• Chia sẻ màn hình có thể thực hiện qua xdg-desktop-portal-wlr, nhưng tồn tại vấn đề không hỗ trợ chia sẻ theo từng cửa sổ và truyền ở độ phân giải thấp
• Khi bật scaling đầu ra, nội dung cửa sổ đôi lúc bị lệch tức thời hoặc xuất hiện glitch mờ
• Thông báo dunst và rofi (2.0.0 trở lên) hoạt động bình thường, còn công cụ chụp màn hình grim thì tính năng chọn cửa sổ khá bất tiện

Kết luận: khả năng sử dụng Wayland trong năm 2026

• Phiên Wayland/Sway lần đầu tiên đã tiến rất gần tới mức dùng thực tế, nhưng vẫn còn nhiều khiếm khuyết
• Môi trường X11/i3 cung cấp độ trễ đầu vào thấp ở mức 763μs và độ ổn định gần như hoàn hảo
• Khi chuyển sang Wayland sẽ xuất hiện glitch đồ họa, độ trễ đầu vào và suy giảm hiệu năng ở các ứng dụng chính
• Các điều kiện cần để dùng hằng ngày:
  • Sửa lỗi nhập phím hai lần và glitch khi chuyển đổi của Sway
  • Ổn định tăng tốc phần cứng của Chrome và hỗ trợ khôi phục cửa sổ
  • Cải thiện độ trễ đầu vào và kết xuất của Emacs (pgtk)
• Kết luận, Wayland vẫn chưa sẵn sàng cho công việc hằng ngày, và tác giả dự định tiếp tục dùng X11/i3

[GN⁺]

Ý kiến trên Hacker News

• Wayland chỉ đơn thuần là một giao thức, nên tồn tại nhiều cách triển khai khác nhau (GNOME, KDE, wlroots, v.v.)
  Xorg là kiểu kiến trúc mà desktop được đặt lên trên một nền tảng vững chắc duy nhất, còn với Wayland thì mỗi desktop gần như phải tự phát minh lại bánh xe
  Weston phù hợp để làm tham chiếu, nhưng không thích hợp cho sử dụng hằng ngày
  Tôi nghĩ cần có một thư viện tiêu chuẩn mà mọi desktop có thể dùng chung. wlroots đang nhắm tới vai trò đó, nhưng GNOME hay KDE có lẽ sẽ không sớm chuyển sang
  • Tôi nghĩ X.org đã chọn đúng mức độ trừu tượng. WM không cần trực tiếp xử lý input hay output, nhờ vậy có được sự đơn giản và hiệu quả điện năng tốt. Wayland coi như đã không học được bài học từ X11
  • Tôi đã dùng Sway và Hyprland, còn bây giờ là niri. Sway và niri dựa trên wlroots khá ổn, nhưng vẫn còn rất nhiều lỗi ngẫu nhiên. Vấn đề con trỏ trong ứng dụng Wine, crash khi chia sẻ màn hình, lỗi màu 10-bit, v.v. Có thể tới khoảng năm 2027 thì sẽ ổn định hơn, nhưng với 20 năm phát triển thì tôi thấy như vậy là khá kém hiệu quả
  • KDE và GNOME mỗi bên đều có triển khai xdg-desktop-portal riêng, nên phát sinh vấn đề tương thích. Nếu dùng nền tảng wlroots thì phải dùng xdg-desktop-portal-wlr, còn Hyprland thì phải dùng xdg-desktop-portal-hyprland.
    Bản thân cấu trúc của Wayland nhìn trên lý thuyết có vẻ tốt như trong tài liệu kiến trúc chính thức, nhưng trên thực tế vẫn thiếu rất nhiều tính năng ở cấp giao thức
  • Thực ra X cũng là một giao thức, nhưng vì có một triển khai duy nhất là X.org nên ít hỗn loạn hơn. Việc có một thư viện được tiêu chuẩn hóa ở mức như wlroots không phải là điều bất khả thi về mặt kỹ thuật
  • Các nhà phát triển Wayland ban đầu thiết kế nó như một giao thức chỉ dành cho hiển thị. Họ kỳ vọng các giao thức cho input hay quản lý cửa sổ sẽ do các nhóm khác xây dựng, nhưng điều đó đã không diễn ra suôn sẻ.
    Những nỗ lực thay thế Wayland hiện nay rốt cuộc có thể chỉ là sự lãng phí khi phải làm lại những phần vốn đã trưởng thành
• Tôi vẫn chưa thấy lý do phải dùng Wayland. Xorg thì ổn định, và phần lớn bài viết hướng dẫn xử lý sự cố đều bắt đầu bằng kiểu “nếu đang dùng Wayland thì quay lại Xorg đi”.
  Có lẽ chỉ khi các bản phân phối ép đổi mặc định như từng làm với systemd thì mức độ chấp nhận mới thực sự tăng lên
  • Người dùng phổ thông thật ra không có lý do gì phải đổi. Nhưng Wayland xử lý tốt những điểm mà X11 yếu, như scale đa màn hình.
    Với GNOME và KDE, động lực lớn là muốn giảm gánh nặng tiếp tục bảo trì X11 bằng cách chuyển sang Wayland.
    Tôi nghĩ mục tiêu của năm nay là đạt đến mức “không còn nhược điểm rõ rệt”
  • Wayland cho cảm giác mượt hơn về hiệu năng, nhưng tôi vẫn phải dùng Xorg vì một số ứng dụng.
    GNOME 49 trên Arch và Ubuntu đã loại Xorg khỏi mặc định, và KDE cũng sẽ sớm làm theo. Thời của Xorg đang dần khép lại
  • Trước đây phải tự sửa xorg.conf, nhưng từ sau khi thử Wayland ở chế độ thử nghiệm trên Ubuntu thì tôi đã chuyển hẳn. Có lẽ vì dùng GPU AMD nên mọi thứ chạy mượt mà không vấn đề
  • Ưu điểm của Wayland là fractional scaling
  • Tôi cần dùng các công cụ như x2x, xev, xdotool, nhưng do mô hình bảo mật của Wayland nên điều đó là không thể, vì vậy tôi vẫn ở lại với Xorg
• Nói Nvidia từ chối API GBM của Wayland là hiểu nhầm. GBM là một API không chính thức nằm bên trong Mesa nên Nvidia không thể tự triển khai trực tiếp.
  Vì vậy họ đã đề xuất một phương án thay thế trung lập với nhà cung cấp là EGLStreams.
  Vấn đề đúng hơn là phía freedesktop đã không cung cấp một cấu trúc để driver Nvidia có thể hoạt động
  • Nhưng tôi thắc mắc làm sao một dự án mã nguồn mở như Mesa lại có thể phụ thuộc vào API không công khai
• Tôi đã dùng Wayland trên Gnome suốt nhiều năm và không gặp vấn đề gì.
  Dĩ nhiên phần nào cũng nhờ phần cứng đơn giản, không phải Nvidia, nhưng tôi muốn nhấn mạnh rằng Wayland hoàn toàn có thể hoạt động tốt
  • Tôi cũng vậy, dùng Sway (2016) và KDE Plasma 6 đều chạy hoàn hảo. Chỉ có game Steam là tôi chạy bằng XWayland. Tổ hợp AMD/Intel ổn định hơn nhiều
  • Ngay cả với phần cứng Nvidia thì gần đây nó cũng chạy khá mượt. Trước kia có giật lag, nhưng giờ tôi thấy còn tốt hơn Xorg.
    Tuy vậy, các tính năng như điều khiển vị trí cửa sổ hay duyệt qua ứng dụng khác vẫn phải lách bằng Gnome Shell Extension
  • Giống như chuyện ngày xưa có người không nhận ra CRT bị nhấp nháy, những bất tiện nhỏ như cảm giác input tinh tế hay khác biệt phông chữ trên Wayland có thể được mỗi người cảm nhận rất khác nhau
• Tôi đã dùng Wayland dựa trên wlroots/swaywm nhiều năm, và cả eGPU cũng hoạt động hoàn hảo.
  Tuy vậy có thể là vì tôi dùng phần cứng AMD. Đời quá ngắn để lãng phí vào các vấn đề của Nvidia
  • Ngược lại, trên đồ họa tích hợp Intel thì sway hay crash, nên tôi quay về i3+Xorg
  • Tôi đã dùng Nvidia 23 năm mà không gặp vấn đề lớn nào. Dù vậy tôi nghĩ đây là chuyện lựa chọn của mỗi người
  • Trước đây tôi cũng dùng tốt trên Nvidia, và với bản vá TILE thì màn hình 5K cũng ổn.
    Tôi từng chuyển sang Wayland vì hỗ trợ scale nhiều đầu ra, rồi sau đó lại quay về
• Gần đây tôi chuyển sang Linux vì các vấn đề của Windows, mà trước kia điều đó là không thể do thiếu fractional scaling.
  Wayland đã giải quyết được nên là một cải thiện lớn. Tuy nhiên không phải bản phân phối nào cũng dùng Wayland mặc định nên tôi chọn Ubuntu.
  Firefox bản Snap không dùng tăng tốc phần cứng nên hơi bất tiện
  • Tôi cũng thấy fractional scaling là điều thiếu nhất trên Linux.
    MacOS thì kể cả đặt kiểu “trông như 1440p” vẫn hoàn hảo, còn Windows thì hơi mờ.
    Trên Linux, X11 thì chậm, còn Wayland vẫn có độ trễ hiệu năng
• Tôi cũng dùng bộ i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool.
  Việc đổi stack đang chạy hoàn hảo này sang Sway có hại nhiều hơn lợi.
  Tôi thấy việc Michael đã thử và ghi chép lại là rất đáng nể
  • Điều gây ấn tượng là họ đã ghi lại các vấn đề thực tế một cách tỉ mỉ
• Tôi sẽ không chuyển trước khi window manager (WM) tôi dùng hỗ trợ Wayland.
  Vấn đề lớn nhất của Wayland là nhiều dự án WM không thể chuyển đổi do thiếu nhân lực.
  Có thể đi đường vòng bằng XWayland, nhưng tôi không muốn thêm một lớp nữa vào môi trường vốn đã hoạt động hoàn hảo
  • Nếu bạn dùng StumpWM, thì phiên bản Wayland là Mahogany đang được phát triển tích cực.
    Ngoài ra Wayback là dự án chạy toàn bộ desktop X11 trên nền Wayland
• Tôi dùng Wayland trên laptop Framework và nó hoạt động hoàn hảo.
  Màn hình 4K, chuyển đổi một màn hình, fractional scaling, tất cả đều không có vấn đề.
  Ngay cả trên Chromebook cũ, hiện tượng xé hình cũng biến mất và mọi thứ chạy mượt.
  Tôi vẫn chưa cảm nhận thấy nhược điểm nào, mà trái lại nhược điểm duy nhất là bị người khác bảo rằng nó “sai”
  • Nếu nó chạy tốt thì rất hay, nhưng cũng phải thừa nhận rằng có những người không dùng được
  • Chỉ vì bạn may mắn không gặp vấn đề không có nghĩa là nó không có nhược điểm
• Với tôi, Wayland chỉ có nhược điểm mà không có ưu điểm. Tôi cho rằng cấu trúc đẩy sự phức tạp sang các lớp khác là một hướng đi sai.
  Sau này tôi vẫn sẽ dùng Xorg và Openbox
  • Việc phân tán độ phức tạp từ một chỗ sang nhiều chỗ là một quyết định khó hiểu
  • Dù vậy, Xorg đang ngày càng ít được bảo trì, và các nhà phát triển chủ chốt đang chuyển sang Wayland.
    Cuối cùng Wayland sẽ trở thành lựa chọn duy nhất còn được quản lý tích cực