Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

X.Org a Wayland — czyli stary król i młody następca tronu

System okien - co to jest?

System okien jest to komponent graficznego interfejsu użytkownika (GUI) odpowiadający nie tylko za obsługę grafiki, ale też za obsługę myszki, klawiatury i innych urządzeń wejściowych. Udostępnia on menedżerom okien prostokątne obszary (zwane oknami), w których następnie rysowane są elementy interfejsu, takie jak przyciski, menu, scrolle itd.

System okien zajmuje się jednak najbardziej niskopoziomowymi rzeczami. Za to co widzimy (wspomniane wyżej elementy interfejsu) odpowiadają inne składniki, takie jak menedżery okien czy biblioteki widżetów. Ogólnie w wielu graficznych systemach operacyjnych zawierających zintegrowane (i niedostępne nigdzie indziej) systemy okien, te składniki są często łączone i nie ma wyraźnej granicy pomiędzy systemem okien a menedżerem okien. Taka granica jest widoczna w najpopularniejszym systemie okien dostępnym na systemy Uniksowe: X Window System (jego najpopularniejszą dzisiaj implementacją jest X.Org). Wayland jednak zwraca się ku komercyjnym rozwiązaniom. Ale zanim przejdziemy do opisu architektury, to najpierw trochę historii.

Historia X Window System oraz Wayland

X Window System (będę go określał w skrócie X/X11) nie jest pierwszym systemem okien operującym na bitmapach. Tak samo na bitmapach operowały systemy operacyjne (a właściwie ich systemy okien) dołączane z komputerami takimi jak: Xerox Alto, Xerox Star, Apple Lisa, Apple Macintosh itd.

Historia X wiąże się z projektem zwanym Project Athena. Był to projekt tworzony wspólnie przez MIT, IBM, Digital Equipment Corporation, który wystartował w 1984 roku, a trwał aż do połowy roku 1991. Jego głównym celem była poprawa jakości edukacji na uniwersytetach. Chciano, żeby użytkownik mógł podejść do dowolnej stacji roboczej i swobodnie przeglądać pliki czy aplikacje bez większych różnic pomiędzy interfejsem a usługą, zupełnie jak w dzisiejszym internecie. Do osiągnięcia tego celu potrzebowano jednak niezależnego od jednej platformy systemu graficznego, który ujednolici produkty różnych producentów.

Problem postanowiono rozwiązać tworząc protokół, który będzie pozwalał uruchamiać zarówno aplikacje lokalnie jak i przez sieć. Na Uniksa sportowano (w połowie 1983 roku) system okien W z systemu operacyjnego V. Jednakże, pracował on sporo wolniej (nawet 5 razy), niż na swoim natywnym systemie operacyjnym. W maju 1984 roku Scheifler zastąpił synchroniczny protokół W asynchronicznym protokołem, który został nazwany X. Pierwsza wersja X została pierwszym systemem okien oferującym prawdziwą niezależność od platformy i producenta.

X zaczął rozwijać się szybko, dzięki pracy Scheifler’a, Gettys’a i Ron’a Newman’a. W styczniu 1985 roku została wydana wersja 6 nowego systemu okien. DEC (Digital Equipment Corporation) postanowiła go wykorzystać w swojej stacji roboczej Ultrix. Ich inżynierowie sportowali X6 na QVSS pracujący na MicroVAX. W drugim kwartale 1985 roku X wraz z wersją 9 dostał obsługę kolorów działającej na VAXstation-II/GPX.

X rozwijał się dalej będąc portowany na coraz to więcej platform. MIT zdecydowało się wydać X10R3 (luty 1986 rok) na wolnej licencji MIT (zwanej też licencją X11), a także zdecydowało się na tej licencji wydawać wszystkie przyszłe wersje. To działanie znacząco zwiększyło popularność X. 15 września 1987 roku wydano jedenastą wersję protokołu, zwaną X11. Ta wersja protokołu do dzisiaj jest stosowana w dzisiejszych implementacjach. Stąd też popularna nazwa: X11.

W styczniu 1988 roku powołano MIT X Consortium jako grupę non-profit z Scheifler’em na czele. Jej celem było ustalanie kierunku rozwoju X w neutralnej atmosferze, zarówno biorąc pod uwagę komercyjne jak i edukacyjne interesy. W 1993 grupa ostatecznie odłączyła się od MIT i na jej miejsce powołano X Consortium, Inc. (korporacje typu non-profit). W 1995 wzieła pod swoje skrzydła toolkit Motif oraz jedno z najstarszych środowisk Uniksowych – Common Desktop Environment, w skrócie CDE. Na początku roku 1997 przekazano zarządzanie dalszym losem X do The Open Group (grupę zajmującą się rozwojem otwartych standardów. Posiada ona też prawa do nazwy UNIX). Wydana przez nich wersja X116.4 przestała być wolnym oprogramowaniem – była darmowa do użytku tylko niekomercyjnego. Na skutek nacisku, głównie ze strony XFree86 (było gotowe na fork), The Open Group się ugięła i przywróciła X11 jako wolne oprogramowanie.

Jedna z pierwszych popularnych implementacji X11 nazywała się XFree86. Powstała ona w 1992 roku z projektu X386. Dostarczała ona implementację X11 dla komputerów kompatybilnych z IBM PC dla systemów Uniksowych. W połowie roku 1999 The Open Group powołało X.Org, które dostało pod nadzór X11R6.5.1 i wszystkie późniejsze. Jednakże rosnąca popularność Linuksa i dostarczanego razem z nim XFree86 spowodowała, że to XFree86 wprowadzało innowacje i nowości w X11. Na skutek zachęt różnych producentów dołączyło do The Open Group jako honorowy członek bez konieczności płacenia grupie. W 2003 roku X.Org praktycznie pozostawał nieaktywny, a główny prym w rozwoju X11 wiódł XFree86. Jedną z ważniejszych osób uczestniczących w rozwoju implementacji XFree86 był Keith Packard.

