Tách compositor và trình quản lý cửa sổ trong Wayland

• Trong môi trường Wayland trước đây, compositor và trình quản lý cửa sổ là một chương trình duy nhất được gắn kết với nhau, nhưng river 0.4.0 đã tách chúng thành các tiến trình riêng biệt
• Giao thức river-window-management-v1 mới trao cho trình quản lý cửa sổ toàn quyền quyết định chính sách như bố trí cửa sổ, key binding, đồng thời vẫn duy trì frame perfection và hiệu năng
• Cấu trúc này hoạt động không có độ trễ đầu vào (latency), và ngay cả với bố cục xếp ô phức tạp vẫn bảo đảm kết xuất gọn gàng nhờ cập nhật trạng thái nguyên tử
• Nhờ kiến trúc tách rời, trình quản lý cửa sổ có thể được phát triển và khởi động lại độc lập, cũng dễ triển khai bằng ngôn ngữ bậc cao
• Cách tiếp cận này thúc đẩy sự đa dạng của trình quản lý cửa sổ trong hệ sinh thái Wayland, và river hiện đã hỗ trợ hơn 15 trình quản lý tương thích

---

Cấu trúc truyền thống của Wayland và cách tiếp cận tách rời của river

• Compositor Wayland truyền thống tích hợp ba vai trò display server, compositor và trình quản lý cửa sổ trong cùng một tiến trình
  • Display server định tuyến các sự kiện đầu vào và chuyển bộ đệm hiển thị cho kernel
  • Compositor kết hợp buffer của nhiều cửa sổ để tạo ra màn hình cuối cùng
  • Trình quản lý cửa sổ đảm nhiệm các chính sách người dùng như bố trí cửa sổ và key binding
• Trong kiến trúc X11, display server tồn tại như một tiến trình riêng, gây ra giao tiếp khứ hồi không cần thiết và độ trễ
• Wayland giải quyết điều này bằng cách hợp nhất server và compositor, nhưng không bắt buộc phải gắn luôn cả trình quản lý cửa sổ
• river tháo rời sự gắn kết này để tách trình quản lý cửa sổ thành một chương trình riêng

Nguyên tắc thiết kế của giao thức river-window-management-v1

• Được thiết kế để trình quản lý cửa sổ có quyền kiểm soát tối đa nhưng vẫn giữ được các ưu điểm của Wayland
• Không cần giao tiếp khứ hồi ở mỗi frame hay mỗi sự kiện đầu vào, nên không có độ trễ đầu vào
• Duy trì frame perfection: khi cửa sổ mới mở hoặc thay đổi kích thước, bảo đảm cập nhật màn hình không có khe hở hay chồng lấn
  • Việc kết xuất sẽ được trì hoãn cho đến khi mọi cửa sổ gửi buffer mới, nhưng sẽ xử lý bằng timeout nếu vượt quá thời gian nhất định
• Ứng dụng được triển khai tốt sẽ càng dễ đạt được đồng bộ frame hoàn chỉnh

Cấu trúc quản lý cửa sổ dựa trên state machine

• Giao thức chia trạng thái thành trạng thái quản lý cửa sổ và trạng thái kết xuất
  • Trạng thái quản lý cửa sổ: kích thước cửa sổ, có toàn màn hình hay không, keyboard focus, key binding, v.v.
  • Trạng thái kết xuất: vị trí cửa sổ, thứ tự, trang trí, crop, v.v.
• Các thay đổi được gom lại và xử lý bằng cập nhật nguyên tử (manage/render sequence)
• Compositor khởi đầu sequence, và khi không có thay đổi trạng thái thì trình quản lý cửa sổ sẽ được giữ ở trạng thái chờ
• Cấu trúc này là cách chuẩn hóa tường minh những khái niệm vốn đã tồn tại ngầm trong river-classic, sway, v.v.

Lợi ích của kiến trúc tách rời

