LWN：复活fbdev！

关注了就能看到更多这么棒的文章哦～

Resurrecting fbdev

By Jake Edge
January 19, 2022
DeepL assisted translation
https://lwn.net/Articles/881827/

Linux 的帧缓冲设备（fbdev）子系统很长时间以来在某种程度上来说是一直被搁置的，它在 MAINTAINERS 文件中被列为 "orphaned" 状态，维护工作相当少，这些也主要是由在内核图形堆栈（kernel graphics stack）其他部分做工作的开发人员所推动的。1月 17 日当 Linus Torvalds 合并了一个改动来把 Helge Deller 指定为该子系统的新维护者时，这一切都发生了变化，令人大开眼界。但事实证明，fbdev 的水很深，至少在 kernel graphics 社区的其他成员看来是这样的。Deller 来担任维护者，看起来是为了要把 fbdev 中已经被删除的一些有问题的功能再加回来，这引起了一些争论。

图形社区的担忧的一点是这些事件发生在太短的时间里了。Deller 在 1 月 14 日星期五发布了他打算接管 framebuffer 维护的意见，当天晚些时候就收到了 Geert Uytterhoeven 的回复。两天后，在没有任何其他回应之前，Deller 向 Torvalds 发送了一个 pull request 要求将 Deller 加入到 fbdev 的维护者行列，这个 pull request 很快就被采纳了。1月 19 日，Deller 发布了两版 patch set，把 fbdev 中删除了了滚动加速（scrolling acceleration）功能的 patch 给 revert 掉了。而且这个 revert 操作马上就进入了 Deller 的全新的 fbdev Git tree 了。

被 revert 的那些 patch 是在一段时间之前发布并合并的。Daniel Vetter 早在 2020 年底就禁用了 framebuffer console （fbcon）的滚动加速功能。当时，他添加了一个 "todo" 项目，打算今后把这部分代码删除掉。Claudio Suarez 在 2021 年 9 月发布了一个 patch 来完成这个 todo 项目，在 10 月被合并了。1月 13 日，在决定承担 fbdev 的维护工作的几天之前，Deller 就提出要求 revert 后一个 patch（至少是其中一部分）。

1 月 17 日星期一，Vetter 和其他一些人注意到周末发生的这些活动，并开始参与进来。Vetter 认为，"在没有征求之前一直在维护这部分代码的人的意见的情况下"，直接就修改维护者的话，有些太仓促了。具体来说他不喜欢将 fbdev 和 fbcon 移到与 DRM 树分开的代码树之中。这个子系统虽然之前已经被标记为 orphaned，但情况并不是这么简单：

这里标注的状态并不完全正确，fbdev 的核心代码， fbcon 等等都还是有人维护的，只是处于 bugfixes 状态。而且我们有充分的重要理由来要求通过 drm tree 来合并这些 patch，因为所有的驱动开发都是在那里进行的，而且所有的测试也在那里（例如，drm 测试套件中有一些 fbdev 测试——据我所知这是唯一存在的相关的自动化测试——我们在 CI[持续集成]中保持运行这些测试）。所以，把它移到一个很少有人关注的新的代码 tree 上（甚至都还不在 linux-next 的关注中），没有一点好处。

现在，fbdev 驱动的 bugfixes 实际上是 orphaned 状态，我非常欢迎任何人站出来，但最简单的方法是直接获得 drm-misc 的提交权，然后直接把 bugfix 推到那里。

除此之外，Jani Nikula 对这里的旋风式的修改速度感到很吃惊。尤其是他看到新的 fbdev 树上几乎是马上就进行了改动而感到不高兴，这个反对仅仅是在几天前才刚提出的。"我非常赞赏那些公开、透明、合作的维护者，他们通过讨论来寻求共识，并且只在有必要时才动手。" Deller 说，他刚刚开始翻阅所积压的 patch，"目前还没有什么 push 什么改动"。他认为 Nikula 目前完全可以先直接忽略 fbdev tree 内的改动。

在回答 Vetter 的问题时，Deller 说，拥有一个独立的 tree 并不重要。他列出了今后维护 fbdev 的四个目标：

1. 将发布在 fbdev 邮件列表中的 fix 代码合入进来，如果它们是有用、正确的 fix。
   

2. 如果有新的驱动（特指那些旧硬件），就把它们加进来。可能很少会有这种情况发生，但也还是有这个可能的。我知道至少有一个驱动程序不能支持 DRM….。当然，如果硬件能够支持 DRM，就应该使用 DRM，而不应该合入 fbdev。
   

3. 重新回到以前 fbcon 在 fbdev 上可以快速运行的情况。这对于 non-DRM 的设备来说是很重要的，无论是在本地硬件上运行还是在模拟器上运行的情况。
   

4. 不破坏 DRM 的开发
   

