Wayland compositor और window manager का अलगाव

• मौजूदा Wayland वातावरण में compositor और window manager एक ही प्रोग्राम में जुड़े हुए होते थे, लेकिन river 0.4.0 इन्हें अलग processes में विभाजित करता है
• नया river-window-management-v1 protocol window manager को window placement, key bindings जैसी policies पर पूरा अधिकार देता है, जबकि frame perfection और performance को बरकरार रखता है
• यह संरचना input latency के बिना काम करती है, और जटिल tile layouts में भी atomic state updates के जरिए साफ़-सुथरी rendering सुनिश्चित करती है
• अलग की गई संरचना की वजह से window manager को स्वतंत्र रूप से develop और restart किया जा सकता है, और high-level languages में implement करना भी आसान हो जाता है
• यह दृष्टिकोण Wayland ecosystem में window managers की विविधता बढ़ाने को प्रोत्साहित करता है, और river पहले से ही 15 से अधिक compatible managers को support करता है

---

Wayland की पारंपरिक संरचना और river का अलगाव वाला दृष्टिकोण

• पारंपरिक Wayland compositor display server, compositor, और window manager — इन तीन भूमिकाओं को एक ही process में एकीकृत करता था
  • display server input events को route करता है और kernel को display buffer सौंपता है
  • compositor कई windows के buffers को मिलाकर अंतिम स्क्रीन तैयार करता है
  • window manager window placement, key bindings जैसी user policies को संभालता है
• X11 संरचना में display server एक अलग process के रूप में मौजूद होता था, जिससे अनावश्यक round-trip communication और latency पैदा होती थी
• Wayland ने इसे हल करने के लिए server और compositor को एकीकृत किया, लेकिन window manager को भी साथ जोड़ना अनिवार्य नहीं है
• river इस जुड़ाव को तोड़कर window manager को एक अलग प्रोग्राम के रूप में अलग करता है

river-window-management-v1 protocol के design principles

• इसे इस तरह design किया गया है कि window manager के पास अधिकतम control हो, लेकिन Wayland के फायदे भी बने रहें
• हर frame या input event पर round-trip communication की ज़रूरत नहीं पड़ती, इसलिए input latency नहीं होती
• frame perfection बनाए रखी जाती है: जब कोई window खुलती है या उसका size बदलता है, तो बिना gap या overlap के screen update सुनिश्चित होता है
  • rendering को तब तक रोका जाता है जब तक सभी windows नया buffer submit न कर दें, लेकिन तय समय से अधिक होने पर timeout के साथ आगे बढ़ा जाता है
• application जितनी अच्छी तरह implement की गई हो, उतनी ही पूर्ण frame synchronization संभव होती है

state machine आधारित window management संरचना

• protocol state को window management state और rendering state में अलग करता है
  • window management state: window size, fullscreen status, keyboard focus, key bindings आदि
  • rendering state: window position, order, decorations, crop आदि
• बदलावों को atomic updates (manage/render sequence) के रूप में समूहित करके process किया जाता है
• compositor sequence की शुरुआत करता है, और जब state changes नहीं होते तब window manager idle state में बना रहता है
• यह संरचना river-classic, sway आदि में पहले से मौजूद अवधारणाओं को स्पष्ट और औपचारिक रूप देती है

अलग संरचना के फायदे

• window manager developers पूरा compositor implement किए बिना सिर्फ policy पर focus कर सकते हैं
• debugging और restart आसान हो जाते हैं, और window manager crash होने पर session समाप्त नहीं होता
• garbage-collected languages में लिखने पर भी performance गिरती नहीं, और frame delay के बिना काम होता है
• पहले से ही 15 से अधिक river-compatible window managers मौजूद हैं, और X11 जैसी विविधता बढ़ने की उम्मीद है

सीमाएँ और आगे की योजना