• Nhà phát triển trình quản lý cửa sổ có thể chỉ tập trung vào chính sách mà không cần triển khai toàn bộ compositor
• Dễ gỡ lỗi và khởi động lại, sự cố của trình quản lý cửa sổ không dẫn tới kết thúc phiên làm việc
• Viết bằng ngôn ngữ có garbage collection cũng không làm giảm hiệu năng, vẫn hoạt động không trễ frame
• Hiện đã có hơn 15 trình quản lý cửa sổ tương thích với river, và có thể kỳ vọng mức độ đa dạng như X11

Giới hạn và kế hoạch sắp tới

• Giao thức hiện chỉ hỗ trợ môi trường desktop 2D, chưa hỗ trợ VR hay các trường hợp tương tự
• Hiệu ứng hình ảnh phức tạp (ví dụ: cửa sổ rung lắc) nằm ngoài phạm vi, nhưng các animation đơn giản thì có thể
• Trong tương lai có xem xét hỗ trợ custom shader, nhưng chưa phải kế hoạch ngắn hạn
• river 0.4.0 đã đủ tốt cho sử dụng hằng ngày, và UX sẽ tiếp tục được cải thiện trước khi chuyển sang phiên bản 1.0.0
• Dự án kêu gọi hỗ trợ qua liberapay, GitHub Sponsors, Ko-fi để tiếp tục phát triển

Ví dụ và thư viện ảnh

• Cung cấp nhiều ví dụ về các trình quản lý cửa sổ hoạt động trên river
  • Canoe: trình quản lý cửa sổ stacking kiểu cổ điển
  • reka: trình quản lý cửa sổ dựa trên Emacs
  • tarazed: môi trường desktop tập trung
  • rhine: hỗ trợ quản lý cửa sổ đệ quy, mô-đun và animation
• Ngoài ra còn có nhiều trình quản lý cửa sổ tương thích với river khác

[GN⁺]

Ý kiến trên Hacker News

• Tôi thấy khó hiểu trước những bất mãn với Wayland (giao thức) trong các bình luận
  Các thư viện như wlroots đã xử lý sẵn phần nặng, và giờ river còn cung cấp mức trừu tượng cao hơn
  Dự án Wayland có thể đã tự cung cấp kiểu trừu tượng này sớm hơn, nhưng tôi nghĩ đây vốn là việc ai cũng có thể làm
  Cuối cùng thì chúng ta đang có được những tiến bộ này miễn phí, nên không cần phàn nàn chỉ vì không có người khác làm thay mình

  • Tôi cho rằng vấn đề bắt đầu từ lập trường nguyên tắc ban đầu của Wayland, kiểu như cấm chụp màn hình
    Các vấn đề về khả năng truy cập cũng bị xem là rủi ro bảo mật nên việc thiết kế trở nên khó khăn hơn, và giờ khi bước vào thời đại Agentic AI thì đây có vẻ sẽ là một điểm thú vị
    Pipewire đang bù đắp những phần Wayland bỏ lỡ, nhưng vẫn có cảm nhận rằng thiết kế còn thiếu tính thân thiện với người dùng
    Dù vậy, tôi vẫn nghĩ Wayland nhìn chung đang tiến hai bước dù đôi lúc có lùi lại một hai bước
  • Tôi cho rằng gốc rễ của sự bất mãn nằm ở cộng đồng Wayland, đặc biệt là thái độ của phe GNOME
    Kiểu phản hồi “không theo cách của tôi thì biến đi” xuất hiện khá nhiều, và họ không linh hoạt trước các yêu cầu bên ngoài
    Việc được cung cấp miễn phí là tốt, nhưng trong bối cảnh Xorg đã dừng lại và không có lựa chọn thay thế thì việc bị ép đẩy sang đó là một vấn đề

