windows-监视筛选器驱动程序

解读： 这里引入了 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），仅与自家控制面板通信
必要性 必需 可选，仅当有非标准功能时才需要