• फिलहाल यह protocol सिर्फ 2D desktop environments को support करता है, VR जैसी चीज़ें अभी supported नहीं हैं
• जटिल visual effects (जैसे हिलती-डुलती windows) इसकी scope से बाहर हैं, हालांकि simple animations संभव हैं
• आगे custom shaders support पर विचार हो रहा है, लेकिन यह short-term plan नहीं है
• river 0.4.0 रोज़मर्रा के उपयोग के लिए पर्याप्त है, और 1.0.0 version से पहले UX improvements की योजना है
• development जारी रखने के लिए liberapay, GitHub Sponsors, Ko-fi के जरिए समर्थन की अपील की गई है

उदाहरण और gallery

• river पर चलने वाले कई window managers के उदाहरण दिए गए हैं
  • Canoe: एक क्लासिक stacking window manager
  • reka: Emacs-आधारित window manager
  • tarazed: focused desktop environment
  • rhine: recursive, modular window management और animation support
• इनके अलावा भी कई river-compatible window managers मौजूद हैं

[GN⁺]

Hacker News की राय

• टिप्पणियों में Wayland (protocol) को लेकर नाराज़गी को समझना मुश्किल लगता है
  wlroots जैसी लाइब्रेरी पहले ही भारी हिस्सों को संभाल चुकी हैं, और अब river उससे भी ऊँचे स्तर का abstraction देता है
  Wayland प्रोजेक्ट यह abstraction शायद पहले दे सकता था, लेकिन मेरा मानना है कि यह काम कोई भी कर सकता था
  आख़िरकार हमें यह प्रगति मुफ़्त में मिल रही है, इसलिए यह शिकायत करना ठीक नहीं लगता कि किसी और ने हमारे लिए यह काम नहीं किया

  • लगता है कि Wayland ने शुरुआत में screenshot पर रोक जैसी सिद्धांतवादी स्थिति अपनाई, वहीं से समस्या शुरू हुई
    accessibility के मुद्दों को भी security risk माना गया, जिससे design और मुश्किल हो गया, और अब Agentic AI के दौर में यह दिलचस्प मोड़ बन सकता है
    Pipewire, Wayland की छूटी हुई जगहों को भर रहा है, लेकिन फिर भी यह धारणा है कि user-friendly design अभी कमज़ोर है
    फिर भी Wayland, एक-दो क़दम पीछे जाने पर भी, कुल मिलाकर दो क़दम आगे बढ़ रहा है
  • नाराज़गी की जड़ Wayland community, खासकर GNOME खेमे के रवैये में दिखती है
    अक्सर जवाब यही रहता है, “मेरे तरीके से करो, नहीं तो निकलो,” और बाहरी अनुरोधों के प्रति लचीलापन कम है
    मुफ़्त में उपलब्ध होना अच्छी बात है, लेकिन Xorg के बंद होने और कोई विकल्प न होने की स्थिति में इसे ज़बरदस्ती आगे बढ़ाना समस्या लगता है

• इस प्रोजेक्ट को देखकर पहली बार लगा कि Wayland समय की बर्बादी नहीं है
  display server को window management तक अपने ऊपर लेकर इतना जटिल होने की ज़रूरत नहीं लगती
  मूल Wayland ने window manager और compositor को जोड़ा, शायद इसलिए कि वही सबसे कम विरोध वाला रास्ता था
  लेकिन remote access अभी भी समस्या है। X11 में जो ठीक चलता था, Wayland में उसमें काफ़ी bugs रहे

  • X11 में Xserver और window manager अलग थे, इसलिए शुरुआती window placement जैसी समस्याएँ सुलझाना मुश्किल था
    Wayland ने इन्हें जोड़कर यह हल किया, लेकिन इसके साथ दूसरे side effects भी आए
  • ज़्यादातर छोटे Wayland compositor, wlroots या smithay जैसी libraries इस्तेमाल करते हैं
    API boundaries अच्छी तरह तय हैं, इसलिए code sharing आसान है
    90-degree rotation bug compositor की समस्या है या wlroots की, यह जानने की उत्सुकता है
  • X11 में remote access बहुत बिखरा हुआ था। Wayland में EGL या Vulkan के ज़रिए layering ज़्यादा साफ़ हो सकती है, इसलिए यह उल्टा बेहतर भी हो सकता है
  • X11 में window manager decoration संभालता था, इसलिए उन्हें अलग करने पर messaging और configuration जटिल हो जाती है
  • संभव है कि desktop environments ने अपने-अपने ecosystem बनाकर सीढ़ी खींच ली हो

