Dlaczego Canonical wybrał Mir zamiast Wayland jako serwer wyświetlania?

Lubię wiedzieć, jakie są zalety Mir.

Dlaczego nie Wayland / Weston?

Najpierw oczywiste wyjaśnienie: Wayland jest definicją protokołu, która określa, w jaki sposób aplikacja kliencka powinna komunikować się z komponentem kompozytora. Dotyka obszarów takich jak tworzenie / niszczenie powierzchni, przydzielanie / zarządzanie buforem graficznym, obsługa zdarzeń wejściowych i szorstki prototyp integracji elementów powłoki. Nasza ocena definicji protokołu wykazała jednak, że protokół Wayland nie spełnia naszych wymagań. Po pierwsze, dążymy do bardziej rozszerzalnej obsługi zdarzeń wejściowych, która uwzględnia przyszłe zmiany, takie jak urządzenia wejściowe 3D (np. Leap Motion). Należy jednak pamiętać, że obsługa zdarzeń wejściowych Waylanda nie wiąże się z problemami bezpieczeństwa wprowadzonymi przez semantykę obsługi zdarzeń wejściowych X (podziękowania dla Daniela Stone'a i Kristiana Høgsberga za zwrócenie na to uwagi). W odniesieniu do mobilnych przypadków użycia, uważamy, że obsługa metod wprowadzania powinna również znaleźć odzwierciedlenie w protokole serwera wyświetlania. Jako kolejny przykład uważamy części protokołu związane z integracją powłoki za uprzywilejowane i wolimy raczej unikać definiowania jakiegokolwiek zachowania powłoki w protokole skierowanym do klienta.

Nadal jednak uważamy, że próba ujednolicenia komunikacji między klientami a komponentem serwera wyświetlającego przez Wayland jest bardzo rozsądna i użyteczna, ale ze względu na nasze różne wymagania zdecydowaliśmy się na następującą architekturę związaną z integracją protokołu:

Rdzeń wewnętrzny niezależny od protokołu, który jest wyjątkowo dobrze zdefiniowany, dobrze przetestowany i przenośny. Zewnętrzna powłoka wraz z zaporą frontend, która pozwala nam przenieść nasz serwer wyświetlania na dowolne stosy graficzne i powiązać go z wieloma protokołami.

Podsumowując, nie wybraliśmy Wayland / Weston jako podstawy do świadczenia usług nowej generacji, ponieważ nie spełnia ona całkowicie naszych wymagań. Co więcej, dzięki naszemu podejściu opartemu na protokole i platformie możemy zagwarantować, że osiągniemy nasz cel polegający na spójnym i pięknym doświadczeniu użytkowników na różnych platformach i urządzeniach. Jednak obsługę Wayland można dodać albo poprzez zapewnienie specyficznej dla Wayland implementacji frontendu dla naszego serwera wyświetlania, albo przez zapewnienie implementacji libwayland po stronie klienta, która ostatecznie rozmawia z Mirem.

Bardziej szczegółowa dyskusja tutaj: https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

I od architekta technicznego Mir:

http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/

Więcej informacji:

• http://blog.cooperteam.net/2013/03/artistic-differences.html
• http://blog.cooperteam.net/2013/03/mir-and-you.html
• http://blog.cooperteam.net/2013/03/for-posterity.html

Jono Bacon w swoim Q i A odpowiedział na to kilka razy. Jego ostatnia odpowiedź jest tutaj:

http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s

Z tego, co zebrałem na podstawie pytań i odpowiedzi Jono oraz komentarzy Popeya dotyczących Linux Unplugged, punkty można podsumować następująco:

1. Wayland robi za dużo. Ciągłe nieużywanie funkcji w stosie oprogramowania jest złym projektem oprogramowania.
2. Zespół Waylanda nie byłby wystarczająco elastyczny, aby zaoferować wypatroszoną wersję Waylanda, aby odpowiednio i z szacunkiem pomieścić.
3. Mir to Wayland, a LightDM to GDM / KDM.
4. Ubuntu ma bardzo tragiczne terminy, które muszą spełnić z producentami telefonów i tym podobnymi. Kontrola nad projektem ułatwia wlewanie dodatkowych zasobów, aby zagwarantować dotrzymanie tych terminów.
5. Chociaż nie sądzę, by ten powód kiedykolwiek oficjalnie pochodził z kanoniki, a zatem jest to po prostu spekulacja z mojej strony, w momencie, gdy decyzja została podjęta, Wayland nie wydawał się być wystarczająco szybki, aby wprowadzić go na rynek, a obecna technologia Androida wydawała się jak bardziej odpowiednia baza do uruchomienia ich produktu.