I have to modify the Hardware IDs reported by HIDCLASS for some device collections and was wondering can I do it by attaching on top of HIDCLASS driver . If am able to register as a upper filter to HIDCLASS , then planning to intercept the completion of IRP_MJ_QUERY_ID and modify it by embedding another string
Please have a look at the architecture I have pasted link below for the HIDCLASS . What’s worrying me w.r.t to adding a filter driver above is , HIDCLASS itself got registered/added as a upper filter and how will I be able to register a filter on top of it .
Details of HID Architecture
HID Class does the job of working with transport driver like USB,I2C, Custom driver for the Bus specific activities and and works as a Bus driver to create PDO for each of Collection of Device it got from the connected Panel/Trackpad etc . If i need to modify the HW IDs , i need to be on top of HIDCLASS and intercept the QUERY RELATION and QUERY IDs . Let me know if its possible . Can i use a toaster filter and add as a upper filter to the HW ID and start to intercept the QUERY RELATION and Query ID ?
Unlike the HIDI2C , HIDUSB the transport driver on our solution is a custom PCI device . In this case the HID CLASS is not creating the required HWIDs. Rest all features are working as expcted . The major one missing is HID\VID_xxxx&PID_yyyy&Col01 . It creates other HWIDs like HID\VID_xxxx&UP:000D_U:0004, HID_DEVICE_UP:000D_U:0004,HID_DEVICE . Those are too general in nature and customer cant differentiate there TLC filter driver based on just the VID . This is where i thought , may be if i can be an upper filter and intercept the QUERY_ID for the PDOs , i can try to workaround the solution . Let me know if this is feasible ? If yes how should i create the filter driver inf ? The toaster sample filter can help ?
That seems like a reasonable use case to me. Basically you have to attach to all the PDO's enumerated by the class driver, as it is the PDO's that are the target of the PNP query requests you need to modify. Search here for 'bus filter driver'. It is even sort of supported, but unfortunately there is no WDF model for it.
is this a custom hid miniport? or is your custom PCI device exposing itself as a usb hid to use hidusb.sys? If you this is a custom hid mini port, why not fix the mini port to report PID correctly? is the mini port returning a valid HID_DEVICE_ATTRIBUTES with the expected VID and PID? Is the HID_DESCRIPTOR correctly formatted to report all of your collections? The missing hardware ID should be correctly reported if everything above is correct.
Ours is a PCI device and a custom miniport and directly working with the HIDCLASS .Not connected to any inbox transport drivers . We are properly exposing the IOCTL_HID_GET_DEVICE_ATTRIBUTES ,IOCTL_HID_GET_DEVICE_DESCRIPTOR,IOCTL_HID_GET_REPORT_DESCRIPTOR properly. All functions like Input reports ,output , features are working as expected and all TLC in Report are exposed also . In our case the HID CLASS reports a HWID based on VID like HID\VID_xxxx&UP:000D_U:0004. This means it got VID from HW ATTRIBUTES or DEVICE descriptor properly . In addition to that it creates many HWIDs where the VID and PID was that of the VID PID of my PCI device
. For example HID\VEN_xxxx&DEV_yyyy&SUBSYS_abcdabcd&REV_30&Col02 where xxxx and yyyy was nothing but the transport driver VENDOR ID and Product ID
If you are looking for a device specific ID, why not match on HID\VEN_xxxx&DEV_yyyy&SUBSYS_abcdabcd&REV_30&Col02 in your INF? it doesn't have to be HID\VID_xxxx&PID_yyyy&Col01
