Continuing from 472503 Hans.... I'm sorry, I seems that the new driver is very buggy. The following is written with good feelings and intentions. I'm not being argumentative. Lets get this problem solved. Please understand that you are not talking to a novice user, but a very experienced system adminsitrator that has been using Redhat/Fedora since Redhat 5.2. Comment #1 From Hans de Goede (hdegoede) 2008-11-26 08:36:35 EDT (-) [reply] ------- (In reply to comment #0) >> kernel-2.6.27.5-41.fc9.x86_64 >> >> libv4l-0.5.4-1.fc9.i386.rpm (koji) >> libv4l-0.5.4-1.fc9.x86_64.rpm (koji) >> >> >> WEBCAM: Logitech quickcam >> >> Modules loaded >> -------------- >> gspca_spca561 gspca_main compat_ioctl32 videodev v4l1_compat >> >> >> kopete and ekiga works when loaded with >> >> LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so kopete -caption "%c" %u >> LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so ekiga If I understood correctly, I shouldn't have had to issue the LD_PRELOAD command in Fedora 10 with applicatons specifically compiled for Fedora 10. If this is correct, then I need to report that I still need to do this with both kopete x64_86 and ekiga x86_64. >> Other minor problems: >> >> 1) When I close access to the web cam the pilot light on the camera >> goes out even though the camera still seems to work >> > That is a feature not a bug, the light indicates if videodata is actually > being streamed. So if you close the app showing the camstream the light > goes off. Sorry, this simply isn't true. The pilot light comes on when the computer boots. And after the pilot light goes out after I close access to the camera, and I try to use the camera again, the pilot light doesn't come back on. Like I indicated this is a minor annoyance. >> 2) Only one application can access the camera at a time. >> > Yes, that is normal video4linux behavior. >> a) If I run kopete first then kopete will have access to the camera. >> If I then run ekiga the display shows green. >> >> b) If I run ekiga first, then ekiga has access to the camera. >> If I then run kopete. kopete crashes alltogether. >> Yes and no (maybe - I didn't notice any problem with the older drivers). If I'm using the camera in one application it is very unlikely that I would use it in another. However, if I'm not using the camera in one application then the camera should be fully accessible by the other. This is how the older driver behaved. Applications did not crash because another applicaton was using the camera. Nor did they show green screens. Apps misbehaving when they get -EBUSY errors is not the drivers problem. >> skype crashes when trying to access the camera when using >> >> LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype > skyoe works for me and a lot of other users with an spca561 based cam, do you > have the latest skype? Anyways I cannot help you with that as skype is closed > source software and as such not supported by Fedora. The camera and skype seems to works OK in Fedora 10 The software maybe unsupported by Fedora, but it never crashed until I tried to access the camera with the new built in kernel drivers. And it still does after I've accessed closed access to the camera, and then I try to access the camera in skype. Thanks for your attention in this matter.
(In reply to comment #0) <snip> > >> Modules loaded > >> -------------- > >> gspca_spca561 gspca_main compat_ioctl32 videodev v4l1_compat > >> > >> > >> kopete and ekiga works when loaded with > >> > >> LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so kopete -caption "%c" %u > >> LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so ekiga > > If I understood correctly, I shouldn't have had to issue the LD_PRELOAD command > in Fedora 10 with applicatons specifically compiled for Fedora 10. If this is > correct, then I need to report that I still need to do this with both kopete > x64_86 and ekiga x86_64. > That is not true, ekiga will work fine without the LD_PRELOAD, kopete indeed is not yet patches to use libv4l, so needs the LD_PRELOAD, please file a bug against kopete for this and put me in the CC. > >> 2) Only one application can access the camera at a time. > >> > > > Yes, that is normal video4linux behavior. > > >> a) If I run kopete first then kopete will have access to the camera. > >> If I then run ekiga the display shows green. > >> > >> b) If I run ekiga first, then ekiga has access to the camera. > >> If I then run kopete. kopete crashes alltogether. > >> > > Yes and no (maybe - I didn't notice any problem with the older drivers). If I'm > using the camera in one application it is very unlikely that I would use it in > another. However, if I'm not using the camera in one application then the > camera should be fully accessible by the other. This is how the older driver > behaved. Applications did not crash because another applicaton was using the > camera. Nor did they show green screens. > > Apps misbehaving when they get -EBUSY errors is not the drivers problem. The old driver only allowed one app to open the device, other apps got the -EBUSY error upon opening the device. the new driver (using the new v4l2 API) allows multiple drivers to open the device, so that for example a video control panel (like audio mixers) can open the device, and it can still be opened by another app to stream data. Try running your favorite webcam using app and v4l2ucp at the same time, and notice how this allows you to control all kinda setting most apps don't allow you to , while watching the stream in another application. The problem is that if you open 2 applications which both want to stream video, only the first one will get the stream, the next one will be able to open the device, but will get an EBUSY error when it tries to actually activate the stream. If this causes apps to crash, file bugs against the apps. > >> skype crashes when trying to access the camera when using > >> > >> LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype > > > skyoe works for me and a lot of other users with an spca561 based cam, do you > > have the latest skype? Anyways I cannot help you with that as skype is closed > > source software and as such not supported by Fedora. > > The camera and skype seems to works OK in Fedora 10 > > The software maybe unsupported by Fedora, but it never crashed until I tried to > access the camera with the new built in kernel drivers. And it still does after > I've accessed closed access to the camera, and then I try to access the camera > in skype. > Let me see if I understand you correctly, if you first use an other webcam using application and then *fully* exit it, and then use skype it crashes? Does dmesg give anything usefull after this has happened? Can you try (as root) doing "rmmod gspca_spca561 && modprobe gspca_spca561" before running skype after an other app?
I've opened up a bug report at kde https://bugs.kde.org/show_bug.cgi?id=177338 and in bugzilla. https://bugzilla.redhat.com/show_bug.cgi?id=473534 I've added you to the CC list in bugzilla at redhat.com, but for some reason I was unable to add you to the cc list at kde. > Let me see if I understand you correctly, if you first use an other webcam > using application and then *fully* exit it, and then use skype it crashes? I guess I need to revise this one a little.... Skype crashes if ekiga is open. If I exit out of ekiga completely, then skype seems to be fine. It seems to be fine currently if I'm not using the camera in kopete while accessing the camera in skype. A little more on this below. > Does dmesg give anything usefull after this has happened? Nope... nothing at all. > Can you try (as root) doing "rmmod gspca_spca561 && modprobe gspca_spca561" > before running skype after an other app? Before rmmod, modprobe, after accessing the camera in kopete and then exiting out of kopete Skype crashed. Running skype after rmmod, modprobe works. And now with kopete running while not using the camera skype seems to have no trouble accessing the camera.
IOW skype does not handle the EBUSY error at another moment then device open well. That only leaves the led issue, which I cannot fix without access to an actual cam. and the copete issue which is tracked separately (and certainly not a kernel bug). Closing this.