USBInspector, wrong reports?
Posted: Wed Mar 06, 2013 12:13 am
Hi,
it seems that parts of the USB subsystem report certain devices to be of wrong class.
I should explain first, what I try to do and what I have done... I try to develop a mouse driver.
Yes, I know, hid.fdclass will recognize and use it, but it does it in a weird way (maybe another problem I should report? Ok, so be it: plug in a Cherry Xero mouse and resize ReAction or MUI windows containing many gadgets, big ListViews and perhaps MUI html class. You will notice heavy lagging when dragging the window borders. I have a Wintech mouse here (similar to the Xero one, 5 buttons but NO tilt wheel, same problems with bootmouse.fdclass *sigh*), working much better).
bootmouse.fdclass doesnt drive it very well, although it should (Class: hid.class, Subclass: 1 (bootmouse). Only one axis recognized (but the wrong one, Y axis driven for X axis movement). So I try to make up a specialized driver for it (based on rmouse driver, courtesy of Rene W. Olsen). This way I might even support the tilt scrollwheel one day...
I disabled hid.fdclass to check if the mouse is working with rmouse out of the box, so I found out the problem with bootmouse.fdclass, not working correctly for this mouse. And I saw that the Xero mouse is reported twice, as it should be for this multifunction device, but one entry makes me wonder.
It seems that the Xero mouse is identified as bootkeyboard, too! This is the weird thing I wonder about. The second entry should state <custom> or similar, as its a custom function of the mouse (you will need an extra driver to get the tilt wheel function for Windows, too...)
Looking into the "Structure" tab, the Xero mouse is reported with the correct class (multifunction).
It seems that there is a slight glitch in interpreting the mouses reports.
it seems that parts of the USB subsystem report certain devices to be of wrong class.
I should explain first, what I try to do and what I have done... I try to develop a mouse driver.
Yes, I know, hid.fdclass will recognize and use it, but it does it in a weird way (maybe another problem I should report? Ok, so be it: plug in a Cherry Xero mouse and resize ReAction or MUI windows containing many gadgets, big ListViews and perhaps MUI html class. You will notice heavy lagging when dragging the window borders. I have a Wintech mouse here (similar to the Xero one, 5 buttons but NO tilt wheel, same problems with bootmouse.fdclass *sigh*), working much better).
bootmouse.fdclass doesnt drive it very well, although it should (Class: hid.class, Subclass: 1 (bootmouse). Only one axis recognized (but the wrong one, Y axis driven for X axis movement). So I try to make up a specialized driver for it (based on rmouse driver, courtesy of Rene W. Olsen). This way I might even support the tilt scrollwheel one day...
I disabled hid.fdclass to check if the mouse is working with rmouse out of the box, so I found out the problem with bootmouse.fdclass, not working correctly for this mouse. And I saw that the Xero mouse is reported twice, as it should be for this multifunction device, but one entry makes me wonder.
It seems that the Xero mouse is identified as bootkeyboard, too! This is the weird thing I wonder about. The second entry should state <custom> or similar, as its a custom function of the mouse (you will need an extra driver to get the tilt wheel function for Windows, too...)
Looking into the "Structure" tab, the Xero mouse is reported with the correct class (multifunction).
It seems that there is a slight glitch in interpreting the mouses reports.