Niestety, zmiana licencji części kodu XFree86 w lutym 2004 roku na bardziej restrykcyjną licencje zakończyła jego panowanie. Nowa licencja została uznana przez Free Software Foundation oraz Debiana za niekompatybilną z GNU GPL. Nie spodobało się to środowisku Open Source, które uznało to za pogwałcenie tradycji X11, jako wolnego i niezależnego systemu okien. Krótko po tym rózne osoby należące do X.Org oraz do freedesktop.org powołali X.Org Foundation, do którego dołączył m.in. Keith Packard, a The Open Group przekazało nowej organizacji prawa i nadzór nad domeną x.org. Sforkowano także ostatnią wersję XFree86 na wolnej licencji i nową implementację nazwano X.Org Server. Wielu deweloperów wcześniejszej implementacji przeniosło się także do nowej. Pomimo, że rozwój XFree86 trwał jeszcze kilka lat (ostatnią wersje wydano 15 grudnia 2008 roku), to jednak na zawsze utracił swoją popularność i został zastąpiony X.Org Server. Nowy serwer stał najpopularniejszą implementacją X11 i do dzisiaj jest rozwijany i używany. Jest głównym systemem okien w większości systemów uniksowych (np. Linux, *BSD), a jego porty znaleźć można nawet na systemach takich jak Microsoft Windows, które z Uniksem mają niewiele wspólnego.

Jednakże trudno dostosować jest pomysł z ubiegłego wieku do wymagań dzisiejszych czasów. X11 z czasem stawał się coraz trudniejszy do rozwoju. Dodawano do niego rozszerzenia mające zapewnić obsługę nowego sprzętu i zaspokoić wymagania dzisiejszych konsumentów. Trzeba to było jednak robić tak, by zachować wsteczną kompatybilność. W X11 znajdziemy kilka API do obsługi jednej rzeczy. Na temat problemów trapiących X11 pojawił się news na portalu dobreprogramy, znajdziecie go tutaj. I tu właśnie wkracza Wayland. Kristian Hoegsberg, deweloper X.Org, który pracował nad AIGLX oraz DRI2 rozpoczął prace nad Waylandem w 2008 roku, jako poboczny projekt obok swojej pracy w Red Hat. Jako cel projektu Hoegsberg określił:
every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker.
każda klatka była perfekcyjna, mam na myśli to, że aplikacje będą w stanie kontrolować wyświetlanie wystarczająco dobrze, że nigdy nie ujrzymy rozrywania się obrazu, lagów, przerysowań czy migotań (tłumaczenie)
W 2010 roku Wayland stał się projektem freedesktop.org. Początkowo biblioteki serwera i klienta były pod licencją MIT, podczas gdy Weston i parę innych komponentów było pod licencją GNU GPL2, jednakże zastąpiono licencję GPL licencją MIT. Wayland nie ma nic wspólnego z X11 – to całkowicie nowy projekt, który dzięki zerwaniu ze starym protokołem ma uniknąć jego problemów i znacznie lepiej sprostać wymaganiom nowych czasów. Pierwsza wersja (0.85) ujrzała światło dzienne w lutym 2012 roku. Wersja stabilna (1.0) została wydana w październiku tego samego roku. Na dzień pisania tego wpisu najnowsza wersja to 1.11 wydana 1 czerwca 2016 roku.

Różnice w architekturze X.Org oraz Wayland

Oba projekty, pomimo że odpowiadają za to samo, to jednak różnią się mocno założeniami.

Architektura: W X11 menedżer kompozycji to osobna, opcjonalna aplikacja. Wayland łączy ze sobą serwer wyświetlania oraz menedżer kompozycji, a także przyjmuje część funkcji menedżera okien, który w X11 jest osobną aplikacją działającą po stronie klienta.

Kompozycja: W X11 obsługa kompozycji jest opcjonalna, lecz w Waylandzie jest już obowiązkowa. Ponadto w X11 kompozycja jest aktywna, czyli kompozytor musi pobrać wszystkie dane pikseli, co powoduje opóźnienia. Kompozycja w Waylandzie jest pasywna, a więc kompozytor może bezpośrednio pobierać dane pikseli od klientów.

Wyświetlanie: Serwer X11 jest sam w stanie wyświetlać dane, Wayland jednak nie posiada żadnego API do wyświetlania, lecz część zadań przekazuje klientom (wyświetlanie fontów, widgetów itd.). Dekoracje okna mogą być wyświetlane zarówno po stronie serwera (przez kompozytor) jak i po stronie klienta (przez toolkit).

Bezpieczeństwo: Wayland izoluje wejście i wyjście każdego okna, zachowując integralność, czego nie potrafi X11. Ponadto więcej rzeczy w Waylandzie jest wykonywane po stronie klienta, co wymaga uruchomienia mniejszej ilości kodu z prawami administratora, niż w X11.

Komunikacja między procesami: X11 oferuje metody komunikacji pomiędzy procesami. Używane są m.in. do implementacji drag-and-drop (transferu danych pomiędzy oknami). Protokół Waylanda nie posiada żadnych metod komunikacji i implementacja takowych musi być zrealizowana przez środowisko graficzne, bądź przez trzecie projekty.

Sieć: X11 został zaprojektowany jako transparentny sieciowo, co oznacza, że nie ma dla niego różnicy, czy serwer i klienci działają na tej samej maszynie, czy komunikują się przez sieć. Wayland sam w sobie nie jest transparentny sieciowo i nie posiada metod komunikacji przez sieć. Zdalna obsługa musi być zaimplementowana przez kompozytor.

