Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
PS2 Eyetoy camera is not working after commit 44dc4f093c9ec075e6704965665311a94f6371aa #454
This commit causes the Playstation 2 Eyetoy camera to not work. I have no idea if it affects any other USB cameras, but the error I am receiving from motion is attached to the bottom. Any commit before this works fine.
This is a known issue with fiq_split. The device is a USB1.1 camera which requires isochronous split transactions with multiple split-completes. The current implementation does not allow for more than 1 split-complete in a USB frame therefore only max 188 bytes are transferred per 1ms.
Refer to this comment: raspberrypi/firmware#197 (comment)
The same principle applies for a video stream instead of audio recording stream, but the much greater bandwidth of a video stream (even if JPEG-encoded) produces an unreadable output.
A possible workaround is to disable fiq_split with dwc_otg.fiq_split_enable=0 in /boot/cmdline.txt but the transfer will still be unreliable as generic interrupt latency will mess up the transaction.
I'm currently trying 1d78a22d866b69454c062443db9d4b42f00f0215
mainly to see how high speed isoch' transfers are progressing, but as I have an Eye Toy in my bits box, I thought I'd try it.
If you can put up with a random frame glitch now & then, it does actually produce a fair picture (640*480) using guvcviewer (already in Raspbian distribution), so long as it's plugged directly into a USB port on model B. I'm currently using a 7 port hub which works fine at 2.0 speeds, but has only a single TT. ET's frames just break up if I send through that:
[ 277.432873] gspca_main: ISOC data error:  len=0, status=-71
& when plugged into B directly:
video device: /dev/video0
control type: 0x00000006 not supported
I had tried this again recently, but there was still some bottom-half picture tearing every few seconds.
Happily no tearing now, & between 5 & 7 fps, very good! I generally test using "guvcview", invoked from cli so I can see errors, normally hundreds, but now none!
Also 7 fps on fw 94e1.......30d38, but black screen only. With both firmwares, I left the 3 new cmdline FIQ options in, with a mask of 3.
I have a few more older webcams to check, so I'll update the wiki if any now work that previously didn't.
I was hoping to see just how the new FIQ handler copes with my hd 290e tuner, but I still haven't tracked down why in the last 3 or 4 kernels, it's demodulator won't initialise because of a gpio error. I've just checked kernel's bugzilla & strangely there's no reports, yet there were several for the previous initialisation error which other kernel users noticed after I reported it, so I'm beginning to wonder if it's RPi specific.
Anyway, very good results so far with the new handler. Next to test some USB audio devices.
I abbreviated the string to avoid any transposition errors from the other machine I was posting from. It's the contents of
Here's the full string: "94e1b8014dfa69701d0432088acb11ae01130d38"