You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We now pull the user-specified HID mode from the configuration file, which happens at a state where the device object is already created. The HID mode device property is read by the PnP manager via filter driver when queried for HWID, which happens before the property is refreshed from the configuration file. This can lead to the XI filter being active while the driver mode is still in e.g. SYS mode, causing issues with the different HID report descriptor the filter didn't expect.
A simple workaround is to restart the device twice where the device boots with the correct property value.
For a real fix, it has to be brainstormed how to achieve; we can not delay probing for the mode in the filter PnP routines and we can not read the configuration file content before the device is operational. We could detect the mismatch of the mode from JSON and in the property and react to it somehow, but "auto-restarting" a device in a user-mode driver is tricky and not really supported officially.
The text was updated successfully, but these errors were encountered:
Experimenting with port cycle didn't yield any success sadly because the driver hosting process lacks the necessary permissions to do so. I've archived the relevant code here for future use.
We now pull the user-specified HID mode from the configuration file, which happens at a state where the device object is already created. The HID mode device property is read by the PnP manager via filter driver when queried for HWID, which happens before the property is refreshed from the configuration file. This can lead to the XI filter being active while the driver mode is still in e.g. SYS mode, causing issues with the different HID report descriptor the filter didn't expect.
A simple workaround is to restart the device twice where the device boots with the correct property value.
For a real fix, it has to be brainstormed how to achieve; we can not delay probing for the mode in the filter PnP routines and we can not read the configuration file content before the device is operational. We could detect the mismatch of the mode from JSON and in the property and react to it somehow, but "auto-restarting" a device in a user-mode driver is tricky and not really supported officially.
The text was updated successfully, but these errors were encountered: