GNOME Bugzilla – Bug 583733
PS2 Namtai Eyetoy doesn't display on Cheese but does with gstreamer (and everything else)
Last modified: 2009-06-19 13:47:31 UTC
Please describe the problem: Cheese gives a "No Camera Found" error, despite there being a camera connected. Works with all other software except VLC, but does work with normally problem software such as Skype. Webcam was wqorking on earlier versions of Ubuntu withe same drivers, and on Jaunty with default drivers which are buggy for other purposes. Drivers used are ov51-jpeg modules. Steps to reproduce: 1. Install Ubuntu Jaunty. 2. Install ov51x-jpeg drivers: http://www.rastageeks.org/ov51x-jpeg/index.php/Ov51xJpegHackedInstall 3. Start Cheese Actual results: Cheese opens, does not detect Camera. Expected results: Cheee works, I see myself. Does this happen every time? Yes, reboots do nothing. Other information: Again, webcam works with everything else (except VLC, for other reasons I think), and works with gstreamer-properties.
What does "hal-find-by-capability --capability video4linux" say?
(In reply to comment #1) > What does "hal-find-by-capability --capability video4linux" say? > No output.
Your driver is doing something wrong (according to our past experience there is some chance that it isn't correctly setting the parent field in the videodev structure). So hal is not able to detect it as a video4linux device. If everything will go as I plan, I'll drop hal detection code for the next major release (2.28) and this issue should go away on its own. Nonetheless your driver is actually "bugged" and you should report it to its developers. Feel free to point them here.
(In reply to comment #3) > Your driver is doing something wrong (according to our past experience there is > some chance that it isn't correctly setting the parent field in the videodev > structure). So hal is not able to detect it as a video4linux device. > > If everything will go as I plan, I'll drop hal detection code for the next > major release (2.28) and this issue should go away on its own. > Nonetheless your driver is actually "bugged" and you should report it to its > developers. Feel free to point them here. > Thanks, but why was it working with the exact same driver in Hardy? That was with 2.22... I presume you changed the code to make it better at detecting devices by using the hal thing, and as such these woefully hacked drivers failed :P?
Uhm no as far as I know HAL stuff was already in 2.22, maybe it's not exactly the same driver :) could be that something has changed there, don't know.
*** Bug 578441 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Uhm no as far as I know HAL stuff was already in 2.22, maybe it's not exactly > the same driver :) could be that something has changed there, don't know. > It's exactly the same driver asfaik=- complied it myself as it were. Perhaps some of the other modules have changed or something. As it is, it's an issue limited to Cheese, but thanks anyway.
We had other similar issues with other drivers that have been fixed by respective developers. Please try to report this one to that driver maintainers. Sure it could be limited to Cheese but we're just exposing a bug in the driver.
Now that I think about it I remember a change in the v4l kernel stack that could have triggered this. Something in the videodev structure. All in tree drivers have been updated pretty soon but maybe yours missed it because it's not included in the mainline kernel. I could look for the particular commit but I'm not sure it's worth.
(In reply to comment #9) > Now that I think about it I remember a change in the v4l kernel stack that > could have triggered this. Something in the videodev structure. All in tree > drivers have been updated pretty soon but maybe yours missed it because it's > not included in the mainline kernel. I could look for the particular commit but > I'm not sure it's worth. > Quite possibly as soon as a new version of driver comes out base on in tree versions, then it'll fix it, but we'll see I guess. Thanks, anyway. Will email link to this bugreport to the mailing list.
The change I remember was renaming the "dev" field to "parent" in the videodev structure. It should be pretty easy to fix with something like: - ov->vdev->dev = dev->dev; + ov->vdev->parent = dev->dev; in ov51x-jpeg-core.c line 8377 (from the 1.5.7 tarball)
And, this is the commit http://linuxtv.org/hg/v4l-dvb/rev/db7029e2fe8c
(In reply to comment #11) > The change I remember was renaming the "dev" field to "parent" in the videodev > structure. > It should be pretty easy to fix with something like: > - ov->vdev->dev = dev->dev; > + ov->vdev->parent = dev->dev; > > in ov51x-jpeg-core.c line 8377 (from the 1.5.7 tarball) > Didn't complie with: /usr/src/webcam/modules/ov51x-jpeg/ov51x-jpeg-core.c:8377: error: incompatible types in assignment
Well I was just guessing I didn't test it. That's the part to change anyway, ask driver developers.
try &dev->dev instead of dev->dev
Works for me: - ov->vdev->dev = dev->dev; + ov->vdev->parent = &dev->dev; in ov51x-jpeg-core.c line 8377 (from the 1.5.9 tarball)
Evidently I was doing something wrong. This worked for me!
Good news for you guys! http://hansdegoede.livejournal.com/7219.html