window显示驱动开发—监视筛选器驱动程序

“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），仅与自家控制面板通信
必要性	必需	可选，仅当有非标准功能时才需要