Vlákno názorů k článku XLibre jako další bouře ve sklenici vody, nebo spása pro X.Org? od comodoro - Iniciativě držím palce. Wayland z mého pohledu nesmyslně...
-
Iniciativě držím palce. Wayland z mého pohledu nesmyslně zařízl některé funkce pro automatické ovládání desktopu. To bylo před několika lety, možná už je to jinak. Ale tehdy mi nějaký vývojář napsal, že to tak prostě je kvůli bezpečnosti. To na 1 stranu chápu, na 2. stranu vzít lidem možnost i si to nastavit je zbytečné omezení.
-
To není nějaké uznávání chyby. To je prostě standardní vývoj nové generace řešení. Návrh Xorgu vznikl v 80. letech, kdy počítače vypadaly úplně jinak, a táhne si za sebou 40 let vývoje. Kdyby nové řešení reimplementovali 1:1, tak dostanou řešení se stejnými problémy jako Xorg. Proto je Wayland základní protokol, který víceméně řeší jen základní komunikaci mezi kompozitorem a klienty. A na zbytek jsou tu rozšiřující protokoly Waylandu a portály xdg. Tam si vývojáři nikdy žádné principiální hranice nedávali. Prostě když je po něčem dostatečná poptávka, tak se na to implementuje řešení. Jen to chvíli trvá, protože jsou to otevřené protokoly, na kterých se musí shodnout většina komunity, takže diskuse je občas zdlouhavá, a požaduje se po tom, aby to nebylo ve stylu Xorgu "všichni mají přístup ke všemu", ale aby to bylo v bezpečnostním standardu, který si komunita kolem Waylandu stanovila.
-
S lidmi z Valve jsme HDR řešili. Já jejich přístup naprosto chápu: oni mají roadmapu vydávání hardwaru a podle toho deadliny na implementaci. Oni si nemůžou dovolit čekat, až se komunita dohodne na podobě protokolu apod. Udělat si návrh a implementaci in house bude vždy rychlejší, než se domlouvat na otevřeném protokolu pro všechny. Na toto ta tvorba otevřených řešení nebude nikdy dost rychlá. A možná to je tak dobře, protože ty diskuse se táhnou, ale zpravidla přinesou dlouhodobě nejlepší řešení pro všechny strany. Asi by taky nebylo úplně ideální, když by podobu podpory HDR v Linuxu na dalších 20 let definovalo to, co parta pár vývojářů ve Valve dala dohromady v časovém presu bez ohledu na potřeby ostatních.
-
Steam Deck/HDR je trochu jina situace ktera ovsem vyborne ilustruje zasadni rozdily mezi FOSS a komercnim software.
Steam Deck/HDR je komercni produkt ktery Valve vydela penize takze do toho radi neco investuji. Steam Desk pohani cipy od AMD, AMD dodalo pro Steam Desk closed-source drivery a take podporu pro X11 (HDR delalo AMD, ne Valve).
Takze na Steam Decku bezi neco jineho nez na beznem desktopu, stejne jako Android je i neni Linux.
Pokud mate zakazniky, vizi a cil pak neni problem udelat cokoliv. Za soucastny Linuxovy otevreny desktop ale nikdo neni ochotny zaplatit ani korunu, tak se nedivte ze vypada jak vypada (nerikam ze to je nutne spatne).
EDIT: Ovsem AMD se take vyrazne angazuje v opensource HDR implementaci - napr. v cervenci budou poradat treti kolo HDR hackfestu.
24. 6. 2025, 07:54 editováno autorem komentáře
-
Ked som pred par rokmi po tom patral, tak som nasiel, ze boli uz minimalne 2 pokusy ako nejaky subset tych funkcii spravit cez protokol. A tie neboli akceptovane. Nesledujem to aktivne, ale vnimal som to ako aktivne odmietanie alebo prinajmensom ignoraciu.
Clovek, ktory chce nejaky protokol, si musi ten protokol napisat, implementovat a nakoniec udrzovat vo vlastnom forku wlroots, ktory nema sancu rozsirit sa ani odovzdat do udrzby upstreamu.
7. 7. 2025, 09:57 editováno autorem komentáře
-
V tom case neexistoval zvoleny X11 server. Boli rozlicne xservery, od Xsun po Xming. A nielen softverove, ale aj hardverove - slzu zatlacam pri spomienke na DEC VXT200. Pre linux existovalo niekolko implementacii, vratane proprietarnych -- ktorych biznis case bol, ze podporovali graficke karty, co XFree86 nepodporoval. A kazdy z nich mal ine rozsirenia.
Vo window manageroch bol tiez dobry bordel, kazdy si implementoval co chcel a aplikacie nevedeli, s cim mozu pocitat alebo nie. Samozrejme, aj ked na na niecom dohodlo - napriklad na ICCCM v jeho jednotlivych verziach - kazdy z nich mal iny nazor, ako standard interpretovat a implementovat, cim sa chaos este prenasobil.
Protokoly sa neimplementuju v samotnych DE, ale v kompozitore (teda napriklad v Gnome: v mutteri, nie v gnome-shell. V KDE v kwin, nie v plasmashell). Doslo k zluceniu toho, co bol kedysi X server a window manager (ale window manager; nie shell! A teda, ciastocne... cast sa presunula opacnym smerom do jadra, dnes uz X server neriesi ovladace, ked ma KMS a /dev/input) a dovod je... zjednodusenie. Ono synchronizovat kompozitor s displej serverom, ked bezia v dvoch rozlicnych procesoch nie je jednoduche, nebodaj po tom chciet este aj frame perfect vysledok; tak wayland to ma in-process a problem je vyrieseny.
-
Nemusí, může použít např. wlroots. Dokonce bych řekl, že ta situace může být dlouhodobě jednodušší než u X11, protože rozhraní mezi WM a implementací společných věcí ve Waylandu se může rozvíjet nezávisle na Waylandu. Klidně zítra může někdo udělat fork wlroots, rozbít půlku zpětné kompatibility, a pokud se tím něco zásadně zlepší, některé WM na to přejdou. Kompatibilita s aplikacemi na Waylandu ale zůstane.
