Canonical이 Wayland보다 Mir를 디스플레이 서버로 선택한 이유는 무엇입니까? Mir의 장점이

나는 Mir의 장점이 무엇인지 알고 싶습니다.



답변

왜 웨이 랜드 / 웨스턴이 아닌가?

먼저 명확한 설명 : Wayland는 클라이언트 응용 프로그램이 컴포 지터 구성 요소와 통신하는 방법을 정의하는 프로토콜 정의입니다. 표면 생성 / 파괴, 그래픽 버퍼 할당 / 관리, 입력 이벤트 처리 및 쉘 구성 요소 통합을위한 대략적인 프로토 타입과 같은 영역을 다룹니다. 그러나 프로토콜 정의를 평가 한 결과 Wayland 프로토콜이 요구 사항을 충족하지 않는 것으로 나타났습니다. 먼저, 3D 입력 장치 (예 : Leap Motion)와 같은 향후 개발을 고려한보다 확장 가능한 입력 이벤트 처리를 목표로합니다. Wayland의 입력 이벤트 처리에는 X의 입력 이벤트 처리 시맨틱이 도입 한 보안 문제가 발생하지 않습니다 (Daniel Stone과 Kristian Høgsberg가이를 지적한 덕분입니다). 모바일 사용 사례와 관련하여 우리는 입력 방법의 처리가 디스플레이 서버 프로토콜에도 반영되어야한다고 생각합니다. 다른 예로, 프로토콜의 셸 통합 부분을 권한있는 것으로 간주하고 클라이언트 지향 프로토콜에 정의 된 셸 동작을 피하는 것이 좋습니다.

그러나 클라이언트와 디스플레이 서버 구성 요소 간의 통신을 표준화하려는 Wayland의 시도는 매우 합리적이고 유용하지만, 서로 다른 요구 사항으로 인해 다음 아키텍처를 프로토콜 통합에 적용하기로 결정했습니다.

프로토콜에 구애받지 않는 내부 코어로, 잘 정의되고 테스트가 잘 수행되고 이식성이 뛰어납니다. 프론트 엔드-방화벽과 함께 외부 쉘은 디스플레이 서버를 임의의 그래픽 스택으로 포팅하고이를 여러 프로토콜에 바인딩 할 수있게 해줍니다.

요약하면, 우리는 차세대 사용자 경험을 제공하기위한 기반으로 Wayland / Weston을 선택하지 않았습니다. 또한 프로토콜 및 플랫폼에 구애받지 않는 접근 방식을 통해 플랫폼 및 장치 폼 팩터에서 일관되고 아름다운 사용자 경험을 달성 할 수 있습니다. 그러나 Wayland 지원은 디스플레이 서버에 Wayland 전용 프론트 엔드 구현을 제공하거나 궁극적으로 Mir와 통신하는 libwayland의 클라이언트 측 구현을 제공하여 추가 할 수 있습니다.

여기에 더 자세한 토론이 있습니다 : https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

그리고 Mir 기술 건축가로부터 :

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

더 많은 정보 :


답변

Q와 A의 Jono Bacon이이 질문에 몇 차례 답변했습니다. 그의 최신 답변은 다음과 같습니다.

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

Jono의 Q & A와 Linux Unplugged에 대한 Popey의 의견에서 수집 한 내용을 요약하면 다음과 같습니다.

  1. 웨이 랜드는 너무 많은 일을한다. 소프트웨어 스택에 영구적으로 사용되지 않는 기능이 있으면 소프트웨어 디자인이 좋지 않습니다.
  2. Wayland의 팀은 적절하고 정중하게 수용 할 수있는 Wayland 버전을 제공 할만큼 유연하지 못합니다.
  3. Mir은 WayDM, LightDM은 GDM / KDM입니다.
  4. 우분투는 전화 제조업체 등을 만나야 할 마감일이 매우 깁니다. 프로젝트를 제어하면 이러한 마감 시한을 지키기 위해 추가 리소스를 더 쉽게 주입 할 수 있습니다.
  5. 비록이 이유가 공식적으로 정식에서 나온 것이 아니라고 생각했기 때문에 결정을 내릴 때 Wayland는 시장에 충분히 빠르게 움직이는 것처럼 보이지 않았으며 기존 Android 기술은 보였습니다. 제품을 출시하기에 더 적합한 기반처럼.

답변