W X11 jest wyraźny podział pomiędzy serwerem wyświetlania, a menedżerem okien czy menedżerem kompozycji (chociaż część menedżerów okien X11, jak Mutter czy KWin, posiadają wbudowane menedżery kompozycji). W Waylandzie nie funkcjonuje taki podział. Serwer wyświetlania, menedżer okien i menedżer kompozycji to teraz jedna aplikacja zwana kompozytorem Waylanda. Jest to podejście podobne do stosowanego dzisiaj w Microsoft Windows czy OS X (macOS). Pomimo, że zwiększa to skomplikowanie, to jednak zwiększa też wydajność, bowiem kompozytory operują znacznie bliżej sprzętu, niż menedżery okien X11. Serwerem okien w przypadku X11 nazywamy serwer X (np. X.Org Server), w przypadku Waylanda jest to kompozytor (np. Weston). To serwer odpowiada za wyświetlanie wszystkiego i obsługę urządzeń wejściowych. Przyjmuje także żądania klientów. Klientem w X11 jest menedżer okien, oraz aplikacje na nim działajace, w Waylandzie jest to aplikacja pracująca na danym kompozytorze. Warto też wspomnieć o innej różnicy – X11 celował w bycie niezależnym od systemu. Wayland to projekt Linuksowy i robi użytek z mechanizmów dostępnych w jego kernelu – nie jest więc tak łatwo portowalny na inne platformy, jak X11.

Sytuacja Waylanda dzisiaj

Wayland jest w ciągłym rozwoju i jest podawany jako następca X11. Część popularnych toolkit’ów posiada już wsparcie dla niego, m.in. GTK+3, Qt5, SDL, GLFW itd. Nieco gorzej wygląda sprawa w środowiskach na Waylanda. Poza Westonem, będącym przykładowym kompozytorem (został stworzony po to, by twórcy kompozytorów mieli przykład jak powinien być napisany kompozytor Waylanda), swoje wsparcie dla niego mają też Mutter (menedżer okien GNOME3) oraz KWin (menedżer okien KDE), oraz wiele innych. Z dużych środowisk, które uruchomimy dziś na Waylandzie (nadal trwają pracę nad portem, więc nie wszystko może pracować jak należy) należy wymienić GNOME3, KDE Plasma 5 oraz Enlightenment. Dostępnych jest też część pomniejszych środowisk, jak np. Hawaii Desktop Environment. Tizen oraz Sailfish OS są zbudowane z użyciem Waylanda.

Nieco gorzej wygląda sprawa ze sterownikami. Obecnie Wayland działa tylko na otwartych sterownikach. Fglrx (zwany też Catalyst, bądź Crimson) został porzucony przez AMD i zastąpiony nowym, więc obsługi Waylanda nie dostanie nigdy. Nowy sterownik AMD (zwany AMDGPU-Pro) również nie obsługuje Waylanda, uruchomimy go jednak na otwartej wersji tego sterownika. nVidia wprawdzie dodała wsparcie do Waylanda w swoim zamkniętym sterowniku, jednak nie uruchomimy na nim żadnego środowiska – nVidia nie zaimplementowała GBM (wykorzystywanego przez chyba każdy kompozytor Waylanda), twierdząc, że EGL-Streams to lepszy pomysł. Intel posiada wyłącznie otwarte sterowniki, tak więc nie ma żadnego problemu z obsługą nowego systemu okien. Warto wspomnieć, że dzięki libhybris, Wayland potrafi obsłużyć sterowniki Androida.

Wayland posiada znacznie mniej natywnego oprogramowania niż X11. Aplikacje budowane z użyciem np. GTK+3 lub Qt5 takie wsparcie posiadają, jednak masę oprogramowania używa ich starszych wersji, bądź innych toolkit’ów bez wsparcia dla nowego protokołu. W celu rozwiązania tego problemu stworzono Xwayland. Jest to specjalna wersja X.Org Server, która została przerobiona tak, że pracuje jako klient Waylanda. Dzięki temu możliwe jest uruchomienie aplikacji X11. To rozwiązanie, pomimo niektórych problemów, pracuje całkiem sprawnie. Zdecydowana większosć aplikacji działa bez problemu dzięki temu – zdarzają się jednak aplikacje problematyczne.

Waylanda możemy zainstalować na chyba każdej popularnej dystrybucji Linuksa. Póki co żadna popularna dystrybucja nie używa go jako domyślnego. Jako pierwsza z taką inicjatywą wyszła Fedora – w wersji 25 domyślnie będzie używać Waylanda. Jak wspomniałem wcześniej, systemy mobilne takie jak. Tizen czy Sailfish OS również go używają.

Zakończenie

To już koniec tego wpisu. Czy Wayland zastąpi wysłużone „iksy”? Moim zdaniem jak najbardziej, tylko będzie to proces, który potrwa jeszcze kilka lat. System okien w Linuksie potrzebuje rewolucji i czegoś, co sprosta wymaganiom XXI wieku. Przede wszystkim najważniejsze jest wsparcie producentów, którzy napiszą sterowniki. Kto chce może używać Waylanda dzisiaj, o ile używa otwartych sterowników i zadowoli się środowiskami dostępnymi na ten system okien. Na powszechne wykorzystywanie przyjdzie nam jednak poczekać jeszcze trochę.

Źródła

Schemat okna

Logo X Window System

CDE

Schemat GUI

Weston

Logo Waylanda

Źródło 

linux

Komentarze

0 nowych
Farkas   11 #1 04.09.2016 02:34

Dobrze zebrane informacje, fajnie się czyta :-)

davidns   7 #2 04.09.2016 08:44

Tymczasem Ubuntu kombinuje jak zwykle ze swoim badziewnym wynalazkiem (Mir), zamiast wspomóc społeczność i rozwijać Waylanda...

  #3 04.09.2016 09:30