• Đây là lần đầu tiên một dự án khiến tôi cảm thấy Wayland không phải là sự lãng phí thời gian
  Tôi không nghĩ display server nhất thiết phải ôm luôn cả phần quản lý cửa sổ một cách phức tạp như vậy
  Có lẽ ban đầu Wayland gộp window manager và compositor lại chỉ đơn giản vì đó là con đường ít vấp phải phản đối nhất
  Tuy vậy, truy cập từ xa vẫn là vấn đề. Những thứ từng chạy tốt trên X11 thì trên Wayland lại đầy lỗi

  • X11 tách Xserver và window manager ra, nên khó giải quyết các vấn đề như bố trí cửa sổ ban đầu
    Wayland đã giải quyết bằng cách tích hợp chúng lại, nhưng cũng tạo ra những tác dụng phụ khác
  • Phần lớn compositor Wayland cỡ nhỏ dùng các thư viện như wlroots hoặc smithay
    Ranh giới API được thiết kế tốt nên việc chia sẻ mã khá dễ dàng
    Tôi tò mò lỗi xoay 90 độ là vấn đề của compositor hay của wlroots
  • Truy cập từ xa trên X11 vốn đã rất tệ. Trên Wayland, việc phân lớp qua EGL hay Vulkan còn sạch sẽ hơn nên tôi nghĩ ngược lại là tốt hơn
  • Trên X11, window manager chịu trách nhiệm trang trí cửa sổ, nên nếu tách ra thì phần nhắn tin và cấu hình sẽ trở nên phức tạp
  • Có lẽ các desktop environment đã tự dựng hệ sinh thái riêng của mình rồi đá luôn cái thang lên

• Tôi nghĩ đây chỉ là một trong nhiều lỗi thiết kế của Wayland mà giờ mới bắt đầu được sửa
  Có lẽ phải mất thêm 15 năm nữa các giao thức chung mới ổn định và các window manager mới trưởng thành đến mức như X11
  Rồi cuối cùng sẽ lại có ai đó nói “tôi sẽ làm cái tốt hơn” và bỏ Wayland để làm lại từ đầu

  • Vì thế giờ tôi xem WSL hay Virtualization Framework là giải pháp thực tế hơn cho desktop Linux
    Tôi từng vật lộn với vấn đề UEFI rồi cuối cùng chuyển sang Samsung DEX
  • Dù có làm lại Wayland từ đầu thì kết quả chắc cũng tương tự
    Giới hạn ở đây theo tôi không hẳn là kỹ thuật mà là vấn đề chính trị

• Là người dùng Linux suốt 25 năm, tôi đã chuyển sang Wayland 5 năm trước và từ đó hài lòng vì không còn vấn đề xé hình (tear)
  Với nhà phát triển có thể sẽ phát sinh nhiều việc hơn, nhưng với người dùng thì đây rõ ràng là một cải thiện

  • Dù vậy, việc không có tính năng window shading vẫn đáng tiếc
    Tôi tự hỏi liệu mình có sẽ cứ nhắc mãi chuyện này như những người từng nhớ nhung các tính năng cũ của CDE không

• River vốn đã rất tuyệt ngay cả trước khi tách ra. Tôi rất mong chờ các bước phát triển tiếp theo
  Tôi đã chuyển tạm sang Niri, nhưng một lúc nào đó sẽ quay lại
  Nếu là người dùng Xmonad thì có lẽ River sẽ phù hợp nhất

  • Tôi cũng đang dùng Xmonad, và Hyprland đã không xử lý đúng stack master/slave
    Tôi muốn biết trong River thì cửa sổ mới có được chèn lên trên cửa sổ đang được chọn hay không
    Sau khi tách ra, tôi cũng muốn biết tên dự án phía window manager sẽ là gì

• Rốt cuộc thì chúng ta đang phát minh lại từng tính năng của X11
  Có lẽ một ngày nào đó cửa sổ Wayland sẽ biết được vị trí của chính nó

  • Những người theo chủ nghĩa lý tưởng vẫn còn ngại ngay cả việc mô tả rõ một lưới pixel 2D ảo
    Có lẽ còn phải chờ khá lâu nữa
  • Nhưng giờ đa số GNU/Linux được dùng cho server headless hoặc thiết bị nhúng, nên điều này có lẽ cũng không quá quan trọng
    Desktop có lẽ sẽ thuộc về Android, ChromeOS, hoặc các máy ảo chạy trên Windows/macOS

