我想以尽可能低的延迟（大约几十毫秒）在屏幕上绘制简单（2D 位图）图形（响应（简单）外部输入），这样我就可以凭经验测试绘制到屏幕的结果a）实时，b）尽可能减少开销，c）完全禁用页面翻转（撕裂很好）。
然后我可以将其与在各种刻板（并且可以说是病态的:)）场景（例如 X11、Wayland、Wayland+XWayland、Wayland+XWayland+xcompmgr 等）中绘制到屏幕进行比较。
为此，我该如何修改Linux以便我可以绘制超过我现有的 X11/Wayland 会话？换句话说，是的，我想摆弄 DRM（直接渲染管理器），
A。从内核内部，
湾。而X11拥有DRM主控。 :)
我怀疑硬件覆盖将是防止 X11/Wayland 在我正在绘制的内容上乱涂乱画的最简单（也是最硬件加速！）的方法。 （我正在想象涉及实现影子/直写帧缓冲区缓存的替代方案，以避免读回......不，谢谢！）
我真的非常想将我的疯狂限制在内核模块上，而且我不想摆弄我的图形驱动程序。 :S（我顺便使用了 Intel 显卡，尽管是在 i915 上）
所以，通读https://dri.freedesktop.org/docs/drm/，我的想法是或许我想尝试将一些东西组合在一起，让我创建一个哑帧缓冲区，创建一个观察该哑帧缓冲区的平面，然后双也许设置某种 DMA-BUF...不，等等，如果我有一个指向帧缓冲区的平面，它就已经在屏幕上了...我想？
我的主要问题是，我如何快速而宽松地使用 DRM，以便它基本上告诉 X 这是唯一与屏幕对话的东西，而在幕后我正在管理一架额外的飞机？
非常感谢回答！
我目前对 Wayland 的理解是，它从根本上基于合成，并且根据设计，如果在将一个或多个视频帧释放到显卡之前不缓冲一个或多个整个视频帧，则无法运行。
虽然 X11 没有这个限制 -COMPOSITE是一个可选的扩展 - 它使用基于流的绘图协议，并且我不知道有任何方法可以直接绘制到窗口中。我所知道的最接近的是MIT-SHM扩展的使用，虽然这确实允许使用共享内存，但这至少涉及两个内存副本（me->kernel，kernel->X11），进而戳XShmPutImageX11 管子告诉 X11 请翻转。这意味着，即使我要让我的进程实时运行...好吧，我太胆小了，无法实时运行 X，所以我仍然必须等待 X 被调度、解码并到达我的请求在它的命令队列中，最后翻转。
因此，我举起双手，尝试看看是否可以将图形绘制代码直接推入内核，并希望以某种方式使其全部共存。
我可以想象所有这些额外的开销确实会增加，并且我想准确地量化如何- 或者，具体地证明我的思维模型是完全错误的，并且当代硬件的速度使这些担忧变得毫无意义。
我是极其我很想知道如果消除所有瓶颈会产生什么影响，以及比较旧系统与更现代的硬件会有什么区别。