I couldn't find a picture of the UVCView window, but a very similar
program
USBView here, has the same displayed information.
http://www.die.de/blog/content/binary/usbview.png
Basically, how it works, is USB ports can support two standards. USB 1.1
and
USB 2.0. There are two kinds of logic blocks inside the Southbridge, and
they
are connected via a multiplexer, to the physical USB port.
A USB 1.1 logic block, typically controls two USB ports. You may have
noticed
a habit of putting USB ports in "stacks of two", and the stack of two may
be
tied to the same USB 1.1 controller.
The USB 2.0 controller, tends to be shared over more ports.
In that USBView window, you're seeing the ports listed twice. During
negotiation,
a plugged in device may end up operating at 2.0 speeds, or at 1.1 speeds.
It
will either be "bound" to its USB 1.1 controller, or to the more widely
shared
USB 2.0 controller. But it shouldn't show up on both at the same time. So
12 places may show in USBView/UVCView, but only 6 could be used at any one
time.
For a mouse, what I would expect to see, is the mouse show up on the "pair
of two" blocks, and not on the USB2 6, 8, or 10 shared block.
Note that, on some of the latest Intel chipsets, they have finally
introduced
a second USB2 controller block, breaking the pattern seen on the screen.
This
was done, to offer more USB2 bandwidth to the ports. But it doesn't change
the
multiplexing thing, or the "either/or" nature of which block a plugged
device
is bound to.
In the USBView picture above, the "Root Hub" at the top of the display,
has
not been clicked to expose the two entries it contains. Otherwise, you'd
be
looking at "three pairs of two" and the "six port" near the bottom. That
is
typical of a range of Intel Southbridges for example. (The 82801 number is
what is pointing me at Intel, as that is an Intel number.)
I think this value, is supposed to be used for the control endpoint.
bMaxPacketSize0 Number Maximum packet size for endpoint zero
(only 8, 16, 32, or 64 are valid)
wMaxPacketSize is two bytes, and appears to support arbitrary lengths
(for data transfers).
Maybe the mouse is declaring itself to be a USB2 device, but that seems a
bit strange. Or maybe the computer and mouse are not communicating
error free.
http://www.beyondlogic.org/usbnutshell/usb5.htm
"The bcdUSB field reports the highest version of USB the device
supports"
"USB 2.0 is reported as 0x0200, USB 1.1 as 0x0110 and USB 1.0 as
0x0100."
If a device cannot be fully enumerated (less well than the example in the
picture above), then it is pretty hard for Windows to either apply a
default
driver or associate the device with a separately provided driver.
There are classes of devices, and some of them have built-in
drivers in Windows. For a pointing device, I would have
expected to at least be able to move the cursor, even without
installing a driver. I thought (but could be wrong), that third party
drivers for pointing devices, allowed handling extended numbers
of buttons, or binding them to commands and the like. At
least, my cheesy little test mouse I use here, for testing
UVCView, doesn't need any driver to behave like a mouse,
and is immediately recognized and works.
"HID Compliant Mouse" - my cheesy two button mouse, a freeby at a tech
show
*******
---===>Device Information<===---
English product name: "HID-compliant Mouse (USB)"
ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Low
Device Address: 0x02
Open Pipes: 1
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0003 = Invalid bus speed for USB Video
Class
bInterval: 0x10
===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0100
bDeviceClass: 0x00 -> This is an Interface Class
Defined Device
bDeviceSubClass: 0x00
bDeviceProtocol: 0x00
bMaxPacketSize0: 0x08 = (8) Bytes
idVendor: 0x03EE = Mitsumi
idProduct: 0x6407
bcdDevice: 0x0110
iManufacturer: 0x01
English (United States) "Mitsumi"
iProduct: 0x02
English (United States) "HID-compliant Mouse (USB)"
iSerialNumber: 0x00
bNumConfigurations: 0x01
===>Configuration Descriptor<===
bLength: 0x09
bDescriptorType: 0x02
wTotalLength: 0x0022 -> Validated
bNumInterfaces: 0x01
bConfigurationValue: 0x01
iConfiguration: 0x00
bmAttributes: 0xA0 -> Bus Powered
MaxPower: 0x32 = 100 mA
===>Interface Descriptor<===
bLength: 0x09
bDescriptorType: 0x04
bInterfaceNumber: 0x00
bAlternateSetting: 0x00
bNumEndpoints: 0x01
bInterfaceClass: 0x03 -> HID Interface Class
bInterfaceSubClass: 0x01
bInterfaceProtocol: 0x02
CAUTION: This may be an invalid bInterfaceProtocol
iInterface: 0x00
===>HID Descriptor<===
bLength: 0x09
bDescriptorType: 0x21
bcdHID: 0x0100
bCountryCode: 0x00
bNumDescriptors: 0x01
bDescriptorType: 0x22
wDescriptorLength: 0x0032
===>Endpoint Descriptor<===
bLength: 0x07
bDescriptorType: 0x05
bEndpointAddress: 0x81 -> Direction: IN - EndpointID: 1
bmAttributes: 0x03 -> Interrupt Transfer Type
wMaxPacketSize: 0x0003 = Invalid bus speed for USB Video
Class
bInterval: 0x10
*******
You can get the 650 page USB2 standard here (top of the page, link to
ZIP).
The "usb_20.pdf" document inside, almost 6MB, is the spec. It will
help a bit interpreting the fields.
http://www.usb.org/developers/docs/
In my mouse example above, the 0x03EE and 0x6407 information, would be
how a third-party driver would get loaded, in response to that USB
device being plugged in. So if you installed some mouse software,
the mouse software would load in response to matching on the idVendor
and idProduct. If those values were corrupted in transmission, then
there is no reason for the third-party driver to be consulted.
The "Caution" messages are probably a feature of UVCView, because the
program was intended for debugging USB Video Class devices (webcams?).
So things that don't look like video devices, or support typical
video device characteristics, may be the reason for some of the Caution
messages. Perhaps a copy of USBView would not have those messages.
Paul