• Tôi đang dùng một window manager River được tùy biến hoàn toàn
  Trên Hyprland mặc định chỉ có BSP tiling nên khá bất tiện, còn trên River thì tôi có thể tile đều theo đúng ý muốn
  Việc tách này đã tạo ra thay đổi lớn trong workflow của tôi

  • Nếu muốn tile đều thì có thể tham khảo hy3
    Tôi cũng từng là người dùng i3, và nhờ hy3 mà có thể dùng Hyprland
  • Tôi cũng từng gặp vấn đề tương tự trên Hyprland và cuối cùng chuyển sang Niri để có môi trường phát triển ổn định
    Cấu hình của tôi được để trong dotfiles
  • Tôi muốn hỏi BSP là gì

• Theo tôi biết, một trong những thiết kế cốt lõi của Wayland là tích hợp window manager và compositor
  Tôi tò mò vì sao lại thiết kế như vậy

  • Nếu window manager là một tiến trình riêng giao tiếp bất đồng bộ thì sẽ phát sinh vấn đề đồng bộ khung hình
    Wayland xử lý đồng bộ để loại bỏ sự lệch pha về mặt hiển thị
  • Wayland đưa mọi thứ vào một tiến trình để giảm thiểu context switch
    Giao thức lần này là nỗ lực tách graphics server và window manager mà vẫn giữ được lợi thế hiệu năng đó

• Tôi nghĩ tổn thất lớn nhất của Wayland so với X11 là không thể dễ dàng thay thế window manager dạng plug-in
  Những người đang cố giải quyết vấn đề này thực sự rất đáng quý

  • Với người đã dùng cùng một window manager suốt hàng chục năm như tôi, rất khó chuyển sang Wayland nếu không có giao diện thay thế hoàn chỉnh
    Tôi hy vọng các lớp như River hay Wayback sẽ đảm nhiệm vai trò đó
  • Ràng buộc này cũng là trở ngại lớn cho việc phát triển WM·DE mới
    Tôi cũng có vài ý tưởng desktop thử nghiệm, nhưng vẫn buộc phải bắt đầu với X11 vì có thể lặp thử nhanh
    Wayland vẫn còn những điểm yếu trong thiết kế
  • Thực ra tôi nghĩ chỉ cần một implementation cung cấp WM extension API là đủ
    Không nhất thiết phải ép một cấu trúc cụ thể vào tiêu chuẩn
  • Lý tưởng nhất có lẽ là một cấu trúc phân tầng, với Wayland server gốc ở dưới, Wayland server theo từng người dùng ở trên đó, rồi X11 server bên trong, và window manager ở trên cùng

• Tôi đã dùng i3 suốt 15 năm, và mỗi lần thấy các dự án kiểu này lại tự hỏi vì sao Wayland là cần thiết
  X11 dù có nhược điểm nhưng gần như vẫn làm được mọi thứ tôi muốn
  Wayland lúc nào cũng có vẻ nhiều ma sát

  • Tôi đã dùng Wayland từ thời KDE 5, và HiDPI scaling của nó rất tuyệt
    Với người dùng laptop thì đó là lợi thế lớn, và hỗ trợ VRR hay HDR cũng dễ hơn nhiều so với X.org
  • Ở góc độ người dùng thì nó chỉ đơn giản là hoạt động tốt
    Việc chỉnh DPI theo từng màn hình, chống xé hình, và chặn ứng dụng tự ý quay màn hình đều được giải quyết sẵn
  • Lý do tôi chuyển từ i3 sang sway cũng là vì hỗ trợ DPI
    Tôi không còn phải đụng vào Xorg.conf nữa nên chất lượng sống tăng hẳn
    Đến giờ tôi vẫn dùng tỷ lệ scale khác nhau cho từng màn hình
  • Trên X11, thiết lập tần số quét cao lúc nào cũng là vấn đề
  • Vấn đề gần đây tôi gặp là Wayland không hỗ trợ DeviceEvent
    Tôi cần một tính năng cho phép nhận input ngay cả khi cửa sổ không được kích hoạt, nhưng chỉ riêng việc di chuột là còn hoạt động ngoại lệ
    Cuối cùng tôi phải đổi sang Window Event nhưng vẫn thấy bất tiện