• लगता है कि Wayland की कई design flaws में से एक को अब जाकर ठीक किया जा रहा है
  common protocol के स्थिर होने और window managers के X11 जितने mature होने में शायद 15 साल और लगेंगे
  और फिर आख़िर में कोई फिर कहेगा कि “मैं इससे बेहतर बनाऊँगा,” और Wayland छोड़कर नए सिरे से शुरू करेगा

  • इसलिए आजकल WSL या Virtualization Framework जैसी चीज़ें desktop Linux के लिए ज़्यादा व्यावहारिक समाधान लगती हैं
    UEFI की समस्याओं से जूझते-जूझते आख़िरकार Samsung DEX पर चला गया
  • Wayland को फिर से नया बनाकर भी नतीजा शायद ऐसा ही रहेगा
    सीमाएँ तकनीकी से ज़्यादा राजनीतिक समस्या लगती हैं

• 25 साल से Linux उपयोगकर्ता होने के नाते, 5 साल पहले Wayland पर आने के बाद से screen tearing की समस्या के बिना काफ़ी संतुष्ट हूँ
  developer के लिए काम बढ़ सकता है, लेकिन user के लिए यह साफ़ सुधार है

  • फिर भी window shading फीचर का न होना खलता है
    कहीं ऐसा न हो कि CDE की पुरानी सुविधाओं को याद करने वालों की तरह मैं भी यही बात बार-बार करता रहूँ

• River, अलगाव से पहले भी शानदार था। आगे यह कैसे बढ़ेगा, इसे लेकर उत्सुक हूँ
  थोड़े समय के लिए Niri पर गया था, लेकिन कभी न कभी वापस लौटने का इरादा है
  Xmonad users के लिए River शायद सबसे उपयुक्त होगा

  • मैं भी Xmonad इस्तेमाल करता हूँ, लेकिन Hyprland master/slave stack को ठीक से संभाल नहीं पाया
    River में क्या नया window, अभी चुने हुए window के ऊपर insert होता है?
    अलग होने के बाद window manager वाले प्रोजेक्ट का नाम क्या होगा, यह भी जानना चाहता हूँ

• अंत में हम X11 की सुविधाओं को एक-एक करके फिर से बना रहे हैं
  शायद किसी दिन Wayland windows को अपनी position का पता चल सकेगा

  • आदर्शवादी लोग अब भी virtual 2D pixel grid तक को स्पष्ट रूप से परिभाषित करने से हिचकते हैं
    लगता है इसके लिए अभी काफ़ी इंतज़ार करना पड़ेगा
  • लेकिन अब ज़्यादातर GNU/Linux का इस्तेमाल headless servers या embedded systems में होता है, इसलिए इसका महत्व सीमित रह सकता है
    desktop की जगह शायद Android, ChromeOS, या Windows/macOS पर चलने वाले VM ले लेंगे

• मैं पूरी तरह customized River window manager इस्तेमाल करता हूँ
  Hyprland में डिफ़ॉल्ट रूप से सिर्फ BSP tiling मिलती थी, जो असुविधाजनक थी, लेकिन River में मनचाही equal tiling संभव है
  इस विभाजन ने मेरे workflow में बड़ा बदलाव किया है

  • अगर equal tiling चाहिए, तो hy3 देखना उपयोगी हो सकता है
    मैं भी पहले i3 user था, और hy3 की वजह से ही Hyprland इस्तेमाल कर पाया
  • मुझे भी Hyprland में ऐसी ही समस्या हुई थी, और आख़िरकार Niri पर जाकर एक स्थिर development environment मिला
    मेरी settings dotfiles में रखी हैं
  • BSP क्या होता है, यह पूछना चाहता हूँ

