>> Nov  7 12:30:13 Truly-Delicious /netbsd: usbd_new_device: addr=2, getting full desc failed
>> Nov  7 12:30:13 Truly-Delicious /netbsd: uhub_explore: usb_new_device failed, error=IOERROR
>> Nov  7 12:30:13 Truly-Delicious /netbsd: uhub0: device problem, disabling port 2

>> I dug into the code and concluded that this meant it didn't follow
>> the spec, [...]
> How deep did you dig in the code?

I dunno; what kind of qualitative response is there to that? :-)  I
read over enough code to conclude it was failing to get something which
the code clearly thought every USB device should provide - the device
descriptor of which you speak, probably.

> The error message looks like the kernel couldn't read the device
> descriptor.  This is a really fundemental part of the USB, so it is
> not just that the device has a non-standard interface...

That was my impression too, that it indicated either a broken device
(entirely possible - I have no idea what it's been through) or a
_severely_ nonstandard interface.

> So it might be that device is just buggy and need a quirk, or (IMHO
> more likely) that there is some bug in our USB code.

I considered the possibility.  But the same kernel picks up a USB
printer just fine, so it's not just a blatant "USB doesn't work"; and
while it may be something with this particular device, it didn't -
doesn't - seem worth trying to backport -current's USB subsystem, and
there also didn't seem much point in trying to report possible bugs in
something nobody cares about any longer.

Of course, if the device is hardwarily broken, it won't work any better
with the vendor Windows drivers either, regardless of how good the
emulation may be. :-/

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B