dragon321: Była propozycja ok. 2004 by uprościć X11, wyrzucić duplikujące się rzeczy z głównej gałęzi do oddzielnej biblioteki i część api przenieść bezpośrednio do jądra. Kilka osób powiedziało, że szkoda pracy, a testy tego rozwiązania były obiecujące. Wydajność wzrosła i bezpieczeństwo także, ale kosztem kompatybilności części oprogramowania.
Główną zaletą X11 jest właśnie obsługa sieci i możliwość używania na terminalach natywnego środowiska z pełną akceleracją. Tak grałem z kolegami mając w domu terminale HP z jakimś słabo wspieranym układem graficznym (chyba SIS) oraz serwer z 2 Xeonami i dwoma kartami nvidii. Na Windowsie w wersji serwer nie chciało to działać.

dawidd6   8 #4 04.09.2016 11:42

Kolejny przyjemny artykuł. Dzięki

KoczurekK   10 #5 04.09.2016 11:42

@davidns: Mir nie jest taki zły, pasował im bardziej niż Wayland to używają. Cannonical to korporacja a te istnieją po to by zarabiać. Takiemu RedHatowi aktywne rozwijanie Linuksa jest po drodze, ale Cannonical? Nie bardzo.

Co do samego wpisu – miło się czytało, powinno być takich więcej. :D

  #6 04.09.2016 12:05

Co to jest GBM i EGL-Streams?

flecht   7 #7 04.09.2016 12:49

@KoczurekK: "Cannonical to korporacja a te istnieją po to by zarabiać."
Zdaje się, że oni akurat nie zarabiają. ;)

Anonim (niezalogowany): "Co to jest GBM i EGL-Streams?"
W dużym uproszczeniu: proponowane sposoby komunikacji Waylanda (kompozytorów) ze sterownikami, przy czym GBM jest szeroko wspierany, a EGLStreams nie.

Autor edytował komentarz w dniu: 04.09.2016 13:06
  #8 04.09.2016 13:16

Proszę zapoznać się z pisownią odmiany nazwisk obcojęzycznych w języku polskim. Wykładnia dostępna jest we wstępie do każdego słownika ortograficznego.
Nadużywanie apostrofu jest błędem.

Loombago   9 #9 04.09.2016 13:19

@flecht: Czytałeś ich sprawozdania finansowe czy tak Ci się po prostu wydaje?

flecht   7 #10 04.09.2016 13:26

@Loombago: Nie najświeższe źródło:
https://www.phoronix.com/scan.php?page=news_item&px=MTU3MDg

Jak masz lepsze/nowsze, to się podziel.

Loombago   9 #11 04.09.2016 13:32

@flecht: Nie mam i znaleźć nie mogę stąd zastanawiam się skąd masz informacje o bieżącej sytuacji.

flecht   7 #12 04.09.2016 13:42

@Loombago: Najnowsze, jakie znalazłem:
https://beta.companieshouse.gov.uk/company/06870835/filing-history/MzEzNTg1NzA5N...
(mam nadzieję, że link zadziała :P)
Jeżeli dobrze to czytam, to są prawie 14,5 M$ pod kreską.

KoczurekK   10 #13 04.09.2016 13:55

@flecht: Też tak wyczytałem, chyba jednak nie wyszła im ta polityka za bardzo. D: Dobrze, że przerzuciłem się ostatnio na niezależną od Canonicala dystrybucję.

muska96   9 #14 04.09.2016 13:55

@dragon321 Bardzo dobry wpis, miło się czyta. Kilka drobnych uwag:
- Fedora 25 będzie miała włączony domyślnie Wayland, ale tylko na wersji z GNOME - tzw. spiny nadal będą pracować na X.Org.
- Z projektem Athena wiązał się również Xaw, czyli biblioteka do tworzenia prostych programów okienkowych (X athena widgets) - do dziś jest prawdopodobnie najbardziej uniwersalną biblioteką do GUI. Jest starsza inż Motif, ale nadal można tworzyć w niej okienka! --> http://imgur.com/a/oE4He
- Można też wspomnieć, że z CDE wciąż można korzystać, bo kod został otwarty i jest wykorzystywane do tworzenia retro desktopów np. https://mike632t.wordpress.com/2015/09/09/compiling-cde-on-debian-8-0-jessie/

Z resztą mam wrażenie, że do grania na Waylandzie jeszcze daleko... Choć w przypadku Intela i starszych Nvidii nie jest aż tak źle.

Loombago   9 #15 04.09.2016 14:07

@flecht: Działa dzięki, nie wygląda to dobrze, spodziewałem się lepszego wyniku (np. takiego jak w 2104) biorąc pod uwagę, że od dłuższego czasu jakby otrzeźwieli w swoich działaniach.

StarterX4   10 #16 04.09.2016 14:18

@Anonim (niezalogowany) #6: GBM jest rodzajem interfejsu zarządzania buforem oferowanym przez Mesa/DRM.
https://en.wikipedia.org/wiki/Mesa_(computer_graphics)#Generic_Buffer_Management
EGLStreams jest natomiast rozszerzeniem EGL, ale więcej o nim nie znalazłem.
https://pl.wikipedia.org/wiki/EGL
https://en.wikipedia.org/wiki/EGL_(API)

http://mesa-dev.freedesktop.narkive.com/qq4iQ7RR/egl-streams-trying-to-gain-some...

Autor edytował komentarz w dniu: 04.09.2016 14:18
  #17 04.09.2016 14:28

Common Desktop Environment bardzo przypomina Workbench 3.1 - system amigowski z MUI.
np.
http://scenergy.dfmk.hu/amiga/pics/mailer.gif

MacGregor   8 #18 04.09.2016 14:33

@Loombago: Marki i dobrego imienia nie odbudujesz w rok. Tak samo nie naprawią distro które z każdą wersją powiela i mnoży błędy. Teraz tylko idą z czasem coraz głębiej w stronę dna.

dragon321   10 #19 04.09.2016 16:29

@Farkas: Dzięki :)

