在开启了FBDEV 模拟层的设备上屏蔽/dev/fb0的显示功能

在以 DRM 为主的现代嵌入式系统中，主动屏蔽或关闭 /dev/fb0 的显示输出是非常推荐的常规操作。

之所以要屏蔽它，是因为在默认情况下，即便你的应用程序在使用底层的 DRM 接口，Linux 内核的控制台（fbcon）依然会牢牢霸占着 /dev/fb0。这就导致每当系统引导、内核报错、或者有键盘输入时，内核都会尝试往屏幕上打印白色的文字，从而直接污染你原本干净的 DRM 游戏画面或 UI 界面。

在不重新编译内核（保留 FBDEV 模拟层以备不时之需）的前提下，有以下几种最有效的方法来屏蔽 /dev/fb0 的显示：

方法一：通过内核启动参数彻底禁用控制台绑定（最推荐）

如果你只是不想让内核控制台（TTY）把文字打印到 /dev/fb0 上污染屏幕，可以在 U-Boot 的 bootargs（内核启动参数）中加入以下参数：

Plaintext

fbcon=map:1

原理解析：

• 默认情况下，内核会将控制台绑定到第一个 Framebuffer 设备（即 fbcon=map:0，对应 /dev/fb0）。

• 改为 fbcon=map:1（或者一个不存在的 fb 序号）后，内核控制台就会解除与 /dev/fb0 的绑定。

• 效果 ：/dev/fb0 节点依然存在，但系统启动时的满屏 LOGO 和光标闪烁会彻底消失，屏幕一片漆黑，直到你的 DRM 应用程序接管并刷屏。

方法二：运行期动态解绑控制台（免重启）

如果你的系统已经启动，你想在脚本中动态关闭 /dev/fb0 的控制台输出功能，可以直接通过 sysfs 接口向内核下达解绑命令：

Bash

# 解除 fbcon 与底层 Framebuffer 的绑定
echo 0 > /sys/class/vtconsole/vtcon1/bind

(注意：不同的发行版和内核版本，vtcon1 或者是 vtcon0 可能会有差异，可以通过 cat /sys/class/vtconsole/vtcon*/name 查看哪个含有 "frame buffer" 字样)

执行此操作后，/dev/fb0 将不再接收任何内核控制台的刷新信号，变为纯净的空闲状态。

方法三：利用 DPMS 彻底关闭 FB 层的物理输出

如果你希望 /dev/fb0 不仅不显示文字，甚至连其对应的硬件底层图层（Primary Plane）都不要去读取任何模拟数据，可以直接利用 Linux 系统的图形电源管理（DPMS）将其"熄屏"：

Bash

# 往 fb0 发送不使能（Blank）信号
echo 1 > /sys/class/graphics/fb0/blank

• echo 1：相当于进入 Standby 模式，停止刷屏。

• echo 4：彻底关闭（Powerdown）。

• 效果 ：此时模拟层被彻底挂起，哪怕有 legacy 程序往 /dev/fb0 写入数据，硬件也不会去读取它。此时只有绕过 FB 层、直接控制 DRM 硬件 Plane 的现代程序（如 Weston 或是 DRM 驱动原生应用）才能让屏幕亮起来。

方法四：应用层运行时的"独占"抢占（最优雅）

如果你在使用如 Weston、Wayland 或基于 DRM 的游戏引擎（如自定义配置的 Godot 嵌入式版），引擎本身提供了"高优先级抢占"机制。

在编写 DRM 应用程序时，通常会调用：

C

drmSetMaster(fd);

一旦你的 DRM 程序获取了 Master（主控）权限 ，内核就会在硬件层面上自动挂起（Mute）FBDEV 模拟层的输出请求。此时通过 /dev/fb0 写入的任何画面都会被内核无视，直到你的 DRM 程序退出并释放 Master 权限，控制权才会交还给 /dev/fb0。

总结建议

如果你正在开发一个以 DRM/KMS 渲染为主的嵌入式设备：

1. 修改 U-Boot 启动参数加上 fbcon=map:1，阻止内核字符污染屏幕。

2. 启动脚本中加入 echo 1 > /sys/class/graphics/fb0/blank 彻底休眠 FB 模拟。

3. 腾出干净的硬件管线，让你的 DRM 游戏引擎或 GUI 畅快运行。