在我发布了关于NetBSD新的默认窗口管理器的帖子后，我收到了几个问题，包括NetBSD什么时候从X11切换到Wayland？Wayland是X11&39；s&34；的新竞争对手。在这篇博客文章中，我希望我能解释为什么我们现在还没有！
去年(以及今年初)，我负责将第一个可用的Wayland合成器移植到NetBSD-SWC。我之所以选择它，是因为它看起来很小，而且可以破解。您可以通过从pkgsrc安装velox窗口管理器来试用它。
在Wayland系统中，合成器(显示服务器)负责管理显示、输入和窗口管理。通常，这意味着那里包含大量特定于操作系统的代码。
Wayland没有为X11用户期望的功能定义协议，比如屏幕截图、屏幕锁定或窗口管理。您可以在合成器中实现这些(大量工作需要重做)，也可以定义您自己的协议扩展。
Wayland参考实现是一小组库，可用于构建合成器或客户端应用程序。这些库目前对EPOLL等Linux内核API有硬依赖。在pkgsrc中，我们已经为库打了补丁以添加kqueue(2)支持，但是这些补丁尚未被上游接受。Wayland是基于Linux的假设编写的，以至于每个客户端应用程序都倾向于#include；linux/input.h>；，因为Wayland的设计者认为没有必要定义一种与操作系统无关的方式来获取鼠标按键ID。
到目前为止，除了SWC之外，所有的Wayland合成器都依赖于libinput，而libinput只支持Linux的输入API(也是在FreeBSD中克隆的)。在NetBSD中，我们有一个完全不同的输入API-wscons(4)。实际上，为wscons编写代码相当简单，只需要有人去做就可以了。您可以使用我在SWC中的代码作为参考。：)。
总体而言，Wayland正在摆脱X服务器的模块化、可移植性和标准化。
SWC与Firefox等关键应用程序不兼容，但Luakit等其他应用程序可以工作，就像大多数使用Qt5、GTK3或SDL2的应用程序一样。目前不能运行X11应用程序是相当有限的。
您需要一个支持内核模式设置的GPU或SoC，因为安全软件后备功能在这里不起作用。到目前为止，我只在英特尔图形处理器上测试过这一点。
在更多的Wayland合成器中添加对wscons的支持，并说服开发人员接受补丁。
说服开发人员不要添加对EPOLL的硬依赖，而是使用像libeent这样的抽象层。
更新NetBSD内核DRM/KMS堆栈。这是一项困难的任务，涉及从Linux内核移植代码(一个移动非常快的目标)。
向Wayland合成器添加对基本(非DRMKMS)帧缓冲区的支持。X11可以从基本的非加速NetBSD帧缓冲区运行，但这在任何Wayland合成器中都是不可能的。
我决定暂时不做这件事，因为这是一项相当巨大的事业，而且是一场艰苦的战斗。现在，X11与Picom或xcompmgr这样的排字机相结合是更成熟的选择。
[2条评论]