@davidns: Mir znowuż nie jest tak daleko od Waylanda. Architekturą są dość podobne. Canonical stara się zostać drugim Apple i rozwijanie oraz wykorzystywanie czegoś społecznościowego byłoby mu nie na rękę. Pomimo, że Darwin (podstawa OSX) jest otwarty, to jednak sporo rzeczy jak właśnie system okien są zamknięte. Canonical zapewne chce robić w ten sam sposób - opierać się na otwartym Linuksie i dokładać swoje rzeczy. Niby są otwarte narazie, ale na skutek CLA Canonical może je zamknąć w każdej chwili.

?•?: O a tego to nie wiedziałem. Cóż, dzisiaj i tak część rzeczy, którymi kiedyś zajmowało się X, zostało przeniesione do jądra, albo do poszczególnych menedżerów okien. Fakt, transparentość sieciowa X to zaleta, Wayland takowej nie ma. Znaczy, nie ma sam z siebie, bo to musi zaimplementować kompozytor.

@dawidd6: Dzięki za opinie.

@KoczurekK: Dzięki.

Anonim (niezalogowany)(#6): Wybacz, że tego nie wytłumaczyłem, ale nie chciałem, by wpis się za bardzo nie rozpuchnął od mniej ważnych rzeczy. GBM odpowiada za zarządzanie buforami. EGL-Streams robi to samo, tylko w inny sposób. Według nVidii EGLStreams jest szybsze i ogółem lepsze.

@flecht: Konkretniej rzecz biorąc, to oba odpowiadają za zarządzanie buforami. Kompozytory używają GBM, a nVidia chce EGLStreams. nVidia to duża korporacja i nie ugnie się tak łatwo pod krzykami społeczności (w dodatku dość niewielkiej w porównaniu chociażby do Windowsa), a społeczność nie chce przerabiać masy kodu, by dopasować się do widzimisię jednej korporacji. Narazie AMD milczy w kwesti swojego zamkniętego sterownika. Otwarta wersja AMDGPU wspiera GBM, a w zamkniętej (AMDGPU-Pro) narazie głucho.

@muska96: Dzięki za opinie, a co do uwag:
Fedora: Cóż, główna wersja Fedory jest ze środowiskiem GNOME. Pozostałe to spinoffy tworzone przez społeczność. Tak jak Ubuntu Unity jest od Canonical, a pozostałe już nie. Dlatego pisząc "Fedora" miałem na myśli GNOME oczywiście. Tylko GNOME się przestawia na Waylanda, bo KDE nie wspiera go tak dobrze, a pozostałe wcale.

Athena: Faktycznie, lecz przytaczając nazwę 'Project Athena' chodziło mi o pokazanie gdzie padł pomysł stworzenia X.

CDE: Tutaj pełna racja. Nie rozpisywałem się na temat CDE, bo to nie o nim wpis. Warto tylko było napomknąć, bo to jedno z najstarszych środowisk na X.

W starszych Radeonach też tragedii nie ma. Jak masz odpowiednią kartę, to otwarty sterownik nie jest dużo słabszy niż zamknięty. Na moim dedyku (Radeon) otwarty też zapewnia znośną wydajność.

@StarterX4: Dobrze wyjaśniłem. Za pomocą EGLStreams też można zarządzać buforami. Z tego co mówi nVidia jest lepiej i wydajniej.

Anonim (niezalogowany)(#17): Może i się wzorowali, kto wie?

Autor edytował komentarz w dniu: 04.09.2016 16:30
  #20 04.09.2016 19:06

@StarterX4: dzięki

  #21 04.09.2016 19:43

dobry wpis, pytanie co z menadżerami okien openbox/fluxbox? śmierć naturalna czy pisanie wszystkiego na nowo jak się zachce twórcom?

  #22 04.09.2016 20:12

- Nie ma możliwości zadania aplikacji przechwytywania skrótów klawiatury czy wręcz całych akordów. Bo separacja, a to przecież dało się zrobić z Xliba! Teraz developerzy środowisk graficznych przez kolejne lata od wprowadzenia Waylanda będą przerzucali wzajemnie odpowiedzialność za to, kto ma zająć się skrótami klawiatury, czy ci od środowiska czy od przypadkowej biblioteki, której używa aplikacja... dopóki media nie wyżrą nam mózgów tak, że pisanie będzie nielegalne.
- Nie ma możliwości ustawienia jako końcówka niczego innego niż komputer. Chcesz zrzucić stan okna na grafoskop via ssh, bo pokazujesz komuś łącząc się przez komórkę? Wypchaj się, płać za przesył bitmapy, albo jeszcze lepiej zapłać kolesiom od TV. Używasz grafoskopu tylko do wizualizacji? Musisz mieć bezcelowe okienko żrące pół cennej przestrzeni. O systemach wbudowanych rysujących interfejsy na LCDkach 320x200 nie wspomnę.
- Jeden system, Jeden kompozytor, Jeden rodzaj okien. Ja mam Linuksa bo nie chcę mieć Maca! Cenię to, że jedno okno mogę ustawić jako nie do ruszenia, innemu zdejmuję dekoracje, zmniejszam i mam ładny np. diagram z adaptera sieci na pulpicie. Tutaj nikt się tym nie zajmie, bo po co, i będę mógł wstawić co najwyżej aplet z pogodą na zewnątrz.
- Jeżeli żeby zobaczyć PDF'a po japońsku Wayland ma w tle odpalać kaskadę aplikacji, to musi dużo czasu upłynąć zanim ten piramidalny hack stanie się używalny. Wcześniej wejdzie do powszechnego użytku znacznie lepszy hack: Hurd. A Wayland nie będzie zbyt dobrze z nim działał.

MrBeckham666   19 #23 04.09.2016 23:17

niezły :)

dragon321   10 #24 05.09.2016 00:00

@MrBeckham666: Dzięki :)

