显示器驱动这类东西平时不太会被普通用户注意到但负责嵌入式设备、瘦客户机或老式商用主板的人大概率见过 SM750 这个芯片。它是一颗很常见的 2D 显示控制芯片经常出现在国产工控主板、云终端、医院挂号机、银行排队机这类设备里。这类设备的通病是Windows 下驱动好找Linux 下就比较尴尬以前要么靠内核里已经很边缘的 framebuffer 路径要么找第三方闭源包凑合。这次 SM750 的 HDMI DRM 驱动发布支持 2048 宽输出和 2560x1080 超宽屏分辨率对还在维护这类设备的人来说是一个值得跟进的改变。这篇文章不打算只复述发布信息。我会把 SM750 的显示链路、DRM 驱动的作用、2560x1080 这类超宽分辨率是怎么被支持的、以及拿到驱动后怎么验证、出问题怎么排查一次讲清楚。如果你正在做嵌入式 Linux 开发、显示驱动移植或者手头正好有一台带 SM750 的设备需要接 2K 级别显示器下面这些内容可以给你省点时间。1. SM750 这个芯片和 DRM 驱动到底解决了谁的痛点1.1 先搞清楚 SM750 是哪类芯片SM750 不是 CPU也不是主力显卡它是一颗负责显示输出的控制芯片。在很多商业整机里主板上的处理器可能很弱板载一颗显示芯片专门承担像素输出和简单的 2D 加速把主 CPU 从显示任务里解放出来。SM750 就是这类角色。它的典型特征有三个2D 能力为主能处理 framebuffer、窗口叠加、基本 2D 加速但 3D 能力很弱。显存独立但不大常见板载版本配的是独立显存容量通常在几十 MB 这个量级不像桌面显卡那样有几个 GB。接口多样具体板卡上可能是 VGA、DVI、LVDS、HDMI 或其中几种组合。标题里提到的 HDMI 输出要看板上实际引出的接口和物理层方案。这类芯片之所以在国内设备里出现频率高是因为它足够便宜稳定性也经过了相当长时间的市场验证。对商用设备来说显示不追求炫追求的是稳定、低成本、能长时间开机不花屏。1.2 以前 Linux 下驱动为什么让人头疼如果只是跑 WindowsSM750 的驱动基本不用操心厂商会提供安装包。但 Linux 环境就复杂了。老一代的方案是走内核的 sm750fb framebuffer 驱动配合 Xorg 里的老模块使用。这套东西在 2020 年之前的发行版里还能凑合但这些年 Linux 显示栈已经明显转向 DRM/KMS 体系。KMS 的意思是 Kernel Mode Setting由内核统一管理显示模式、显存、连接器状态。fbdev 老路径在新内核里越来越边缘化。这带来的实际问题是新内核的某些特性兼容不上或者需要额外补丁。桌面环境、Qt 应用、Wayland 合成器对新驱动的适配越来越依赖 KMS 接口。出问题时日志不直观很难判断到底是芯片没启动、模式没设对还是上层合成器没收到信号。这次发布的 SM750 HDMI DRM 驱动本质上就是给这颗芯片补上了通往现代 Linux 显示栈的接口。1.3 谁最需要关注这个发布我认为主力受益者有三类维护存量设备的人手里有大量 SM750 工控板在跑 Linux需要在新内核上继续稳定输出。做嵌入式 Linux 产品的人正在选型显示方案希望芯片能被内核主线 DRM 框架接管而不是依赖厂商私有补丁。学习 Linux 驱动开发的人SM750 的驱动结构不算臃肿作为 KMS 驱动学习样本很合适能看清 connector、encoder、crtc 之间的关系。如果你只是台式机用户手头也没有 SM750 设备那这篇内容可以当作显示栈知识看不需要真的去刷驱动。2. 2048 宽输出和 2560x1080 超宽屏背后靠的是显示时序能力2.1 分辨率的本质不是“加一行设置”很多人以为支持某个分辨率就是把分辨率数值写进某个列表然后重启。实际上显示分辨率背后是一整套时序参数通常用一个叫 modeline 的东西表示。它包含有效图像的宽度和高度比如 2560x1080。像素时钟频率也就是每秒要输出多少个像素点。水平前肩、水平同步、水平后肩。垂直前肩、垂直同步、垂直后肩。刷新率。显示器不会自己产生一张完整的画面它会按固定的节奏刷新。显卡或显示控制芯片负责在正确的时刻把像素数据送到接口上。这个节奏如果和显示器对不上要么黑屏要么画面闪烁撕裂要么直接无法点亮。所以DRM 驱动支持 2560x1080不只是把分辨率数值暴露出来而是要保证芯片的显示控制器能够生成符合这个分辨率的时序并且把足够大的 framebuffer 分配好。2.2 2048 宽这条线有什么讲究这次发布里提到“2048 宽输出”这个数字很关键。很多老一代显示控制芯片有一个隐形的宽度边界超过一定宽度之后内部 FIFO 带宽、行缓冲对齐、内存访问策略就会出问题。2048 这个数值在显示领域经常作为一个分界点出现因为它是 2 的幂对齐友好。支持 2048 宽输出意味着显示控制器在宽度大于 1920 的范围内能稳定分配行缓存。超过 2048 的桌面尺寸不再必须走裁剪或缩放路径。驱动会为宽屏模式准备合适的 framebuffer 对齐策略。这不是一个单纯“把上限调大”的操作它涉及内存带宽的验证和模式表的扩展。2.3 2560x1080 是超宽屏里的特殊档位2560x1080 是 21:9 超宽屏像素量大约是 1920x1080 的 1.33 倍。它在带宽需求上已经接近 2K 级别对显示控制芯片的像素时钟要求比 1080p 高出一截。如果芯片的 PLL 或时钟源不能输出足够高的像素时钟单靠软件改 modeline 是点不亮的。所以这次驱动能支持 2560x1080背后至少意味着三件事驱动里的模式生成逻辑已经能构造出 2560x1080 的时序参数。芯片的时钟能力足够覆盖这个分辨率所需的像素时钟。framebuffer 的尺寸计算、行偏移和内存对齐逻辑已经能处理 2560 宽度的场景。不过要注意一点驱动支持这个模式不代表任何一块 SM750 板子都能稳定输出。具体能不能点亮还取决于板载输出接口、转接芯片、线材和显示器本身。尤其是 HDMI 接口如果板卡是从 DVI 物理层转接出来的那么信号在带宽和 EDID 传达上会有限制。这个坑后面单独说。2.4 模式列表从哪来EDID 和内置模式表DRM 驱动获取可用分辨率的方式主要有两种从显示器读取 EDID显示器通过 DDC 通道把支持的模式列表发给驱动这是最常见的路径。驱动内置模式表当 EDID 缺失、损坏或显示器不带 EDID 时驱动根据硬件能力提供一个固定模式列表。这次发布里强调支持 2560x1080更多是指驱动层面具备生成这个模式的能力。实际插上显示器后是否自动出现在模式列表里要看你插的显示器 EDID 是否完整地支持这个分辨率。如果显示器 EDID 正常通常不需要手动干预。如果 EDID 缺失你就得靠驱动内置模式表或者手动添加 modeline。这个操作后面会提到。3. 从 DRM 内核到 Qt 应用显示链路里的每一次中转3.1 完整链路是什么在 Linux 桌面环境下一个 Qt 窗口最终显示在屏幕上要经过很多层。SM750 的 DRM 驱动处于最底层但如果你要调试为什么画面不对光看驱动不够。完整的链路是这样的屏幕硬件 ← DRM 内核驱动 ← X server(Xorg) ← X11 协议 ← Qt(xcb 插件) ← 你的 Qt 程序如果用的是 Wayland链路则是屏幕硬件 ← DRM 内核驱动 ← Weston/Sway 等合成器 ← Wayland 协议 ← Qt(wayland 插件) ← 你的 Qt 程序每一层都在上一层的输出上做处理。DRM 驱动负责把最底层的模式设置好Xorg 选一个分辨率、组织 framebufferX11 协议负责窗口、绘制和事件分发Qt 通过 xcb 插件和 X server 通信。只要显示模式不匹配任何一层都可能出现问题。3.2 DRM/KMS 到底在链路里扮演什么角色DRM 驱动在 Linux 显示体系里是内核和用户的边界。它提供几个核心对象CRTC扫描输出控制器决定从 framebuffer 里怎么读出数据并产生时序信号。Encoder把像素信号编码成特定接口协议比如 HDMI、DVI、LVDS。Connector物理连接器检测是否有显示器接入维护 EDID 和当前模式状态。Plane显示平面负责把 framebuffer 内容合成到输出上。KMS 的价值在于上面这些对象全部由内核统一管理。用户空间的 Xorg、Wayland 合成器不用直接去操作寄存器而是通过 DRM 提供的接口来设置 mode、提交 framebuffer。这带来的好处是只要 SM750 驱动把 KMS 接口实现好上层的 Xorg、Qt、GTK 都无需专门适配这颗芯片。这也是为什么现在很多人强调 KMS而不是继续维护老 fbdev。3.3 用户空间怎么操作 DRM 设备驱动加载成功后系统会产生 /dev/dri/card0 之类的设备节点。用户空间的工具和库通过这个节点访问显示能力libdrm 是底层库提供 ioctl 封装。modetest 可以查看连接器状态、模式列表和 framebuffer 信息。xrandr 是 Xorg 环境下的分辨率管理工具。weston 或 sway 这类合成器直接走 DRM/KMS。这意味着即使你没有图形界面也可以先用命令行工具验证 SM750 驱动是否正常工作。图形界面出问题时先用 modetest 排除内核驱动下面的问题再往上检查 Xorg 或合成器效率要高得多。3.4 为什么链路长出问题时要分层看待很多人在显示出问题时第一反应是“驱动坏了”。但实际上显示链路每一层都有可能出现兼容性问题驱动层模式设置失败、连接器检测不到、显存分配失败。Xorg 层配置错误、驱动加载顺序不对、分辨率列表没刷新。应用层Qt 的 xcb 插件没有拿到正确的屏幕缩放窗口画不出来。所以排查时要先确认 DRM 层正常再用 xrandr 确认 Xorg 层最后再去看 Qt 或者具体应用。不要一上来就怀疑驱动也不要一黑屏就去改源码。4. 拿到驱动后怎么验证 2560x1080 能不能开出来4.1 建议先做一轮最小验证如果你手里有一套带 SM750 的设备想验证这次发布的能力我建议不要直接接上超宽屏就开搞。先把环境固定下来做一轮最小验证。需要准备的东西带 SM750 的主板或整机。一根可靠的 HDMI 或 DVI 线根据板卡的实际接口来。一台支持 2560x1080 的显示器最好确认显示器本身的 EDID 信息是完整的。Linux 系统内核版本要足够新才能包含或加载这个 DRM 驱动。modetest、dmesg 这些基本维护工具。如果内核里还没有集成这个驱动需要先按模组或补丁方式把它装进去。加载方式取决于驱动是编译进内核还是作为外部模块不同环境不一样。建议先看驱动发布说明里给的加载路径。4.2 第一步确认驱动是否加载成功开机之后先看内核日志里有没有对应的驱动信息dmesg | grep -i sm750如果驱动正常加载应该能看到设备识别、连接器扫描或者模式列表初始化的日志。如果没有输出先确认驱动模块是否被加载lsmod | grep sm750再检查设备节点是否创建ls -l /dev/dri/正常情况下会有 card0 或者 card1。如果设备节点不存在多半是驱动没有编译进去或者设备树、PCI 枚举阶段没有识别到硬件。4.3 第二步用 modetest 查看模式列表modetest 是 DRM 调试中最直接的工具。先列出所有设备modetest -M sm750或者先不管驱动名直接扫描modetest -p重点看连接器部分的输出。正常情况下会列出连接器状态、物理接口类型和所有可用模式。如果连接器状态是 connected并且模式列表里有 2560x1080 或 2560x108060Hz说明驱动已经把这个模式暴露出来了。如果连接器状态是 disconnected先检查线材、接口和显示器电源。4.4 第三步在 Xorg 下切换分辨率如果你的系统跑的是 Xorg可以先用 xrandr 确认当前输出xrandr输出里会列出显示器名称和可用分辨率列表。如果 2560x1080 在列表里直接切换xrandr --output HDMI-1 --mode 2560x1080注意输出名称不一定是 HDMI-1要以 xrandr 实际显示为准。切换之后观察画面是否正常铺满有没有黑边、花屏或闪烁。如果 xrandr 列表里没有 2560x1080但显示器确实支持可能是 EDID 没有把这个模式传回来。可以尝试手动添加 modeline。具体做法是先用 cvt 生成时序参数再用 xrandr --newmode 和 --addmode 注入比如cvt 2560 1080 60 xrandr --newmode 2560x1080_60.00 实际时序参数 xrandr --addmode HDMI-1 2560x1080_60.00 xrandr --output HDMI-1 --mode 2560x1080_60.00这种方式在驱动层已经支持、只是 EDID 未上报时比较有用。如果驱动层本身没有这个模式能力手动注入也不一定能点亮。4.5 第四步用 Qt 或通用图形程序验证分辨率切换成功后还需要确认上层应用能正常适配。Qt 程序在 X11 下走 xcb 插件它会读取 X server 提供的屏幕尺寸。如果 Xorg 已经在 2560x1080 下工作Qt 应用一般会自动填满屏幕。你可以在普通程序里放一个全屏窗口或者在终端里查看显示服务器报告的屏幕尺寸xdpyinfo | grep dimensions如果 dimensions 显示的是 2560x1080说明链路已经通到 X11 层。Qt 程序的窗口布局、鼠标坐标、缩放比例都以这个尺寸为准。如果里面某个 Qt 应用在超宽屏下布局错乱不要先怪 SM750 驱动。先确认 X11 层尺寸是否正确再用 QT_SCALE_FACTOR 或 Qt 的屏幕缩放机制去调应用。问题大概率出在应用对宽屏适配而不是显示驱动。4.6 验证结果怎么判断可以按下面的表来判断每一层是否正常验证层命令或位置正常结果异常表现驱动加载dmesg能看到 SM750 设备识别无日志设备节点缺失DRM 设备/dev/dri/card0存在且可读设备不存在连接器状态modetest -pconnected有模式列表disconnected模式列表为空模式设置xrandr2560x1080 可用并可切换模式缺失切换后黑屏X11 尺寸xdpyinfodimensions 为 2560x1080尺寸仍为旧分辨率Qt 应用窗口显示全屏铺满文字不糊布局错乱窗口越界这一套走完基本能确定 SM750 DRM 驱动在你手头这块板子上是否正常工作。5. 黑屏、分辨率缺失、输出空白按这个顺序排查5.1 容易误判的几个点SM750 这类嵌入式显示芯片的调试同样一个黑屏现象原因可能差得很远。我建议不要上来就改驱动源码先按下面的顺序过一遍很多时候问题根本不在驱动本身。常见的误判有这些“驱动没加载”实际上是内核没有把硬件枚举出来。“驱动不支持 2K”实际上是 EDID 没读到显示器模式没上报。“HDMI 坏了”实际上线材或转接头的 DDC 通道有问题导致 EDID 传输失败。“Qt 显示不了”实际上是 Xorg 层的分辨率没有切换成功。排查的第一步永远是把现象写清楚是完全没有信号还是画面闪、花屏还是只有部分分辨率不可用。5.2 排查顺序先物理再 EDID再内核再上层我从实际经验里总结的排查链路是这样的物理接口确认板卡输出接口和显示器输入接口一致。SM750 板卡如果是 DVI 转 HDMI 座要理解它的信号本质是 DVI带宽上限和 EDID 特点会和原生 HDMI 不同。线材和供电换一根短一点的线排除线材损耗。HDMI 线的质量对高分辨率影响很明显尤其是 2560x1080 这种接近 2K 带宽的场景。EDID用 modetest 看连接器是否 connected看模式列表里有没有 2560x1080。如果没有多半是 EDID 没读到或显示器的 EDID 不完整。内核日志dmesg 里看有没有和 SM750、DRM、HDMI 相关的错误。驱动参数有些板卡需要额外指定输出类型或初始化方式看发布说明里有没有相关参数。上层显示服务器确认 X org 或合成器有没有接住驱动提供的模式xrandr 能不能切到目标分辨率。应用层适配最后才考虑 Qt、GTK 或者其他应用对超宽屏的适配问题。下面是常见问题和排查方向现象优先排查方向次要排查方向完全无信号线材、接口、显示器输入源驱动是否加载连接器状态连接器 disconnectedEDID 通道、线材、物理接口驱动对连接器检测是否正常模式列表为空EDID 缺失显示器是否上电驱动内置模式表是否启用有模式但切换黑屏像素时钟是否足够时序是否匹配线材带宽刷新率是否过高切换后不断闪烁线材质量、刷新率、HDMI 时钟稳定性显示器内部缩放是否触发分辨率超过 2048 后花屏行缓存、framebuffer 对齐驱动是否有宽度限制遗漏重启后分辨率丢失Xorg 配置没有保存显示器 EDID 在上电时序上不稳定5.3 关于“EDID 没读到”这件事EDID 是显示器和驱动之间沟通的“身份信息”它是一段 128 字节或更长的数据存放在显示器内部的存储芯片里通过 DDC 通道传输。DDC 通道依赖物理引脚的连通性HDMI 线里如果有一根针接触不良、转接头质量问题都可能导致驱动读不到 EDID进而拿不到 2560x1080 模式。读不到 EDID 时modetest 里连接器状态通常会变成 disconnected或者模式列表为空。这时可以先强制指定一个 EDID 或 modeline 来验证硬件本身能不能输出。不过要注意强制的 modeline 如果和显示器内部时序不能对上画面可能依然无信号。更稳妥的做法是换线。换显示器。检查转接头是否支持高带宽。如果这些都不行再考虑驱动层面强制注入模式。不要一开始就怀疑 SM750 驱动对超宽屏支持有问题。5.4 关于转接和物理层差异的提醒SM750 这颗芯片历史悠久不同板卡对 HDMI 的实现方式不一样。有的板子引出的是原生 HDMI 信号有的则是 DVI 信号通过转接芯片变成 HDMI 座。两种方案对调试的影响不太一样原生 HDMI 支持音频和完整 EDID 通道更接近普通显示器场景。DVI 转 HDMI 通常不支持 HDMI 音频EDID 也可能只暴露 DVI 模式这时 2560x1080 这种依赖高带宽的模式可能不会自动出现。判断方法很简单看板卡资料里 HDMI 是否支持音频传输。如果资料没写清楚可以用 edid-decode 工具读取 EDID 内容看里面的接口类型标识。注意如果板卡是 DVI 物理层遇到 2560x1080 点不亮不要急着骂驱动。先确认物理层方案是否支持这个带宽。另外热词里提到的“edp 转 hdmi out 时 panel 时序、lane 和速率等参数要求”对 SM750 场景也有参考意义。显示接口转换时最终输出的时序要以目标接口的带宽和时钟为准不是输入源多少分辨率输出就一定能按多少分辨率跑。中间多一个转接芯片就多一个带宽瓶颈和时序校准环节。5.5 什么时候才需要去动驱动或设备树如果你已经确认物理接口、线材、显示器都没问题EDID 也能正常读取但模式列表里就是没有 2560x1080这时才考虑驱动或设备树层面的处理。驱动层面常见做法是在驱动内置 mode table 中追加上目标 modeline。检查 framebuffer 最大宽度限制必要时修改宽度判断逻辑。确保像素时钟计算支持目标频率。设备树层面常见做法是检查输出接口类型是否与硬件对应。确认连接器默认状态避免热插拔检测异常。如果板卡有多个显示输出确认路由是否正确。这些操作需要对 DRM 框架和具体板卡硬件都比较熟悉新手建议先拿 modetest 和 xrandr 把问题定位到具体层次再决定要不要改内核层。不要一上来就找驱动源码改那样容易把简单问题复杂化。6. 开源驱动不只是一份源码更是一条可以长期维护的路径6.1 闭源驱动的老问题还在在 SM750 这类芯片上厂商通常会提供 Windows 驱动Linux 支持则不一定完整。有些厂商会提供预编译的二进制模块但二进制模块有几个长期痛点内核版本升级后模块可能加载失败或需要重新编译适配。出现问题时没有源码可查只能靠日志猜。用户空间和内核接口变化时厂商更新速度不一定跟得上。无法深度定制比如加一个自定义分辨率、改某种时序输出。对消费级用户来说闭源驱动勉强够用。但对嵌入式产品和个人开发者来说闭源驱动意味着一种不可控你依赖厂商的更新节奏依赖它愿意支持的内核版本依赖它在安全补丁上的态度。6.2 开源 DRM 驱动带来的改变这次 SM750 的 DRM 驱动以开源方式发布最大价值不是“免费”而是把显示控制能力纳入到 Linux 内核的公开框架里。具体能带来这些实际好处可读源码出现问题时可以打开源码看寄存器操作、模式设置和连接器检测逻辑。可加日志可以用 printk、dev_dbg 等手段在关键路径上打印信息帮助定位。可改参数如果你想增加分辨率、调整时序、适配特殊面板可以在源码层面修改并重新编译。可跟主线如果驱动进入内核主线后续内核升级会有更持续的维护。可参考学习DRM 驱动开发门槛不低一套简洁的 2D 驱动实现可以让学习者更快理解 KMS 对象关系。6.3 开源不代表零维护这里要说一句不那么乐观的话开源驱动发布不等于装上之后就一劳永逸。DRM 内核 API 也会演进驱动需要跟着调整。如果你的产品要长期维护不能只下载一次源码就丢在那里要关注内核版本变化对驱动的影响。另外开源驱动只是把能力开放出来具体到某个板卡上的初始化时序、供电要求、接口物理层可能还需要板卡厂商提供补充信息。开源解决了“有路可走”的问题但不等于每个硬件细节都自动对齐。所以我的建议是把驱动源码纳入到你的镜像构建体系里方便重复构建和保存补丁。记录板卡型号、内核版本、显示接口、面板参数。每次换内核大版本时先跑一轮单分辨率和多分辨率切换验证。对于从产品选型角度考虑的人开源驱动还意味着供应链上的选择更自由。你不一定非要用某家厂商封装的私有显示方案可以按 DRM 框架选择适合自己的显示控制芯片。6.4 对 Linux 驱动学习者的意义如果你正在学 DRM 驱动开发SM750 的驱动是一个不错的入门观察对象。它不像那些复杂的 GPU 驱动那样有海量调度、显存管理、固件加载逻辑但它把 KMS 的骨架体现得比较清楚。你可以重点看这些部分驱动如何注册 DRM 设备。连接器的检测函数怎么写。CRTC 的 mode_set 如何处理分辨率变化。像素时钟和 mode 参数的计算路径。看懂这些小而完整的实现再回头去读更复杂的驱动比如各种 SoC 内置显示控制器或独立显卡驱动会轻松不少。7. 什么情况下用得上什么情况下别指望太多7.1 很适合用的场景你可以在这些场景里放心考虑 SM750 DRM 驱动的支持Linux 桌面的商业终端云终端、前台展示机、信息查询机。这些设备不追求 3D 性能只要稳定输出文字和视频即可。嵌入式 Linux 产品需要长期固定显示界面希望显示输出由内核统一管理。超宽屏商务展示需要输出 21:9 内容的设备比如接待台、大屏信息终端。驱动学习和科研环境想研究 DRM/KMS 的人手头正好有 SM750 板卡。7.2 不太适合指望的场景以下场景就不要对 SM750 抱太多期望3D 游戏SM750 的 2D 定位决定了它不是为 OpenGL 游戏性能设计的。4K 高刷这次发布支持到 2048 宽和 2560x1080它并不等于支持所有 4K 高刷模式。芯片内部带宽和显存规格本来就不是为 4K 高刷准备的。多屏复杂组合如果产品需要多路 4K 输出应该选更现代的显示控制方案。完全不懂 Linux 的命令行环境DRM 驱动只解决 Linux 显示链路底层能力系统集成和调试仍然需要基本的 Linux 操作知识。7.3 我的实际建议不管你是设备维护者还是产品开发人员这个发布都值得关注但不值得立刻把现有稳定方案推翻。更稳妥的做法是先拿一块闲置板卡搭一个最小验证环境确认驱动在你要用的内核版本上能编译、加载、输出。单独接一台 2560x1080 显示器把模式列表、xrandr 切换、Qt 全屏显示这三个环节验证通过。之后再考虑是否把驱动纳入生产镜像。如果只是学习默认配置和文档足够入门。如果要投入生产就要把驱动版本、内核版本、发行版构建方式、输出接口物理方案全都记录归档。这样后续内核升级或硬件批次变化时你有一个可以快速定位问题的基线。踩过几次显示栈的坑之后我最大的感受是很多黑屏和分辨率问题不是驱动能力不够而是前置环境和输入材料没有处理干净。先确认物理输出链路再确认 EDID然后看内核日志最后才有必要去动源码。这套顺序在 SM750 上适用在其它 DRM 驱动上同样适用。