Tags Posts tagged with "x server"

x server

przez -
38 840

W 2008 roku Kristian Høgsberg zapoczątkował nowy projekt w świecie Linuksa – Wayland. Jego celem było stworzenie następcy obecnego X Servera, wraz z menadżerami okien i sporą ilością funkcji, które obecnie posiada jądro Linux. Tak narodził się Wayland – protokół systemu okien, który łączy w sobie menadżera kompozycji oraz system okien. Jest on swojego rodzaju protokołem dla kompozytora, który łączy się z klientami i posiada towarzyszącą mu bibliotekę implementującą, napisaną w języku C.

Częścią projektu Wayland jest Weston, który jest implementacją kompozytora Waylanda. Weston może działać, jako klient X lub Linux KMS, i zapewnia kilka przykładowych klientów. Kompozytor Weston jest szybki i minimalistyczny, dzięki czemu nadaje się dla urządzeń mobilnych i wbudowanych.

X Server

Poniżej zamieszczamy rysunek działania X Servera:
Architektura X Server

  1. Jądro otrzymuje sygnał z urządzenia wejściowego i przesyła go do X Servera poprzez sterownik wejścia evdev. Jądro wykonuje całą żmudną pracę poprzez sterowanie urządzeniem i tłumaczeniem specyficznych protokołów dla standardowego zdarzenia wejściowego evdev.
  2. X Server decyduje, którego okna dotyczy sygnał i śle go do klientów, które zostały wybrane do danego zdarzenia w tym oknie. X Server nie wie aktualnie, jak to zrobić, ponieważ lokalizacja okna na ekranie jest kontrolowana przez kompozytor i może zostać to zmienione na wiele sposobów, których X Server nie obsługuje.
  3. Klient czeka na zdarzenie i decyduje, co zrobić. Często interfejs graficzny musi zostać zmieniony, w odpowiedzi na zdarzenie, może został kliknięty przycisk zamknięcia, lub wskaźnik najechał na przycisk, który powinien zostać podświetlony. Tak więc klient wysyła żądanie renderowania z powrotem do serwera X.
  4. Kiedy X Server otrzymał żądanie renderowania, wysyła to do sterownika, aby umożliwić mu zaprogramowanie sprzętu do renderowania. X Server oblicza także przylegający region renderowania i wysyła to do kompozytora, jako zdarzenie zniszczenia.
  5. Następnie kompozytor otrzymuje od zdarzenia zniszczenia, że coś zostało zmienione w oknie, i powinna zostać ponownie narysowana część ekranu, na którym jest owe okno widoczne. Kompozytor jest odpowiedzialny za renderowanie całej zawartości ekranu i okien X. Potem musi jeszcze raz przesłać to przez X Server, aby zakończyć renderowanie.
  6. X Server otrzymuje żądanie renderowania od kompozytora i kopiuje back bufor do front bufora, lub wykonuje tzw. pageflip.

Wayland

Oto, jak działa Wayland:
Architektura Wayland

  1. Jądro otrzymuje żądanie i wysyła je do kompozytora. Odbywa się to podobnie, jak w X Server, ponieważ możemy użyć wszystkich sterowników wejścia, zawartych w jądrze.
  2. Kompozytor przegląda swoją obecną scenę graficzną (Scene Graph), aby ustalić które okno powinno otrzymać zdarzenie. Scene Graph wysyła sygnał, co ma obecnie na ekranie, a kompozytor próbuje zrozumieć zmianę, jaką ma zaimplementować do elementów sceny. Warto zaznaczyć, że typy transformacji wykonywane na oknie, są ograniczone jedynie do możliwości kompozytora, tak długo, jak może on obliczać wsteczną transformację dla zdarzeń wejścia.
  3. Klient podłączony do Waylanda, wykonuje całe renderowanie. Wysyła żądanie do kompozytora, aby zainicjować region, który został zaktualizowany.
  4. Kompozytor zbiera żądania zniszczenia od klientów, a następnie zmienia cały obraz na ekranie. Kompozytor może bezpośrednio wysłać ioctl, aby zaplanować pageflip z KMS.

Zalety i wady nowego protokołu

Jak zatem widzimy Wayland niweluje wiele niepotrzebnych czynności, jakie są wykonywane przez X Server. Patrząc po obecnych możliwościach, jakie możemy wykonywać z jego wykorzystaniem, czyni go to przyszłościowym rozwiązaniem. Aktualnie jednak jest sporo problemów:

  • Brak wsparcia od nVidia i AMD, w kwestii własnościowych sterowników. Jedyne, które aktualnie współpracują dobrze, to te od Intela.
  • Brak transparentności sieciowej. Wiele osób zarzuca brak tej cechy, jednakże Windows też tego nie posiada i nikt nie narzeka. Wykorzystywane są programy typu RDP, VNC.
  • Nie ma natywnego OpenGL. Domyślnie API OpenGL dla systemów Linux, posiada w nazwie GLX i jest ściśle związane z Xami. Jedynym niezależnym API jest OpenGL ES, który został przystosowany dla urządzeń mobilnych, jak Android, który nie korzysta z Xów.
  • Brak łatwego przenoszenia na inne platformy. Wayland jest silnie związany z mechanizmami, zawartymi w jądrze Linux.

przez -
0 387
X.Org

Jeremy Huddleston ogłosił wydanie X.Org Server 1.9.3. Jest to trzecie wydanie aktualizujące stabilną wersję, w której nie będą dodawane żadne nowości, a jedynie naprawiane błędy. Najważniejszą z rzeczy jest obsługa owej wersji przez najnowsze sterowniki Catalyst 10.12. Naprawiono łącznie 52 znalezione błędy, które poprawiają stabilność, wydajność i poprawność wyświetlania. Znalazły się również poprawki dla KDrive i Apple XQuartz.

Polecane

Jesień Linuksowa

1 1163
Polska Grupa Użytkowników Linuksa ma zaszczyt zaprosić na konferencję Jesień Linuksowa 2017, która odbędzie się w dniach 22 – 24 września 2017 roku. Jako...