Loombago   9 #25 05.09.2016 08:44

@MacGregor: Mylisz markę z optymalizacją kosztów. C nie zarabia na kopiach Ubuntu tylko, a kopiach Ubuntu podpiętych np. pod Lunchpada, a firmy które korzystają z tego rozwiązania mają gdzieś przepychanki z kubuntu i temu podobne perypetie. Z takim bilansem jak C. zamyka się nierentowne projekty i skupia się na core przynoszącym zyski. Po wypracowaniu zysków można przejść w etap inwestycyjny gdzie saldo będzie na minusie przez jakiś czas i będą wykorzystywane rezerwy finansowe. C. zrobiło naprawdę wiele dla spopularyzowania linuksa i mam nadzieje, że wyjdą z dołka. Natomiast mam wrażenie, że Pani CEO ma niewiele do gadania, a Mark realizuje swoje utopijne wizje nie przejmując się specjalnie rentownością interesu. Dla mnie pomimo błędów i nietrafionych pomysłów to od zawsze jedyny projekt dytro linux, który ma jakąkolwiek szansę na wyjście z marginesu błędu statystycznego.

pocolog   12 #26 05.09.2016 08:58

Znowu bardzo dobry wpis.
Chociaż do Waylanda się po nim nie przekonałem, ale ja to już taka konserwa jestem ;)

  #27 05.09.2016 10:13

Wayland jes martwy wogóle jego założenia o konieczności porzucenia X są przedwczesną optymalizacją i nie trzymają się kupy.
Po pierwsze sam server X mógłby się stać kompozytorem 3D przezroczystym dla aplikacji i nie potrzeba żadnej rewolucji.
Po drugie sam protokół X można rozszerzyć aby lokalnie server i klient współdzielił bufory wyświetlania i omijać stos sieciowy taj jak to jest z GLX.
Po trzecie twierdzenie że zaszłości takie jak XFonts są problemem to bzdura bo XWayland też musi mieć ich obsługę aby zachować kompatybilność z 20 letnimi aplikacjami i nie wpływa to na wydajność.

  #28 05.09.2016 10:18

@Loombago: "Dla mnie pomimo błędów i nietrafionych pomysłów to od zawsze jedyny projekt dytro linux, który ma jakąkolwiek szansę na wyjście z marginesu błędu statystycznego."

chyba sobie kpisz
red hat - 1.534 billiona $ przychodu na 2014, novel podobnie, błąd statystyczny hahah dobre powiedz to projektowi debian, którego używają miliony przedsiębiorstw, osób prywatnych instytucji rządowych pozarządowych itp:
https://www.debian.org/users/

Wiesz linux to nie tylko zwykły ludzik kupujący nowego laptopa z okienkami zananej korpo...

  #29 05.09.2016 12:18

treściwy i przyjemny w czytaniu artykuł
pozdrawiam

dragon321   10 #30 05.09.2016 13:05

@pocolog: Dzięki.

Co do Waylanda, to dość ciężko się do niego dzisiaj przekonać. No niby jest lepszy i nowocześniejszy jak iksy. Ale X.Org ma sterowniki, aplikacje i masę środowisk. Wayland nie ma sterowników innych niż otwarte, mało natywnych aplikacji oraz mało środowisk z porządną obsługą. Jak napisałem we wpisie, jeszcze nie pora na rok Waylanda. Nastąpić raczej nastąpi, bo Red Hat wydaje się już powoli rzucać iksy (Fedora 25 ma domyślnie używać Waylanda), a oni mają duży wpływ na rozwój technologii linuksowych.

But_w_trawie   9 #31 05.09.2016 13:12

A jak wygląda sprawa współpracy na linii Wailand - Vulcan ? Moim zdaniem mogłoby to być bardzo dobre połączenie, bo Vulcan wspiera 3D, oraz jest wspierany przez niemal wszystkich najważniejszych producentów chipów grafiki. W dodatku jest wieloplatformowy. Współpraca Wailanda z Vulcanem mogłaby też ułatwić jego portowanie z linux na windows. a słuchawki z androidem? one i tak wszystko wyświetlają przez akcelerator 3D, płaskiej grafiki praktycznie nie używają.

Ewentualnie z innej beczki, Vulcan też ma warstwę emulacji OpenGL, tak więc Wailand mógłby pracować na oklepanym OpenGL. Rozwiązanie mniej wydajne, jednak jest do tego masa narzędzi deweloperskich. Tak wiem, OpenGL w zasadzie powinien być wycofywany, ale ten pomysł moim zdaniem zasługuje na ocenę przydatności.

Zresztą znalazłem troszkę na ten temat w wikipedii:
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)

dragon321   10 #32 05.09.2016 15:06

@But_w_trawie: Waylanda samego w siebie nie obchodzi ani OpenGL ani Vulkan. To czy wykorzysta jedno czy drugie to raczej sprawa kompozytora. Obsługa tego też nie jest w kwestii systemu okien, a sterowników i bibliotek. Ułatwić portowanie czego? Vulkan jest przecież dostępny na Windowsie i Androidzie, nie jest to projekt ograniczony wyłącznie do Linuksa, tylko otwarta specyfikacja tak jak OpenGL. Vulkan może być dostępny wszędzie, o ile GPU spełni jego wymagania i ktoś napisze sterownik z jego obsługą. Portowanie Waylanda na Windowsa czy Androida nie ma żadnego sensu, no chyba, że po to, by uruchamiać jego aplikacje (tak jak dzisiaj można na Windowsie uruchamiać aplikacje X11 wykorzystując np. Cygwin/X).

