1. 为什么在 Linux TTY 终端里显示中文至今仍是“硬骨头”你有没有试过在纯文本模式下也就是按下 CtrlAltF2/F3 进入的真正 TTY不是 GNOME Terminal 或 Konsole 那种图形终端输入ls结果看到一堆问号、方块或者干脆是乱码的文件名更别提用nano编辑一个带中文注释的 shell 脚本保存后打开全是 。这不是你的字体没装好也不是编码设错了——这是 Linux 内核级 TTY 子系统与中文字符集之间长达二十多年的“代际错位”。核心问题就一句话Linux 内核原生 TTY 驱动从设计之初就没打算支持 Unicode 多字节字符渲染。它只认 ASCII 和简单的 ISO-8859-1 这类单字节编码最多通过consolefonts加载点阵字体来映射 256 个码位。而中文需要 UTF-8 编码 至少 16×16 像素以上的可缩放字体 双字节/三字节字符宽度计算 行内换行对齐 光标重定位修正……这一整套机制内核 TTY 层根本没预留接口。所以当你看到kmscon、cjktty、fbterm这些名字时它们不是“增强版 TTY”而是绕过内核 TTY 的替代方案要么接管内核帧缓冲fbdev/KMS自己画字符要么在用户态模拟终端协议再把输出喂给图形服务器。这解释了为什么所有“TTY 中文方案”都带着强烈的“非官方”“实验性”“维护停滞”标签——它们本质是在补一张内核没画完的图纸。我从 2008 年开始在嵌入式设备上调试串口中文日志到 2015 年在 Kali Linux 上为渗透测试员定制中文 TTY 环境再到 2022 年给国产 ARM 服务器部署无 GUI 的运维控制台踩过的坑全指向同一个事实没有银弹只有取舍。你要的是启动快、内存省、内核兼容性高那cjktty是目前唯一能进 initramfs 的方案。你要的是字体平滑、支持 emoji、能跑 Vim 插件那kmscon是唯一接近生产可用的选择但代价是必须用 systemd、放弃 SysVinit、且无法在老内核4.15上稳定运行。这个标题里的“现状”二字不是指“已经搞定”而是指“我们还在用各种临时胶带把一块不匹配的拼图强行按进系统里”。接下来我会带你一层层剥开每种方案的真实能力边界、编译陷阱、以及那些连 GitHub Issues 里都没人敢写的实操雷区。2. 四大主流方案深度解剖原理、适用场景与致命缺陷2.1 cjktty最轻量也最脆弱的“内核补丁派”cjktty不是一个独立程序而是一组针对 Linux 内核源码的 patch 集合最早由国内开发者于 2004 年发布目标很直接让内核 TTY 驱动原生支持 GBK/GB2312 字符集。它修改了drivers/tty/vt/vt.c和drivers/video/console/vgacon.c等核心文件添加了双字节字符宽度判断、GBK 字形缓存、以及基于 VGA 文本模式的 16×16 点阵字体渲染逻辑。它的优势极其鲜明零用户态依赖打完补丁重新编译内核重启即生效连/sbin/init都不用改内存占用极低实测在 256MB RAM 的 ARM 设备上仅增加约 12KB 内核镜像体积启动速度无损比kmscon快 3~5 秒因为完全跳过了用户态初始化流程。但代价同样残酷UTF-8 支持为零它只认 GBK 编码如果你的系统 locale 是zh_CN.UTF-8cjktty会把每个 UTF-8 三字节序列当三个独立字符处理结果就是满屏 字体扩展性为负内置字体固定为lat0-16.psfuLatin-1gb2312-16.psfu国标想加思源黑体得自己用psfaddtable工具重新生成 PSF 字体文件且最大尺寸不能超过 32×32否则内核 OOPS现代硬件兼容性崩坏在 Intel 核显i915或 AMD GPUamdgpu驱动启用 KMS 模式时cjktty会与内核 DRM 子系统抢帧缓冲控制权导致黑屏或字符错位这个问题在 5.10 内核中从未被修复。我去年在一台飞腾 D2000 服务器上部署时发现它甚至无法正确识别 USB 键盘的 Shift数字键组合——因为cjktty的键盘扫描码映射表是硬编码的不读取/usr/share/keymaps/下的任何配置。这意味着如果你想用cjktty显示中文就必须把整个系统 locale 切成zh_CN.GBK同时禁用所有 UTF-8 相关服务如systemd-localed这在现代发行版中等于自废武功。提示cjktty的唯一合理使用场景是嵌入式设备的最小化 initramfs 环境且设备明确使用 GBK 编码的固件日志。如果你的系统已启用 systemd、使用 UTF-8 locale、或需要连接 HDMI 显示器请直接跳过此方案。2.2 kmscon最接近理想的“用户态重写派”kmscon是目前唯一试图用现代工程方法彻底重构 TTY 渲染链路的项目。它完全抛弃内核 TTY转而通过 libdrm 直接访问内核 DRM/KMS 接口在帧缓冲上绘制自己的虚拟终端。其架构分三层底层渲染引擎基于 Cairo FreeType支持任意 TrueType/OpenType 字体、亚像素抗锯齿、emoji 彩色渲染中间协议层完整实现 VT100/VT220/ECMA-48 标准包括 DECSCNM反色模式、DECTCEM光标显示控制等冷门特性上层会话管理集成 logind支持多用户 TTY 切换、自动登录、PAM 认证行为几乎与原生 TTY 一致。这意味着什么你可以把Noto Sans CJK SC字体复制到/usr/share/kmscon/fonts/然后在/etc/kmscon/kmscon.conf中写[core] font Noto Sans CJK SC:styleRegular:size14重启kmscon服务后CtrlAltF3 进入的终端就能显示清晰的简体中文且vim中的中文注释、git log --oneline的中文提交信息、甚至htop进程名里的汉字全部原样呈现。但它的“理想”背后是沉重的现实约束强依赖 systemdkmscon通过 D-Bus 与logind通信获取 VT 控制权SysVinit 或 OpenRC 发行版需手动编写 init 脚本且无法保证 VT 切换可靠性KMS 硬性要求必须使用内核 DRM 驱动i915、amdgpu、radeon、nouveauVESA 或 fbdev 模式下直接拒绝启动内存与 CPU 开销显著实测在 4GB RAM 的笔记本上kmscon进程常驻内存 45MBCPU 占用率比原生 TTY 高 3~5 倍这对老旧设备是不可接受的。更隐蔽的问题在于字体回退机制。kmscon默认只加载配置中指定的单一字体当遇到该字体未覆盖的 Unicode 区段比如数学符号 ⊗、古汉字 它不会像桌面环境那样自动切换到备用字体而是直接渲染为空白或方块。我曾为某国产信创平台定制时发现其预装的Noto Sans CJK SC缺少《通用规范汉字表》外的生僻字最终不得不手动合并Noto Sans CJK JP和Noto Sans CJK KR的 glyph 表用fonttools重新打包字体文件——这个过程耗时两天且每次内核更新后都要重做。2.3 fbterm最古老也最“Linux 原教旨”的方案fbterm出生于 2005 年是纯粹的“帧缓冲终端”Framebuffer Terminal。它不依赖 X11也不碰 KMS而是直接mmap()/dev/fb0用软件渲染方式在帧缓冲上画出字符。其设计哲学非常朴素只要硬件有帧缓冲我就一定能显示中文。它的技术栈异常干净字体引擎自研的fbterm-font支持.fonWindows 位图字体和.ttfTrueType输入法通过libim接口接入fcitx或ibus但仅限于fbterm自身窗口内生效编码处理内置完整的 UTF-8 解码器可正确处理代理对surrogate pairs和组合字符combining characters。正因为这种“去中心化”设计fbterm在极端环境下表现出色在禁用 KMS 的 Intel GMA3100 集成显卡上稳定运行在init/bin/bash的救援模式下只要/dev/fb0可访问就能启动内存占用仅 8MB比kmscon低近 6 倍。然而它的“原教旨”也成了枷锁无 VT 切换支持fbterm是一个独立进程运行时会独占/dev/fb0你无法像 CtrlAltF1 那样切回图形界面必须CtrlAltBackspace强制退出鼠标与快捷键失效它不解析 X11 的XKeyEvent所有CtrlC、CtrlV操作需通过fbterm自定义键绑定实现且默认配置里CtrlShiftC复制文本的功能在 Wayland 下根本不可用字体渲染质量低下由于是纯软件渲染没有硬件加速16px 以上字体会出现明显锯齿且无法开启 subpixel rendering子像素渲染在 LCD 屏幕上文字发虚。我曾在一次现场故障排查中用fbterm在一台 BIOS 启动的旧服务器上查看中文日志结果发现fbterm把ls -l输出中的中文文件名宽度计算错误——它把每个中文字符当成 2 个英文字符宽导致后续列内容全部右移ls的权限列和大小列完全错位。查源码才发现fbterm的宽度计算函数get_char_width()对 UTF-8 的处理存在 off-by-one 错误这个 bug 自 2012 年起就存在于所有公开版本中却从未被修复。2.4 console-setup unifont官方“妥协派”的最后防线Debian/Ubuntu 系统自带的console-setup工具包代表了上游社区的官方立场不修改内核不引入新 daemon只在现有框架内做最大优化。它通过setupcon命令将unifont字体一个覆盖 Unicode BMP 区段的开源位图字体加载到内核控制台并设置console-keymaps-at键盘映射。unifont的特殊之处在于它是目前唯一被 Linux 内核主线接受的、包含中文字符的 PSF 字体。其字形数据直接编译进内核的drivers/tty/vt/consolemap.c因此无需用户态程序即可启用。执行以下命令sudo apt install console-setup fonts-unifont sudo dpkg-reconfigure console-setup # 在交互式配置中选择 UTF-8, Guess optimal character set, unifont sudo setupcon之后CtrlAltF2 进入的 TTY 就能显示基础中文GB2312 范围内的 65536 个汉字。但这套方案的“官方背书”掩盖不了其本质局限字体质量灾难unifont是 16×16 点阵字体放大后全是马赛克在 1080p 屏幕上阅读 10 行中文文档就是一场视力考验性能惩罚严重unifont的 PSF 文件体积达 12MB内核加载时需解压并构建字符映射表导致 TTY 初始化延迟 1.5~2 秒功能阉割彻底不支持粗体、斜体、下划线等 ANSI 转义序列的字体样式变化echo -e \033[1m加粗\033[0m会原样输出转义字符。更讽刺的是console-setup的配置逻辑本身就有缺陷。它默认将console-setup服务设为enabled但该服务实际只在multi-user.target启动时运行一次。如果你在运行时动态修改了/etc/default/console-setupsetupcon命令并不会自动重载配置——你必须手动执行sudo systemctl restart console-setup而这个 service 在大多数 systemd 版本中根本不存在导致配置变更永远不生效。这个 bug 在 Debian BTS 中标记为wontfix已逾 8 年。3. 实操全流程从零构建一个稳定可用的中文 TTY 环境以 kmscon 为例3.1 环境检查与前置准备避开 90% 的失败起点在敲下第一个git clone命令前必须完成三项不可跳过的验证。我见过太多人卡在这一步花三天时间调试最后发现只是内核没开一个 CONFIG 选项。第一步确认 KMS 驱动已激活运行lspci -k | grep -A 3 -i vga输出中必须包含Kernel driver in use: i915Intel、Kernel driver in use: amdgpuAMD或Kernel driver in use: nouveauNVIDIA 开源驱动。如果显示Kernel driver in use: vesa或Kernel driver in use: fbdevkmscon将直接报错failed to open drm device。此时你需要编辑/etc/default/grub找到GRUB_CMDLINE_LINUX行添加video...参数强制启用 KMS例如 Intel 平台加i915.modeset1执行sudo update-grub sudo reboot。第二步验证 systemd-logind 状态kmscon依赖logind分配 VT 资源。运行loginctl show-session $(loginctl | grep -o session-[0-9]* | head -1) -p Type输出必须为Typewayland或Typex11。如果返回Typeunmanaged说明当前会话未被logind管理常见于使用startx手动启动 X11在 WSL2 中运行WSL2 无 systemd-logind使用openrc或runit初始化系统。解决方案改用systemd启动桌面环境或在~/.bash_profile中添加export XDG_SESSION_TYPEwayland。第三步检查字体路径与权限kmscon默认从/usr/share/kmscon/fonts/加载字体但该目录在多数发行版中不存在。创建它并赋予kmscon用户读取权限sudo mkdir -p /usr/share/kmscon/fonts/ sudo chown root:root /usr/share/kmscon/fonts/ sudo chmod 755 /usr/share/kmscon/fonts/然后下载 Noto Sans CJK SC 字体官方 GitHub Release 页面提供.zip包解压后将NotoSansCJKsc-Regular.otf复制到上述目录。注意不要用fc-cache -fv刷新字体缓存kmscon不读取 Fontconfig 数据库。注意如果你的系统 locale 是en_US.UTF-8但需要显示中文不要修改全局 locale。kmscon会继承当前用户的LANG环境变量只需确保你的用户账户的~/.profile中包含export LANGzh_CN.UTF-8即可。全局修改 locale 可能导致apt等工具输出乱码这是新手最常犯的错误。3.2 源码编译与安装绕过包管理器的“完美幻觉”虽然 Ubuntu/Debian 提供kmscon的二进制包但实测发现其存在两个致命问题包含的kmscon二进制文件链接了旧版libdrm2.4.100在内核 6.1 上触发drmSetClientCap符号未定义错误预编译的kmscon.service文件硬编码了ExecStart/usr/bin/kmscon --vt3 --seatseat0而现代 systemd 要求--seat参数必须与logind中注册的 seat 名称一致否则无法获取 VT 控制权。因此必须从源码编译。以下是经过 12 次失败后验证的可靠步骤# 安装编译依赖Ubuntu/Debian sudo apt install build-essential meson ninja-build libdrm-dev libudev-dev \ libevdev-dev libinput-dev libsystemd-dev libxkbcommon-dev \ libpixman-1-dev libcairo2-dev libfreetype6-dev libfontconfig1-dev # 克隆官方仓库注意必须用 master 分支v9.x 之后的 tag 均有内存泄漏 bug git clone https://github.com/xkbcommon/kmscon.git cd kmscon # 创建构建目录并配置关键参数 meson setup builddir --buildtypeplain \ -Dsystemdtrue \ -Dlogindtrue \ -Ddrmtrue \ -Dudevtrue \ -Dlibinputtrue \ -Dxkbcommontrue \ -Dpixmantrue \ -Dcairotrue \ -Dfreetypetrue \ -Dfontconfigtrue \ -Dprefix/usr # 编译使用 4 线程加速但不要用 -j$(nproc)会导致内存溢出 ninja -C builddir -j4 # 安装注意必须用 ninja install不要用 make install sudo ninja -C builddir install编译成功后验证二进制文件是否链接正确ldd /usr/bin/kmscon | grep -E (drm|systemd|udev) # 正确输出应包含 libdrm.so.2, libsystemd.so.0, libudev.so.1如果看到libdrm.so.1或libsystemd.so.1说明 meson 配置参数有误需清理builddir重新配置。3.3 配置文件详解每一个参数都是血泪教训kmscon的配置文件/etc/kmscon/kmscon.conf是其稳定性的命脉。以下是我在线上环境稳定运行 18 个月的生产级配置每一行都对应一个真实踩过的坑[core] # 必须指定 VT 编号且不能与图形环境冲突GDM 默认占 VT1SDDM 占 VT2 vt 3 # seat 名称必须与 loginctl list-seats 输出完全一致通常是 seat0 seat seat0 # 启用硬件加速禁用则回退到软件渲染性能下降 70% accel true # 设置默认字体注意必须用绝对路径相对路径会静默失败 font /usr/share/kmscon/fonts/NotoSansCJKsc-Regular.otf # 字体大小14 是 1080p 屏幕的最佳平衡点小于 12 会模糊大于 16 会换行错乱 font-size 14 # 启用字体平滑但必须配合 freetype 的 subpixel rendering antialias true # 关键禁用 bitmap 字体回退否则遇到缺失 glyph 时会显示方块而非空白 bitmap-fonts false [keyboard] # 必须启用 XKB否则中文输入法无法工作 xkb true # layout 设置为 us, cn允许 CtrlSpace 切换中英文 layout us, cn # model 必须匹配物理键盘pc105 是绝大多数 USB 键盘的标准 model pc105 # variant 为空避免加载额外键映射导致 Shift2 输出 而非 variant [terminal] # 启用 256 色支持否则 vim 的配色方案会降级为 16 色 colors 256 # 关键设置正确的 TERM 类型否则 tmux 会报错 unknown terminal type term linux-kmscon # 启用鼠标支持但仅限于 xterm 协议Wayland 下无效 mouse true # 行缓冲大小设为 10000 可避免长日志滚动时卡顿 scrollback 10000 [logging] # 日志级别设为 warningdebug 级别日志会每秒写入 2MB 文件 level warning # 日志文件路径必须确保 /var/log/kmscon 可写 file /var/log/kmscon/kmscon.log特别强调term linux-kmscon这一行。很多教程建议设为xterm-256color这会导致tmux启动时报错unknown terminal type因为tmux的 terminfo 数据库中没有xterm-256color的完整定义。而linux-kmscon是kmscon自带的 terminfo 条目已预编译进系统执行sudo tic -s /usr/share/kmscon/terminfo.src即可安装。3.4 服务配置与开机自启让 TTY 中文成为系统本能kmscon的 systemd 服务文件/usr/lib/systemd/system/kmscon.service是一个模板单元必须通过实例化启用。创建/etc/systemd/system/gettytty3.service.d/override.conf注意不是kmscontty3.service[Unit] DescriptionKMSCON on %I Aftersystemd-user-sessions.service [Service] # 替换默认 getty 进程为 kmscon ExecStart ExecStart/usr/bin/kmscon --vt%I --seatseat0 --log-levelwarning # 关键设置 PAM 会话否则无法调用 PAM 模块进行认证 PAMNamelogin # 设置环境变量确保中文 locale 生效 EnvironmentLANGzh_CN.UTF-8 EnvironmentLC_ALLzh_CN.UTF-8 [Install] WantedBygetty.target然后启用服务# 重载 systemd 配置 sudo systemctl daemon-reload # 禁用原生 gettytty3 服务 sudo systemctl disable gettytty3.service # 启用 kmscon 实例 sudo systemctl enable gettytty3.service # 立即启动无需重启 sudo systemctl start gettytty3.service验证是否生效按下CtrlAltF3你应该看到kmscon的欢迎横幅接着是中文登录提示符用户名主机名 的密码。如果看到黑屏或立即返回图形界面执行sudo journalctl -u gettytty3 -n 50 --no-pager查看错误日志90% 的情况是seat名称不匹配或vt编号被占用。实操心得在调试阶段永远用sudo kmscon --vt3 --seatseat0 --log-leveldebug手动启动而不是直接启用服务。--log-leveldebug会输出详细的 DRM 设备枚举过程比如found drm device /dev/dri/card0或failed to open /dev/dri/renderD128这能帮你快速定位是驱动问题还是权限问题。一旦手动启动成功再转为服务模式。4. 常见问题与排查技巧实录那些文档里不会写的真相4.1 “中文显示为方块”问题的三级诊断法这是最普遍的故障但原因千差万别。我总结了一套三步定位法能在 2 分钟内锁定根源第一级确认字体文件可读且格式正确运行sudo kmscon --vt3 --font/usr/share/kmscon/fonts/NotoSansCJKsc-Regular.otf --log-leveldebug 21 | grep -i font观察输出如果出现failed to load font说明字体路径错误或文件损坏如果出现font has no glyphs for U4F60U4F60 是“你”字的 Unicode 码点说明该字体确实不包含中文字符需更换字体如果出现successfully loaded font但仍有方块进入第二级。第二级检查 locale 与编码一致性在kmscon启动后按CtrlAltF2切回原生 TTY执行locale echo $LANG cat /proc/sys/kernel/console_loglevel确保三者输出均为zh_CN.UTF-8。如果locale显示POSIX说明用户环境变量未生效需检查~/.profile是否被正确加载如果console_loglevel小于 7kmscon的 debug 日志可能被内核过滤需执行sudo dmesg -n 8提升日志级别。第三级验证 DRM 设备权限与能力运行sudo strace -e traceopenat,open,read -p $(pgrep kmscon) 21 | grep -E (drm|render)观察kmscon是否成功打开了/dev/dri/card0和/dev/dri/renderD128。如果只打开card0而失败于renderD128说明用户不在render用户组中sudo usermod -a -G render $USER sudo systemctl restart gettytty3.service注意render组在 Ubuntu 22.04 中默认存在但在 CentOS Stream 9 中需手动创建。不要尝试chmod 666 /dev/dri/*这会破坏 SELinux 策略导致系统安全警告。4.2 “输入中文时卡死”问题的底层机制当你在kmscon中启动fcitx5输入“你好”后光标停止响应这不是fcitx5的 bug而是kmscon与输入法框架的 IPC 协议不兼容所致。kmscon使用libinput获取原始按键事件但fcitx5期望的是 X11 的XIM协议或 Wayland 的text-input-v3协议。两者之间缺少转换层。解决方案只有两个推荐方案放弃fcitx5改用ibus并启用ibus-kmscon插件需从源码编译ibus启用kmsconbackend应急方案在kmscon中不启用输入法改用CtrlShiftU输入 Unicode 码点如CtrlShiftU 4f60 enter输入“你”字虽然效率低但 100% 可靠。我曾为某银行信创项目定制时发现ibus-kmscon插件在 ARM64 平台上存在浮点数精度错误导致中文候选框位置偏移 200 像素。最终解决方案是修改ibus-kmscon源码中的坐标计算函数将float强制转为double重新编译后问题消失。这个补丁至今未被上游接受但已在我维护的私有仓库中稳定运行两年。4.3 “VT 切换后图形界面崩溃”问题的硬件级归因在kmscon运行时按下CtrlAltF1切回图形界面Gnome Shell 突然黑屏或无限旋转这不是软件 bug而是GPU 内存管理冲突。kmscon和 X11/Wayland 同时申请 GPU 显存当显存不足时内核 DRM 驱动会随机 kill 其中一个进程。诊断方法执行dmesg | grep -i out of memory如果看到drm_kms_helper: timeout waiting for object即可确认。解决方案分三级一级推荐为kmscon分配专用 VT并禁止其与图形环境共享 GPU。编辑/etc/default/grub添加videoefifb:offUEFI 系统或videovga16fb:offBIOS 系统阻止内核加载通用帧缓冲驱动二级降低kmscon的显存占用在配置文件中添加[core] gpu-memory-limit 64单位 MB三级终极在 BIOS 中关闭Integrated Graphics的DVMT Pre-Allocated Memory将其从 64MB 改为 32MB为kmscon留出余量。这个方案在联想 ThinkPad X1 Carbon 第 10 代上实测有效但会略微降低图形界面的 3D 性能。权衡之下运维人员的中文 TTY 稳定性优先级更高。4.4 “中文文件名 ls 显示乱码”问题的 shell 层真相在kmscon中执行ls看到test_中文.txt显示为test_.txt很多人以为是终端问题其实根源在ls命令自身。GNU coreutils 2.37 版本引入了--show-control-chars选项默认启用它会将非打印字符包括 UTF-8 的多字节序列转义为^、M-^等符号。验证方法执行ls --show-control-chars与ls --hide-control-chars对比输出。解决方案是修改ls的 alias# 在 ~/.bashrc 中添加 alias lsls --colorauto --hide-control-chars # 然后 source ~/.bashrc更深层的原因是ls的字符宽度计算函数mbswidth()在某些 locale 下存在缓存 bug。我在 Arch Linux 上复现此问题时发现只要执行一次locale -a | grep zh_CNls就会自动修复宽度计算。这说明ls的 locale 初始化逻辑存在竞态条件而locale -a命令恰好触发了正确的初始化路径。这个技巧虽不优雅但比重装 coreutils 更快。5. 方案选型决策树根据你的实际场景选最合适的那一个面对cjktty、kmscon、fbterm、console-setup四种方案没有“最好”只有“最合适”。我为你整理了一份基于真实场景的决策树每个分支都来自我亲手部署过的 37 个案例5.1 你是嵌入式设备开发者选cjktty但必须满足三个前提前提一硬件平台明确使用 GBK 编码的固件与日志。例如海思 Hi3516DV300 摄像头模组其串口输出日志默认 GBKcjktty可直接解析前提二内存严格受限≤512MB RAM且无 GPU 加速需求。cjktty的 12KB 内核体积优势在此场景无可替代前提三接受放弃现代 Linux 特性。你必须禁用systemd改用 BusyBox init且所有用户空间工具如busybox vi需重新编译以支持 GBK。如果不满足任一前提立刻转向fbterm。我在瑞芯微 RK3399 平台上测试过fbterm在 1GB RAM 下启动时间仅比cjktty慢 0.8 秒但支持 UTF-8 和任意字体长期维护成本更低。5.2 你是国产信创系统运维工程师选kmscon但必须规避两个雷区雷区一不要在麒麟 V10 SP1 上使用kmscon9.0.0。该版本与麒麟内核的kylin-drm驱动存在符号冲突必须降级到kmscon