Vetter 给 Deller 指出了开始进行 DRM 开发以及在 drm-misc 代码 tree 上获得 commit 权限的文档，他说这应该是 fbdev fix 合入内核的正确路径。此外他说：

我认为，一旦我们建立了这一机制，并使其运转起来，我们就可以看看那些更大更好的事情。有一些可能是长久以来没有得到处理的、但是很容易解决的问题，但在过去 5 年多的时间里，一直没有人愿意站出来解决这些问题。fbdev 中的其他一些问题如果仅仅是做一些最基本的 security-fix 的话，是很难得到妥善解决的，提醒一下，这就是现在的事实。我认为可以先读一下你 revert 掉的这些 patch 本身以及当时的讨论。

无论如何，我希望这些能帮助你开始，尽管起初走了小小弯路。欢迎来到 dri-devel，我们很乐意接受任何类型的帮助，有很多事情要做！"。

Deller 最终决定还是要保留 fbdev tree，尽管他确实也打算跟图形开发社区的其他成员互相协调来进行：

在跟 dri-devel 完成所有讨论之前，我不打算向 fbdev/fbcon 合入 patch 了。所有会影响到 DRM 的东西都需要在 dri-devel 上讨论，然后在达成一致后，通过 fbdev git 树或 drm-misc 树来合入 mainline。

很明显，在后续该如何进行方面，大家还是存在着不同意见。被删除的硬件加速的滚屏功能是依赖于旧硬件的 2D bit-blit 加速功能的。但在 fbdev 驱动中使用这部分功能的代码显然是有不少 bug 的。多年来，syzbot 多次发现这部分代码的问题，这就是为什么它最终被删除了。DRM 子系统并不支持 2D 加速，今后也不会有，因为这里有很大的技术方面的困难。

另一方面，Deller 和其他人拥有还在使用 fbdev 驱动的图形硬件，而且以前在使用硬件加速来进行滚屏的时候性能还是不错的。当代码被删除后，这个性能就大幅下降了，他们希望能重新获取这一功能。但是把删除的代码 revert 回来只是把有 bug 的代码再加回来而已。从 DRM 开发者的角度来看，正确的做法是应该为这些设备来创建基于 DRM 的驱动程序，但 Deller 和其他一些人并不同意。

更大的问题是在过渡该如何处理上，Vetter 在讨论 revert 的邮件中说：

另一方面，担任维护者就意味着需要进行合作，可是在 fbdev 维护者职位接管这个事件中却没有看到合作。这是匆匆忙忙地在双休日[周末]来更换维护者，然后在下周一出现大量的 wtf 邮件，这整个过程确实给大家留下了一个相当酸爽的感觉。并且，这个讨论中展示了 Helge 对所发生的一切以及 drm 能做什么、不能做什么方面有误解，这些误解并不能支持所谓的 "我们需要把 fbdev 加回来" 的论据。

Vetter 坚信，如果被删除的功能还是要加回来，那么就需要把 fbdev 的代码修改得更加现代化，从而达到 "我们仍然可以告诉发行商，完全可以放心启用这个功能，不用担心收到太多 CVE" 的状态。此外，他认为有一个更直接的方法可以改善滚屏的行为，而不需要把 syzbot 所发现的所有问题代码都加回来：

另外，关于这里讨论的 "fbcon 滚屏" 问题。真正能以较好的性能来做到这一点的方法就是渲染到一个完全 cache 下来的 shadow buffer 里面，并通过一个 timer 触发把改动区域传上去的动作。如果我们没有为每个驱动程序建立完整的开发团队，就不会有 hw 加速的滚动功能，因为要想开发出不那么糟糕的 2D 加速真的很困难。

但是 Deller 的看法并不一样，他认为有一些现有的驱动程序还是需要这个被删除功能的。他打算尝试把这个功能 revert 回来，同时也能完成 syzbot 或其他人发现的那些问题的 fix：

但是 fbdev/fbcon 是几乎现存的所有尚未被 DRM 支持的显卡在内核里主要的支持 framework。他们需要 fbdev/fbcon 来显示他们的 text console，也许还可以显示一个简单的 X server。如果你破坏了这些显卡的 fbdev，那么它们就完全陷入困境了。希望这些驱动能被移植到 DRM 上，但目前这并不容易实现（或者实现了也会因为太慢而无法使用）。

DRM 的开发者似乎不太相信能把已经发现的问题都解决，但他们似乎应该给 Deller 一些时间来尝试。fbdev 的 "orphaned" 地位也许设置得并不准确，尽管很明显 DRM 社区相信对这个地位的任何改动都会通过讨论来达成一致，而不是像这样在一个周末就突然接管了。尽管如此，内核中一个长期不受欢迎的部分找到了新的维护者，应该还是被视为一件好事。我们来继续等等看这一切后续如何。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～