• मेरी समझ में Wayland की मुख्य design choices में से एक window manager और compositor का एकीकरण था
  इसे इस तरह क्यों बनाया गया, यह जानने की जिज्ञासा है

  • अगर window manager अलग process में asynchronous communication करे, तो frame sync की समस्या आती है
    Wayland ने इसे synchronous तरीके से संभालकर visual mismatch हटाने की कोशिश की
  • Wayland ने context switching को कम से कम रखने के लिए सब कुछ एक ही process में रखा
    यह नया protocol, उस performance advantage को बनाए रखते हुए graphics server और window manager को अलग करने की कोशिश है

• Wayland में plug-in style window manager को आसानी से बदल न पाना, X11 के मुकाबले सबसे बड़ा नुकसान लगता है
  जो लोग इस समस्या को हल करने की कोशिश कर रहे हैं, वे सच में क़ीमती हैं

  • दशकों से एक ही window manager इस्तेमाल करने वाले व्यक्ति के लिए, बिना किसी पूर्ण replacement interface के Wayland पर जाना मुश्किल है
    उम्मीद है River या Wayback जैसी layers यह भूमिका निभाएँगी
  • यह पाबंदी नए WM·DE development के लिए भी बड़ी रुकावट है
    मेरे पास भी कुछ प्रयोगात्मक desktop ideas हैं, लेकिन तेज़ iteration के लिए X11 से शुरू करना मजबूरी है
    Wayland में अब भी design-level कमज़ोरियाँ हैं
  • सच कहूँ तो, अगर एक implementation ही WM extension API दे दे, तो भी काफ़ी होगा
    standard में किसी खास structure को थोपने की ज़रूरत नहीं है
  • आदर्श रूप में, root Wayland server के नीचे user-specific Wayland server, उसके अंदर X11 server, और उसके ऊपर window manager वाली layered architecture सबसे साफ़ लगती है

• 15 साल से i3 इस्तेमाल कर रहा हूँ, और ऐसे प्रोजेक्ट देखते ही हर बार सवाल उठता है कि Wayland की ज़रूरत ही क्यों है
  X11 में कमियाँ हैं, लेकिन जो चाहिए वह लगभग सब किया जा सकता है
  Wayland हमेशा ज़्यादा friction वाला लगता है

  • मैं KDE 5 के समय से Wayland इस्तेमाल कर रहा हूँ, और HiDPI scaling शानदार रहा है
    laptop user होने के नाते यह बहुत बड़ा फ़ायदा था, और VRR या HDR support भी X.org की तुलना में कहीं आसान है
  • user के नज़रिए से देखें तो यह बस ठीक से काम करता है
    per-display DPI adjustment, screen tearing की रोकथाम, और apps द्वारा बिना अनुमति screen recording को रोकना, ये सब मूल रूप से हल हो जाते हैं
  • i3 से sway पर जाने की वजह भी DPI support ही थी
    अब Xorg.conf छेड़ना नहीं पड़ता, जिससे जीवन आसान हुआ है
    आज भी हर monitor पर अलग scaling ratio इस्तेमाल कर रहा हूँ
  • X11 में high refresh rate सेट करना हमेशा झंझट रहा है
  • हाल में जो समस्या आई, वह यह थी कि Wayland DeviceEvent को support नहीं करता
    मुझे ऐसा फीचर चाहिए था जिसमें window inactive होने पर भी input मिले, लेकिन अपवाद के तौर पर सिर्फ mouse movement चलता है
    आख़िरकार Window Event पर बदलना पड़ा, लेकिन यह अब भी असुविधाजनक है