Vulkan ma emulacje OpenGL? Masz może jakieś źródło do tego, bo pierwsze słyszę? Jeżeli to prawda, to przecież ma to znikomy sens, bo po co bawić się w emulacje OGL na Vulkan, skoro można obsługiwać go natywnie? OpenGL jest obsługiwany na równi z Vulkan na Linuksie (nie przez żadną emulacje, a natywnie), a nawet na Windowsie. Ale nawet jeżeli, to nie potrafię sobie wyobrazić jak taka emulacja miałaby wyglądać. Vulkan jest niskopoziomowy, a OGL wysokopoziomowy. Emulacja tego jest średnio możliwa.

Vulkan nie ma nic wspólnego z OpenGL. Nie jest żadnym jego rozwinięciem i nie istnieje pomiędzy nimi żadna zależność. To całkowicie odrębne API do grafiki, tak jak odrębne są DirectX i OpenGL.

dragon321   10 #33 05.09.2016 15:12

@Anonim (niezalogowany): "dobry wpis, pytanie co z menadżerami okien openbox/fluxbox? śmierć naturalna czy pisanie wszystkiego na nowo jak się zachce twórcom?"
Dzięki za opinie.

A co z nimi? Podejrzewam, że będą musiały być napisane od nowa. Jak pisali twórcy KDE:
"Spora część KWin jest niezależna od systemu okien"

Ale taki KWin to znacznie bardziej rozbudowany projekt niż np. fluxbox i nie jest tylko menedżerem okien, ma też inne funkcje (np. wbudowanego kompozytora). fluxbox, openbox i inne podobne to menedżery okien X11, więc bez przepisania sporej ilości kodu nie ma szans, by wspierały natywnie Waylanda. Jak już stwierdziłeś: albo śmierć naturalna, albo ich twórcom będzie się chciało napisać je praktycznie od nowa.

redspl   6 #34 05.09.2016 22:53

Wpis fajny, ale osobiście nigdzie nie odchodzę od X11. Te tearingi, lagi i wszystkie mankamenty są dla mnie po prostu słodkie, a jestem do nich od dawna przyzwyczajony - po prostu nie mam potrzeby oraz chęci zmiany.

Loombago   9 #35 05.09.2016 23:02

@Anonim (niezalogowany): Powiedz ile z nich jest na desktopach? O serwerach nie wspominałem bo to oczywista oczywistość - jakby wspominać, że Windows jest popularny na desktopach. Większość serwerów www to Debian i Apache. RedHat nie zarabia obecnie na sprzedaży Red Hata na Desktopy tylko na wirtualizacji i chmurze. Desktopy Red Hata nigdy nie były popularne, a jedynie używane w ściśle określonych warunkach. To samo tyczy się Susła.

But_w_trawie   9 #36 06.09.2016 09:48

@dragon321: Gdzieś na jednej ze stron było zestawienie właściwości vulcana, że m.in. podczas prac standaryzacyjnych (po przejęciu Mantle) została dodana emulacja OpenGL, i że dzięki temu za plecami tej emulacji następuje równoleglenie rysowania grafiki. Niestety nie potrafię teraz tej strony odnaleźć. Było to przy okazji jakiegoś benchmarka gier, gdzie gry bazujące naweg na OpenGL zyskiwały na wydajności.

But_w_trawie   9 #37 06.09.2016 09:58

@Loombago: Co do RedHata, sami sobie zamknęli drogę do desktopów. W pewnym momencie nie dało się już bezpłatnie pobrać i używać redhat linux, i powstały klony, co polegało na odarciu oryginalnego redhata z wszelkich komponentów (głównie loga) które nie spełniają wymogów wolnego oprogramowania, bo otwarte nie oznacza wolne. przykładem jest choćby Centos. a na czym zarabia redhat? tak naprawdę kupując redhata (w sensie kopii systemu), kupuje się czasową subskrypcję na wsparcie. ale firma redhat jak słusznie zauważyłeś, na samym systemie zarabia obecnie niewiele. za to nieźle zdziera na rozwiązaniach opartych o javę, np. jboss który biznesowo jest starszną wtopą ze względu na sposób jego licencjonowania i konieczność czasowego płatnego odnawiania subskrypcji. ale cóż, mają taki właśnie model biznesowy, mają do tego prawo.

  #38 06.09.2016 13:49

@redspl: "osobiście nigdzie nie odchodzę od X11. Te tearingi, lagi i wszystkie mankamenty są dla mnie po prostu słodkie, a jestem do nich od dawna przyzwyczajony - po prostu nie mam potrzeby oraz chęci zmiany."

ale prawda jest taka że xorg jest dziurawy jak ser szwajcarski do tego ma straszny burdel w kodzie coś co posiada jeszcze rozwiązania z lat '80 poprzedniego stulecia, jest łatane i zaklejane do dzisiaj nie może być wydajne a już tym bardziej bezpieczne. Także wcześniej czy później xorg umrze i zostanie całkowicie zastąpiony przez Waylanda. Osobiście też mi się nie spieszy do Waylanda, dostępność tylko wolnych sterów graficznych jak najbardziej mi pasuje bo tylko takich używam ale zastępstwa openboksa raczej szybko nie znajdę na Waylandzie a użytkowanie kade czy tym bardziej gnoma doprowadza mnie do szewskiej pasji i jak na razie nie wyobrażam sobie pracy z tymi środowiskami...

dragon321   10 #39 06.09.2016 14:50

@But_w_trawie: To ciekawe. Jeżeli wydajność faktycznie jest lepsza, to jeszcze jakiś sens to ma. Jeżeli nie, to nie ma to żadnego sensu, bo nadal jest natywna obsługa OpenGL. Vulkan nie ma go zastąpić, tylko być dodatkowym API obok niego.

lunareth   4 #40 06.09.2016 14:57

Dobrze sie czytało i czegos nowego się dowiedzialo. Szkoda, że poki co na zamknietych sterownikach nie poszalejemy :P

dragon321   10 #41 06.09.2016 15:04

@lunareth: Dzięki za opinie.

A no szkoda, ale cóż poradzić? Trzeba czekać. A póki co denerwować się na "iksy" :D

