为什么 Canonical 选择 Mir 而不是 Wayland 作为显示服务器？

Question

我想知道，Mir 有什么优势。

Answer 1

为什么不是韦兰/韦斯顿？

首先要明确说明：Wayland 是一个协议定义，它定义了客户端应用程序应该如何与合成器组件通信。它涉及诸如表面创建/破坏、图形缓冲区分配/管理、输入事件处理和壳组件集成的粗略原型等领域。但是，我们对协议定义的评估表明，Wayland 协议不符合我们的要求。首先，我们的目标是提供更可扩展的输入事件处理，将 3D 输入设备（例如 Leap Motion）等未来发展考虑在内。请注意，Wayland 的输入事件处理不会受到 X 的输入事件处理语义引入的安全问题的影响（感谢 Daniel Stone 和 Kristian Høgsberg 指出这一点）。关于移动用例，我们认为输入法的处理也应该反映在显示服务器协议中。作为另一个例子，我们认为协议的 shell 集成部分是特权的，我们宁愿避免在面向客户端的协议中定义任何类型的 shell 行为。

但是，我们仍然认为 Wayland 在标准化客户端和显示服务器组件之间的通信方面的尝试是非常明智和有用的，但由于我们的不同要求，我们决定采用以下架构来进行协议集成：

一个与协议无关的内核，定义非常明确、经过良好测试且可移植。一个外壳和一个前端防火墙，允许我们将我们的显示服务器移植到任意图形堆栈并将其绑定到多个协议。

总之，我们没有选择 Wayland/Weston 作为我们提供下一代用户体验的基础，因为它不能完全满足我们的要求。更重要的是，通过我们与协议和平台无关的方法，我们可以确保实现跨平台和设备外形一致且美观的用户体验的目标。但是，可以通过为我们的显示服务器提供特定于 Wayland 的前端实现或通过提供最终与 Mir 对话的 libwayland 客户端实现来添加 Wayland 支持。

这里有更详细的讨论：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/

更多信息：

• 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

Answer 2

乔诺培根在他的问答中已经回答了几次。他的最新回答在这里：

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

根据我从 Jono 的问答以及 Popey 对 Linux Unplugged 的​​评论中收集到的信息，可以总结如下几点：

1. 韦兰做得太多了。在您的软件堆栈中永久使用未使用的功能是糟糕的软件设计。
2. Wayland 的团队不够灵活，无法提供一个完整的 Wayland 版本来充分、尊重地适应。
3. Mir 之于 Wayland，LightDM 之于 GDM/KDM。
4. Ubuntu 有非常紧迫的截止日期，他们需要与手机制造商等会面。控制项目可以更轻松地注入额外资源以确保满足这些最后期限。
5. 虽然我不认为这个原因正式来自规范，因此只是我的猜测，在做出决定的时候，Wayland 似乎没有足够快地进入市场，现有的 Android 技术似乎喜欢一个更合适的基地来推出他们的产品。