Controladores de cliente HID de teclado y mouse
Nota:
Este tema es para desarrolladores que crean controladores para clientes HID de teclado y mouse. Si desea corregir un mouse o un teclado, consulte:
En este artículo se describen los controladores cliente HID de teclado y mouse. Los teclados y ratones representan el primer conjunto de clientes HID que se estandarizaron en las tablas de uso de HID e implementaron en sistemas operativos Windows.
Los controladores cliente HID de teclado y mouse se implementan en forma de controladores de asignador HID. Un controlador de asignador HID es un controlador de filtro WDM en modo kernel que proporciona una interfaz bidireccional para las solicitudes de E/S entre un controlador de clase no HID y el controlador de clase HID. El controlador del asignador asigna las solicitudes de E/S y los protocolos de datos de uno al otro.
Windows proporciona controladores de asignador HID suministrados por el sistema para el teclado HID y dispositivos HID mice.
Información general y arquitectura
En la ilustración siguiente se muestran las pilas de controladores suministrados por el sistema para dispositivos usb de teclado, mouse y panel táctil.
En la ilustración se muestran los siguientes componentes:
- KBDHID.sys: controlador del asignador de cliente HID para teclados. Convierte los usos de HID en códigos de examen en interfaz con el controlador de clase de teclado existente.
- MOUHID.sys: controlador del asignador de cliente HID para mouses/touchpads. Convierte los usos de HID en comandos del mouse (X/Y, botones, rueda) en interfaz con el controlador de clase de teclado existente.
- KBDCLASS.sys: el controlador de clase de teclado proporciona funcionalidad para todos los teclados y teclados del sistema de forma segura.
- MOUCLASS.sys: el controlador de clase de mouse proporciona funcionalidad para todos los ratones y teclados táctiles del sistema. El controlador admite dispositivos punteros absolutos y relativos. MOUCLASS.sys no es el controlador de Windows para pantallas táctiles.
- HIDCLASS.sys: el controlador de clase HID. El controlador HID Class es el pegamento entre KBDHID.sys y MOUHID.sys clientes HID y varios transportes, como USB, Bluetooth, etc.
El sistema compila la pila de controladores de la siguiente manera:
- La pila de transporte crea un objeto de dispositivo físico (PDO) para cada dispositivo HID conectado y carga el controlador de transporte HID adecuado, que a su vez carga el controlador de clase HID.
- El controlador de clase HID crea un PDO para cada teclado o TLC del mouse. Los dispositivos HID complejos (más de un TLC) se exponen como varios PPO creados por el controlador de clase HID. Por ejemplo, un teclado con un mouse integrado podría tener una colección para los controles de teclado estándar y otra colección para el mouse.
- Los controladores del asignador de cliente HID de teclado o mouse se cargan en el FDO adecuado.
- Los controladores del asignador HID crean FDOs para teclado y mouse, y cargan los controladores de clase.
Notas importantes
- Los controladores de proveedor no son necesarios para teclados y ratones compatibles con los usos de HID admitidos y las colecciones de nivel superior.
- Opcionalmente, los proveedores proporcionan controladores de filtro en la pila HID para modificar o mejorar la funcionalidad de estos TLC específicos.
- Los proveedores deben crear TLC independientes específicos del proveedor para intercambiar datos propietarios entre su cliente HID y el dispositivo. Evite usar controladores de filtro a menos que sea crítico.
- El sistema abre todas las colecciones de teclado y mouse para su uso exclusivo.
- El sistema impide deshabilitar o habilitar un teclado.
- El sistema proporciona compatibilidad con ruedas horizontales o verticales con funcionalidades de desplazamiento suave.
Guía del controlador
Microsoft proporciona esta guía para los controladores de escritura de IHD:
Los desarrolladores de controladores pueden agregar más controladores en forma de controlador de filtro o un nuevo controlador cliente HID.
Controladores de filtros: los desarrolladores de controladores deben asegurarse de que su controlador value-add es un controlador de filtro y no reemplaza (o se usa en lugar de) los controladores HID de Windows existentes en la pila de entrada.
- Los controladores de filtro se permiten en estos escenarios:
- Como filtro superior a kbdhid/mouhid
- Como filtro superior a kbdclass/mouclass
- Los controladores de filtro no se recomiendan como un filtro entre HIDCLASS y minidrivers de transporte HID
- Los controladores de filtro se permiten en estos escenarios:
Controladores de función: como alternativa, los proveedores pueden crear un controlador de función (en lugar de un controlador de filtro), pero solo para los PPO de HID específicos del proveedor (con un servicio en modo de usuario si es necesario).
Los controladores de función se permiten en estos escenarios:
- Cargar solo en el hardware del proveedor específico
Controladores de transporte: el equipo de Windows no recomienda crear más minidrives de transporte HID que son complejos de escribir y mantener. Si un asociado está creando un nuevo minidriver de transporte HID, especialmente en sistemas SoC, se recomienda una revisión de arquitectura detallada para comprender el razonamiento y asegurarse de que el controlador se desarrolla correctamente.
Los desarrolladores de controladores deben usar marcos de controladores (KMDF o UMDF) y no confiar en WDM para sus controladores de filtro.
Los desarrolladores de controladores deben reducir el número de transiciones de usuario del kernel entre su servicio y la pila de controladores.
Los desarrolladores de controladores deben garantizar la capacidad de reactivar el sistema a través de la funcionalidad del teclado y del panel táctil (ajustable por el usuario final (administrador de dispositivos) o el fabricante del equipo). Además de los sistemas SoC, estos dispositivos deben ser capaces de reactivarse a sí mismos desde un estado de energía inferior mientras el sistema está en estado de funcionamiento S0.
Los desarrolladores de controladores deben asegurarse de que su hardware se administra de forma eficaz.
- El dispositivo puede entrar en su estado de energía más bajo cuando el dispositivo está inactivo.
- El dispositivo está en el estado de energía más bajo cuando el sistema está en estado de baja potencia (por ejemplo, en espera (S3) o en espera conectado).
Diseño del teclado
Un diseño de teclado describe completamente las características de entrada de un teclado para Microsoft Windows 2000 y versiones posteriores. Por ejemplo, un diseño de teclado especifica el idioma, el tipo de teclado y la versión, los modificadores, los códigos de examen, etc.
Consulte estos recursos para obtener información sobre los diseños de teclado:
Archivo de encabezado de teclado, kdb.h, en el Kit de desarrollo de controladores de Windows (DDK), que documenta información general sobre los diseños de teclado.
Diseños de teclado de ejemplo.
Para visualizar el diseño de un teclado específico, consulta Diseños de teclado de Windows.
Para obtener más información sobre el diseño del teclado, visite Panel de control\Clock, Language y Region\Language.
Botones y ruedas compatibles en ratones
En la tabla siguiente se identifican las características admitidas en distintas versiones de cliente del sistema operativo Windows.
Característica | Windows XP | Windows Vista | Windows 7 | Windows 8 y versiones posteriores |
---|---|---|---|---|
Botones 1-5 | Compatible (P/2 e HID) | Compatible (PS/2 & HID) | Compatible (PS/2 & HID) | Compatible (PS/2 & HID) |
Rueda de desplazamiento vertical | Compatible (PS/2 & HID) | Compatible (PS/2 & HID) | Compatible (PS/2 & HID) | Compatible (PS/2 & HID) |
Rueda de desplazamiento horizontal | No compatible | Supported(HID only) | Supported(HID only) | Supported(HID only) |
Compatibilidad con ruedas de desplazamiento suave (horizontal y vertical) | No compatible | Parcialmente compatible | Compatible (solo HID) | Compatible (solo HID) |
Activación de botones 4-5 y rueda en ratones PS/2
El método utilizado por Windows para activar el nuevo modo de cuatro y cinco botones y ruedas es una extensión del método utilizado para activar el tercer botón y la rueda en ratones compatibles con IntelliMouse:
El mouse se establece en el modo de rueda de tres botones estableciendo la tasa de informes en 200 informes por segundo y, a continuación, en 100 informes por segundo, en 80 informes por segundo. A continuación, lea el identificador del mouse. El mouse debe notificar un identificador de 3 cuando se completa esta secuencia.
Después, el mouse se establece en el modo de rueda de cinco botones estableciendo la tasa de informe en 200 informes por segundo y, a continuación, en 200 informes por segundo, a 80 informes por segundo. A continuación, lea el identificador del mouse. Una vez completada la secuencia, un mouse de rueda de cinco botones debe notificar un identificador de 4 (mientras que un mouse de rueda compatible con IntelliMouse seguiría informando de un identificador de 3).
Este método es aplicable solo a ratones PS/2, no ratones HID. Los ratones HID deben notificar usos precisos en su descriptor de informe.
Formato de paquete de datos de mouse compatible con PS/2 estándar (dos botones)
Byte | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | Comentario |
---|---|---|---|---|---|---|---|---|---|
1 | Yover | Xover | Ysign | Xsign | Etiqueta | M | R | L | Desbordamientos y signos X/Y, botones |
2 | X7 | X6 | X5 | X4 | X3 | X2 | X1 | X0 | X byte de datos |
3 | A7 | A6 | A5 | Y4 | A3 | Y2 | S1 | A0 | Bytes de datos Y |
Nota:
Los controladores del mouse de Windows no comprueban los bits de desbordamiento. En caso de desbordamiento, el mouse simplemente debe enviar el valor máximo de desplazamiento firmado.
Formato de paquete de datos de mouse compatible con PS/2 estándar (tres botones + rueda vertical)
Byte | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | Comentario |
---|---|---|---|---|---|---|---|---|---|
1 | 0 | 0 | Ysign | Xsign | 1 | M | R | L | Signos X/Y y y botones R/L/M |
2 | X7 | X6 | X5 | X4 | X3 | X2 | X1 | X0 | X byte de datos |
3 | A7 | A6 | A5 | Y4 | A3 | Y2 | S1 | A0 | Bytes de datos Y |
4 | Z7 | Z6 | Z5 | Z4 | Z3 | Z2 | Z1 | Z0 | Byte de datos Z/wheel |
Formato de paquete de datos de mouse compatible con PS/2 estándar (cinco botones + rueda vertical)
Byte | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 | Comentario |
---|---|---|---|---|---|---|---|---|---|
1 | 0 | 0 | Ysign | Xsign | 1 | M | R | L | Signos X/Y y y botones R/L/M |
2 | X7 | X6 | X5 | X4 | X3 | X2 | X1 | X0 | X byte de datos |
3 | A7 | A6 | A5 | Y4 | A3 | Y2 | S1 | A0 | Bytes de datos Y |
4 | 0 | 0 | B5 | B4 | Z3 | Z2 | Z1 | Z0 | Datos y botones Z/wheel 4 y 5 |
Importante
Observe que los datos Z/wheel de un mouse de rueda de cinco botones se han reducido a cuatro bits en lugar de los 8 bits usados en el modo de rueda de tres botones compatible con IntelliMouse. Esta reducción es posible por el hecho de que la rueda normalmente no puede generar valores más allá del intervalo +7/-8 durante cualquier período de interrupción determinado. Los controladores del mouse de Windows firmarán los cuatro bits de datos Z/wheel cuando el mouse esté en el modo de rueda de cinco botones y el byte de datos Z/wheel completo cuando el mouse funcione en el modo de rueda de tres botones.
Los botones 4 y 5 en se asignan a WM_APPCOMMAND mensajes y corresponden a App_Back y App_Forward.
Dispositivos que no requieren controladores de proveedor
Los controladores de proveedor no son necesarios para los siguientes dispositivos:
- Dispositivos que cumplen con el estándar HID.
- Dispositivos de teclado, mouse o puerto de juego operados por los controladores no HIDClass proporcionados por el sistema.
Ejemplo de Kbfiltr
Kbfiltr se usa con Kbdclass, el controlador de clase del sistema para dispositivos de teclado e I8042prt, el controlador de función para un teclado de estilo PS/2. Kbfiltr muestra cómo filtrar las solicitudes de E/S y cómo agregar rutinas de devolución de llamada que modifican la operación de Kbdclass e I8042prt.
Para obtener más información sobre la operación Kbfiltr, consulte:
El archivo de encabezado ntddkbd.h WDK.
Código fuente kbfiltr de ejemplo.
Códigos de control de E/S kbfiltr
Kbfiltr usa las siguientes IOCTLs.
IOCTL_INTERNAL_I8042_HOOK_KEYBOARD
Solicitud de IOCTL_INTERNAL_I8042_HOOK_KEYBOARD:
- Agrega una rutina de devolución de llamada de inicialización a la rutina de inicialización del teclado I8042prt.
- Agrega una rutina de devolución de llamada ISR al ISR del teclado I8042prt.
Las devoluciones de llamada isr e inicialización son opcionales y las proporciona un controlador de filtro de nivel superior para un dispositivo de teclado de estilo PS/2.
Después de que I8042prt reciba una solicitud IOCTL_INTERNAL_KEYBOARD_CONNECT, envía una solicitud de IOCTL_INTERNAL_I8042_HOOK_KEYBOARD sincrónica a la parte superior de la pila de dispositivos de teclado.
Después de que Kbfiltr reciba la solicitud de teclado de enlace, Kbfiltr filtra la solicitud de la siguiente manera:
- Guarda la información de nivel superior que se pasa a Kbfiltr, que incluye el contexto de un objeto de dispositivo de nivel superior, un puntero a una devolución de llamada de inicialización y un puntero a una devolución de llamada ISR.
- Reemplaza la información de nivel superior por la suya propia.
- Guarda el contexto de I8042prt y punteros a devoluciones de llamada que puede usar la devolución de llamada kbfiltr ISR.
IOCTL_INTERNAL_KEYBOARD_CONNECT
La solicitud IOCTL_INTERNAL_KEYBOARD_CONNECT conecta el servicio Kbdclass al dispositivo de teclado. Kbdclass envía esta solicitud a la pila del dispositivo de teclado antes de abrir el dispositivo de teclado.
Después de que Kbfiltr recibió la solicitud de conexión del teclado, Kbfiltr filtra la solicitud de conexión de la siguiente manera:
- Guarda una copia de la estructura de kbdclass CONNECT_DATA (Kbdclass) que se pasa al controlador de filtro por Kbdclass.
- Sustituye su propia información de conexión para la información de conexión del controlador de clase.
- Envía la IOCTL_INTERNAL_KEYBOARD_CONNECT solicitud a la pila del dispositivo.
Si la solicitud no se realiza correctamente, Kbfiltr completa la solicitud con un estado de error adecuado.
Kbfiltr proporciona una plantilla para una rutina de devolución de llamada de servicio de filtro que puede complementar el funcionamiento de KeyboardClassServiceCallback, la rutina de devolución de llamada del servicio kbdclass. La devolución de llamada del servicio de filtro puede filtrar los datos de entrada transferidos desde el búfer de entrada del dispositivo a la cola de datos de clase.
IOCTL_INTERNAL_KEYBOARD_DISCONNECT
La solicitud IOCTL_INTERNAL_KEYBOARD_DISCONNECT se completa con un estado de STATUS_NOT_IMPLEMENTED. El administrador Plug and Play puede agregar o quitar un teclado Plug and Play.
Para todas las demás solicitudes de control de dispositivos, Kbfiltr omite la pila de IRP actual y envía la solicitud a la pila del dispositivo sin procesamiento adicional.
Rutinas de devolución de llamada implementadas por Kbfiltr
Kbfiltr implementa las siguientes rutinas de devolución de llamada.
KbFilter_InitializationRoutine
Consulte PI8042_KEYBOARD_INITIALIZATION_ROUTINE
El KbFilter_InitializationRoutine no es necesario si la inicialización predeterminada de I8042prt de un teclado es suficiente.
I8042prt llama a KbFilter_InitializationRoutine cuando inicializa el teclado. La inicialización de teclado predeterminada incluye las siguientes operaciones:
- restablecer el teclado
- establecer la tasa de tipos y el retraso
- establecer los diodos emisores de luz (LED)
/*
Parameters
DeviceObject [in]
Pointer to the device object that is the context for this callback.
SynchFuncContext [in]
Pointer to the context for the routines pointed to by ReadPort and Writeport.
ReadPort [in]
Pointer to the system-supplied PI8042_SYNCH_READ_PORT callback that reads from the port.
WritePort [in]
Pointer to the system-supplied PI8042_SYNCH_WRITE_PORT callback that writes to the port.
TurnTranslationOn [out]
Specifies, if TRUE, to turn translation on. Otherwise, translation is turned off.
Return value
KbFilter_InitializationRoutine returns an appropriate NTSTATUS code.
*/
NTSTATUS KbFilter_InitializationRoutine(
In PDEVICE_OBJECT DeviceObject,
In PVOID SynchFuncContext,
In PI8042_SYNCH_READ_PORT ReadPort,
In PI8042_SYNCH_WRITE_PORT WritePort,
Out PBOOLEAN TurnTranslationOn
);
KbFilter_IsrHook
Consulte PI8042_KEYBOARD_ISR. Esta devolución de llamada no es necesaria si la operación predeterminada de I8042prt es suficiente.
El ISR del teclado I8042prt llama a KbFilter_IsrHook después de validar la interrupción y lee el código de examen.
KbFilter_IsrHook se ejecuta en modo kernel en el IRQL del teclado I8042prt.
/*
Parameters
DeviceObject [in]
Pointer to the filter device object of the driver that supplies this callback.
CurrentInput [in]
Pointer to the input KEYBOARD_INPUT_DATA structure that is being constructed by the ISR.
CurrentOutput [in]
Pointer to an OUTPUT_PACKET structure that specifies the bytes that are being written to the hardware device.
StatusByte [in, out]
Specifies the status byte that is read from I/O port 60 when an interrupt occurs.
DataByte [in]
Specifies the data byte that is read from I/O port 64 when an interrupt occurs.
ContinueProcessing [out]
Specifies, if TRUE, to continue processing in the I8042prt keyboard ISR after this callback returns; otherwise, processing is not continued.
ScanState [in]
Pointer to a KEYBOARD_SCAN_STATE structure that specifies the keyboard scan state.
Return value
KbFilter_IsrHook returns TRUE if the interrupt service routine should continue; otherwise it returns FALSE.
*/
KbFilter_IsrHook KbFilter_IsrHook(
In PDEVICE_OBJECT DeviceObject,
In PKEYBOARD_INPUT_DATA CurrentInput,
In POUTPUT_PACKET CurrentOutput,
Inout UCHAR StatusByte,
In PUCHAR DataByte,
Out PBOOLEAN ContinueProcessing,
In PKEYBOARD_SCAN_STATE ScanState
);
KbFilter_ServiceCallback
Consulte PSERVICE_CALLBACK_ROUTINE.
La rutina de finalización de distribución de ISR del controlador de función llama a KbFilter_ServiceCallback, que luego llama a la implementación del controlador de clase de teclado de PSERVICE_CALLBACK_ROUTINE. Un proveedor puede implementar una devolución de llamada del servicio de filtro para modificar los datos de entrada transferidos desde el búfer de entrada del dispositivo a la cola de datos de clase. Por ejemplo, la devolución de llamada puede eliminar, transformar o insertar datos.
/*
Parameters
DeviceObject [in]
Pointer to the class device object.
InputDataStart [in]
Pointer to the first keyboard input data packet in the input data buffer of the port device.
InputDataEnd [in]
Pointer to the keyboard input data packet that immediately follows the last data packet in the input data buffer of the port device.
InputDataConsumed [in, out]
Pointer to the number of keyboard input data packets that are transferred by the routine.
Return value
None
*/
VOID KbFilter_ServiceCallback(
In PDEVICE_OBJECT DeviceObject,
In PKEYBOARD_INPUT_DATA InputDataStart,
In PKEYBOARD_INPUT_DATA InputDataEnd,
Inout PULONG InputDataConsumed
);
Ejemplo moufiltr
Moufiltr se usa con Mouclass, el controlador de clase del sistema para dispositivos de mouse usados con Windows 2000 y versiones posteriores, e I8042prt, el controlador de funciones para un mouse de estilo PS/2 usado con Windows 2000 y versiones posteriores. Moufiltr muestra cómo filtrar las solicitudes de E/S y agregar rutinas de devolución de llamada que modifican el funcionamiento de Mouclass e I8042prt.
Para obtener más información sobre la operación Moufiltr, consulte estos recursos:
El archivo de encabezado ntddmou.h WDK.
Código fuente moufiltr de ejemplo.
Códigos de control de E/S moufiltr
Moufiltr usa las siguientes ICTL.
IOCTL_INTERNAL_I8042_HOOK_MOUSE
La solicitud IOCTL_INTERNAL_I8042_HOOK_MOUSE agrega una rutina de devolución de llamada ISR al ISR del mouse I8042prt. La devolución de llamada ISR es opcional y la proporciona un controlador de filtro de mouse de nivel superior.
I8042prt envía esta solicitud después de recibir una solicitud IOCTL_INTERNAL_MOUSE_CONNECT . I8042prt envía una solicitud de IOCTL_INTERNAL_I8042_HOOK_MOUSE sincrónica a la parte superior de la pila del dispositivo del mouse.
Después de que Moufiltr reciba la solicitud del mouse de enlace, filtra la solicitud de la siguiente manera:
- Guarda la información de nivel superior que se pasa a Moufiltr, que incluye el contexto de un objeto de dispositivo de nivel superior y un puntero a una devolución de llamada ISR.
- Reemplaza la información de nivel superior por la suya propia.
- Guarda el contexto de I8042prt y punteros para las devoluciones de llamada que pueden usar las devoluciones de llamada de Moufiltr ISR.
IOCTL_INTERNAL_MOUSE_CONNECT
La solicitud IOCTL_INTERNAL_MOUSE_CONNECT conecta el servicio Mouclass a un dispositivo del mouse.
IOCTL_INTERNAL_MOUSE_DISCONNECT
Moufiltr completa la solicitud de IOCTL_INTERNAL_MOUSE_DISCONNECT con un estado de error de STATUS_NOT_IMPLEMENTED.
En el caso de todas las demás solicitudes, Moufiltr omite la pila irP actual y envía la solicitud a la pila del dispositivo sin procesamiento adicional.
Rutinas de devolución de llamada moufiltr
MouFiltr implementa las siguientes rutinas de devolución de llamada.
MouFilter_IsrHook
Consulte PI8042_MOUSE_ISR.
/*
Parameters
DeviceObject
Pointer to the filter device object of the driver that supplies this callback.
CurrentInput
Pointer to the input MOUSE_INPUT_DATA structure being constructed by the ISR.
CurrentOutput
Pointer to the OUTPUT_PACKET structure that specifies the bytes being written to the hardware device.
StatusByte
Specifies a status byte that is read from I/O port 60 when the interrupt occurs.
DataByte
Specifies a data byte that is read from I/O port 64 when the interrupt occurs.
ContinueProcessing
Specifies, if TRUE, that the I8042prt mouse ISR continues processing after this callback returns. Otherwise, processing is not continued.
MouseState
Pointer to a MOUSE_STATE enumeration value, which identifies the state of mouse input.
ResetSubState
Pointer to MOUSE_RESET_SUBSTATE enumeration value, which identifies the mouse reset substate. See the Remarks section.
Return value
MouFilter_IsrHook returns TRUE if the interrupt service routine should continue; otherwise it returns FALSE.
*/
BOOLEAN MouFilter_IsrHook(
PDEVICE_OBJECT DeviceObject,
PMOUSE_INPUT_DATA CurrentInput,
POUTPUT_PACKET CurrentOutput,
UCHAR StatusByte,
PUCHAR DataByte,
PBOOLEAN ContinueProcessing,
PMOUSE_STATE MouseState,
PMOUSE_RESET_SUBSTATE ResetSubState
);
No se necesita una devolución de llamada MouFilter_IsrHook si la operación predeterminada de I8042prt es suficiente.
El ISR del mouse I8042prt llama MouFilter_IsrHook después de validar la interrupción.
Para restablecer un mouse, I8042prt pasa por una secuencia de subestados operativos. Un valor de enumeración MOUSE_RESET_SUBSTATE identifica cada subestado. Para obtener más información sobre cómo I8042prt restablece un mouse y los subestados de restablecimiento del mouse correspondientes, consulte la documentación de MOUSE_RESET_SUBSTATE en ntdd8042.h.
MouFilter_IsrHook se ejecuta en modo kernel en el IRQL del ISR del mouse I8042prt.
MouFilter_ServiceCallback
Consulte PSERVICE_CALLBACK_ROUTINE
/*
Parameters
DeviceObject [in]
Pointer to the class device object.
InputDataStart [in]
Pointer to the first mouse input data packet in the input data buffer of the port device.
InputDataEnd [in]
Pointer to the mouse input data packet immediately following the last data packet in the port device's input data buffer.
InputDataConsumed [in, out]
Pointer to the number of mouse input data packets that are transferred by the routine.
Return value
None
*/
VOID MouFilter_ServiceCallback(
_In_ PDEVICE_OBJECT DeviceObject,
_In_ PMOUSE_INPUT_DATA InputDataStart,
_In_ PMOUSE_INPUT_DATA InputDataEnd,
_Inout_ PULONG InputDataConsumed
);
El ISR DPC de I8042prt llama a MouFilter_ServiceCallback, que luego llama a MouseClassServiceCallback. Se puede configurar una devolución de llamada del servicio de filtro para modificar los datos de entrada que se transfieren desde el búfer de entrada del dispositivo a la cola de datos de clase. Por ejemplo, la devolución de llamada puede eliminar, transformar o insertar datos.