Created attachment 100886 [details]
Output of lsbusb -v

Should mention this device works on the same hardware in Win98.

Here's a report on linux-usb-users for the same issue (by someone else using a
different distro):
http://www.mail-archive.com/linux-usb-users@lists.sourceforge.net/msg10248.html

Created attachment 101056 [details]
dmesg output w/ CONFIG_USB_DEBUG defined

FWIW, attached dmesg output from kernel-2.6.5-1.358 compiled with
CONFIG_USB_DEBUG defined.  Device attachment occurs immediately after last
(unrelated) i2c_adapter message.

Same in kernel-2.6.7-1.494.2.2.

So, what about the FC3 with 2.6.10-1.741_FC3? It has the new
enumeration exactly for cases like this one.

Thx for checking back Pete.

No joy with .741_FC3 or .760_FC3.  Error messages are a bit different.
Here's dmesg during connect/lsusb:

usb 1-1: new low speed USB device using ohci_hcd and address 2
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
input: USB HID v1.00 Joystick [0925:8866] on usb-0000:00:02.0-1
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: string descriptor 0 read error: -32
usb 1-1: usbfs: process 5830 (lsusb) did not claim interface 0 before use

lsusb -v output essentially identical to previous attachment.

Same single burst of nonsense values from jstest followed by silence.
 Noticed one oddity, first jstest after plugin generates a few more
"events" than subsequent runs.  [cat /dev/input/js0 > somefile gives
352 bytes the first time after plugin, and 336 bytes every time after
that.  FWIW.]

Diabolical scheme to get girlfriend hooked on Linux foiled again by
cheesy dancepad adapter.

The -32 is a stall condition, so device is consciously refusing to return
the descriptor. I suppose you could make a one-off kernel which simply
does not read it. It's probably not all that needed... Just a device name
or vendor name.

Not sure what to do about it in the common case though.

I've been trying to debug this one on my Gentoo system.  I've found that if  
you run usbmodules with the --device paramter will have the side effect of  
allowing the adapter to work.  
  
For example:  
Plug in adapter [joydev is loaded, /dev/input/js0 is created]  
cat /dev/input/js0 [a few bytes, then silence; never any response from pushing  
buttons]  
usbmodules --device /proc/bus/usb/###/### [no output]  
cat /dev/input/js0 [now it responds to button presses]  

I had the same problem with a USB dance pad adepter under FC4 running
2.6.14-1.1644_FC4.  It is recognized when plugged in, but a cat of js0 shows no
activity after the plug-in.  But if I run:

usbmodules --device /proc/bus/usb/xxx/yyy

it works very nicely.

No joy so far using the above method with kernels 2.6.15-1.1831_FC4,
2.6.14-1.1656_FC4, and 2.6.13-1.1526_FC4.  I don't have 1644 on hand.

Since FC4's usbutils package does not build usbmodules by default, I configured
the usbutils-0.70-1.1 SRPM with --enable-usbmodules and compiled usbmodules.

Usbmodules is silent except in the case of the 1656_FC4 kernel, where it shows
that the yealink phone driver module is registered.  Cat or jstest on
/dev/input/js0 show no output beyond the initial burst of garbage as usual.

My particular adapter has a Cypress Semiconductor CY7 C63001 chip.

Update: 
 
The usbmodules hack only worked with old versions (0.11) not with the newer 
(0.70+) 
 
Fortunately the bug has been identified.  Due to a quirk in the hardware, it 
would lock itself during part of the initialization sequence.  The usbmodules 
hack was just giving it a nudge and it would put itself back into a valid 
state. 
 
The patch is here: 
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=114038593204406&w=2 
 
(it's only two lines; it just marks this device as having this particular 
quirk) 

I applied the wisegroup.patch to kernel-2.6.15-1.1831_FC4.src.rpm and it works
for me.  Events now work properly, also both joysticks on the dual adapter show
up in /dev/input instead of just one.

Hey Andrew nice job of chasing this thing down, getting the USB gods to throw
enough crumbs to help you figure this one out yourself, and reporting the fix
back to the rest of us!

I guess proper bz ettiquette would be to close as UPSTREAM, where the patch belongs.