@redspl: Dzięki za komentarz.

Mnie tam średnio obchodzi jaki będzie system okien. Jeżeli ktoś dostarczy mi stabilne, funkcjonalne i bez problemowe środowisko, to nie obchodzi mnie czy działa na X czy na Waylandzie.

  #42 06.09.2016 21:35

@Loombago: "Powiedz ile z nich jest na desktopach"
ogólnie wszystkich linuksów nawet na typowych desktopach jest o wiele więcej niż ci się wydaje, zobacz na takie dp, nie jest to portal stricte linuksowy a prawie co trzecia osoba bangla na linuksowym jajku

But_w_trawie   9 #43 07.09.2016 08:29

@dragon321: benchmarki z którymi się zetknąłem, i dotyczyły gier na steam pokazują że pod Vulcanem działa to szybciej. tyle że ja byłem jedynie czytelnikiem, nie testerem.

Co do Waylanda, powstał on zamiast X tylko dlatego, że rozdrobnienie procesów w X na obecnym etapie niemal całkowicie blokuje wzrost wydajności w renderowaniu grafiki.

Jest też słówko na temat Wayland, że on się nie zajmuje rysowaniem, a X tak. Z puntu widzenia API tak właśnie jest, i tak było w XFree86. ale w X.org już nie, bo sterowniki graficzne są już osobne. Nie są to zintegrowane moduły jak w XFree, i w praktyce tworzą odrębną warstwę. A Wayland na swój sposób to powiela.

Autor edytował komentarz w dniu: 07.09.2016 08:39
Loombago   9 #44 07.09.2016 14:25

@Anonim (niezalogowany): Na portalu technologicznym podnoszącym tematykę linkusową to nie dziwne. W skali globalnej dekstop linuksowy jest na poziomie marginesu błędu.

dragon321   10 #45 07.09.2016 16:21

@But_w_trawie: No to jeszcze to sens ma.

Nie tylko dlatego. Kod iksów stał się też już trudny do utrzymania, ze względu na stosowane niegdyś sztuczki, które miały wprowadzić nowe funkcje i zachować kompatybilność. Czyścić go nie ma sensu, bo za dużo roboty, a i tak nie naprawi to przestarzałej architektury systemu okien. Nie ma sensu trzymanie monolita zajmującego się chyba wszystkim, bo to ogranicza wydajność.

Tutaj się mylisz. Oba komunikują się ze sterownikami (logiczne, bo jak inaczej mają rozmawiać z grafiką), ale X.Org posiada funkcje do rysowania. X.Org również potrafi rysować, a sterownik przecież jest po to, by była możliwa komunikacja z kartą graficzną. X ma API do rysowania, chociaż są metody pozwalające go pominąć przy rysowaniu (chodzi mi tu o DRI - Direct Rendering Infrastructure). Wayland sam w sobie nie posiada żadnych funkcji do rysowania i nie jest to żaden monolit jak X. X.Org jest warstwą będącą pomiędzy grafiką (sterownikiem), a danym menedżerem okien. Wayland to jest tylko protokół, który umożliwia komunikacje kompozytora z grafiką. Architektura X.Org Server się dużo nie różni od XFree86, bo przecież to jego fork.

  #46 08.09.2016 01:25

@Loombago: co nas obchodzą osoby nie-technologiczne? hm dla nas to bydło! im dasz cokolwiek winowsa/osx/linuxa i będą na tym działały bo jest domyślne i ok, jaka to rónica moja matula nie widzi różnicy z przesiadki z dosyć starego blaszaka z intelowskim dwuwątkowym prockiem na rpi2, mało tego jest zadowolona, że komputerek mały i bezgłośny do tego lans wśród koleżanek, że takie to małe a dziaała no popatrz...a ja bym przykładowo nie zniósł pracy na takim kompie ale widzisz wszystko wg potrzeb

Loombago   9 #47 09.09.2016 09:47

@Anonim (niezalogowany):

Mnie obchodzi bo pracuje w it przy obsłudze firm ponad 7 lat i wiem, ile znaczą przyzwyczajenia. Przesiadka z Win 7 na 10 do dla niektórych ciężkie przeżycie. Nigdy nie nazwałbym osób nie technologicznych bydłem bo to brak szacunku. Nie każdy musi się znać na komputerach. Super userzy to mały i w przypadku OSów na desktopie niewiele znaczący globalnie procent. Chyba, że mówimy o specyficznych zastosowaniach.

Autor edytował komentarz w dniu: 09.09.2016 15:07
  #48 12.09.2016 20:25

Kolejny dopracowany wpis, gratulacje! ;)

dragon321   10 #49 12.09.2016 23:24

@mnemosyne: Dzięki :)

  #50 15.09.2016 19:13

@Loombago: ok może przesadziłem, nie bydło ale z pewnością są to ignoranci z biegiem czasu będzie coraz ciężej takim osobom, chyba, że odkleją się od cywilizacji i zamieszkają na jakimś odludziu jest to jakieś wyjście bo stety niestety idziemy w kierunku cyberpunku i coraz więcej rzeczy/czynności i aspektów dzisiejszego życia, naszej pracy itp. będzie pod kontrolą elektroniki i brak znajomości jej działania oraz obsługi będzie dla takich osób niezwykłym utrudnieniem a wręcz mogą zostać zepchnięci na margines i wykluczeni oczywiście mówią tu o co najmniej kilku pokoleniach w przód ale przepaść będzie ogromna

parranoya   9 #51 23.11.2016 11:03

Wszystko ładnie i pięknie ale obyśmy nie czekali na popularyzację Wayland'a tyle co na ipv6 :-)

dragon321   10 #52 23.11.2016 12:44

@parranoya: Cóż, Fedora 25 już ma domyślnego Waylanda. Red Hat ma duży wpływ na Linuksy, to może się uda.