"Microsoft 提供了一个通用的监视器类函数驱动程序，它可以处理大多数与监视器相关的任务。"
- 解读： 再次强调了 Monitor.sys 的基础性和通用性。对于绝大多数标准操作（如识别显示器、获取支持模式），微软的驱动已经完全足够。
"除非供应商想提供超出监视器类函数驱动程序所能提供的服务，否则没有必要使用供应商提供的监视器驱动程序。"
- 解读： 这定义了供应商需要开发自己驱动程序的唯一场景。如果显示器没有任何"特殊功能"，那么使用微软的通用驱动就是最佳选择，这保证了稳定性和兼容性。供应商驱动只是为了实现增值功能。
"如果监视器供应商选择提供筛选器驱动程序，则该驱动程序由筛选器设备对象（筛选器 DO）来表示，该对象位于监视器设备堆栈中功能设备对象 (FDO) 的上方。"
- 解读： 这里引入了 Windows 驱动程序架构中的两个核心概念：
- FDO (Functional Device Object)： 由功能驱动程序（此处即 Monitor.sys）创建，代表它对设备的主要功能职责。
- Filter DO (Filter Device Object)： 由筛选器驱动程序创建。它被附加（Attach） 到设备堆栈上，位于 FDO 的上方。这意味着所有的 I/O 请求包（IRP）会先经过 Filter DO，再到达 FDO。这使得筛选器可以拦截、修改或处理请求。
可视化堆栈：
[用户模式应用程序]
|
v
[内核模式] - 监视器设备堆栈
|
+--> [Filter DO] (供应商提供的筛选器驱动程序，处理自定义请求)
|
+--> [FDO] (微软的 Monitor.sys，处理标准 DDC/CI 等请求)
|
+--> [PDO] (物理设备对象，由总线驱动创建)
|
v
[硬件显示器]"筛选器驱动程序也由监控器供应商提供，它可以处理来自用户模式应用程序的请求。筛选器驱动程序与用户模式应用程序之间的接口是专用的，只有监控器供应商知道。"
- 解读： 解释了供应商的"自定义控制面板"软件（用户模式应用程序）如何与它的驱动程序（内核模式筛选器）通信。
- 专用接口： 这种通信不通过标准的 Windows API。供应商会定义自己私有的IOCTL (I/O Control Code) 协议。只有供应商自己的控制面板软件知道如何发送这些特定的IOCTL请求，也只有它自己的筛选器驱动程序知道如何解析和执行这些请求。
- 安全性/封闭性： 这种设计使得功能是封闭的，其他应用程序无法直接调用这些高级功能。
"监视器设备堆栈不会通过显示数据通道命令接口 (DDC/CI) 来对显示器进行编程控制，因此计数器供应商不应编写用于此目的的筛选器驱动程序。"
解读： 这是极其重要的一点澄清和限制。
- Monitor.sys 已经处理了 DDC/CI： 微软明确表示，标准的、符合规范的 DDC/CI 操作（如获取EDID、设置亮度）是由其通用驱动程序 Monitor.sys (FDO) 负责处理的。
- 供应商驱动的禁区： 供应商不应该再写一个筛选器驱动程序去"重新实现"或"劫持"标准的 DDC/CI 命令。这样做会破坏系统的稳定性和一致性。
- 供应商驱动的正确领域： 供应商的筛选器驱动应该只处理那些超出 DDC/CI 标准规范的、供应商自己定义的私有命令。例如，一台显示器可能有一个特殊的"电竞模式"，需要通过一组非标准的指令来激活，这个功能就属于供应商驱动的范畴。
核心要点总结
| 方面 | 负责方 (微软 Monitor.sys) |
负责方 (供应商筛选器驱动) |
|---|---|---|
| 主要角色 | 提供标准功能 和基础兼容性 | 提供增值功能 和差异化特性 |
| 通信协议 | 处理标准 DDC/CI 协议 | 处理供应商私有协议 |
| 设备对象 | 创建 FDO (功能设备对象) | 创建 Filter DO (筛选器设备对象)，附加在FDO之上 |
| 用户接口 | 通过标准系统API（如SetupAPI） | 通过专用接口（私有IOCTL），仅与自家控制面板通信 |
| 必要性 | 必需 | 可选，仅当有非标准功能时才需要 |