Em Quarta 20 Setembro 2006 20:42, você escreveu: > Hi Claudio, > > First of all thanks for willing to have a look at my problem. I work
You're welcome! > with Fedora Core 5, KDE 3.5.4 and the Kopete version that is installed > through the kdenetwork RPM is 0.11.3. However I also manually compiled > 0.12.2 which didn't work either. Let's try 0.12.2 then. When something wrong is found I'll backport it to the stable branch. > I have a Logitech QuickCam Fusion, which is a 1.3Mpixel webcam and > support for that webcam is provided by the uvcdriver of which I > downloaded the latest verion through http://linux-uvc.berlios.de/ I just saw in the driver's homepage that neither frame-based and stream-based payload aren't supported. The 1st thing my code does when it finds an V4L2 device is try to open it in memory-mapped mode. If it fails it will try to read frames using a read() function. I diddn't look (yet) into the USB UVC specification, so maybe those modes have counterparts in V4L2 with a different nomenclature. Alpha-state drivers can be troublesome. I had lots of problems (and I still have some) with a spca5xx webcam about image controls not well defined and some calls returning different values non-compliant to the V4L2 specification. The V4L2 api itself is a moving target (it changed 6 times since past year) and even drivers included in Linux kernel show problems here and there. > When I 'modprobe uvcvideo' the dmesg shows me: > > uvcvideo: Found UVC 1.00 device <unnamed> (046d:08c1) > usbcore: registered new driver uvcvideo > USB Video Class driver (v0.1.0) Aren't you running hotplugd? After installing the module and doing a depmod -qa you shouldn't need to modbrobe by hand. There are some conflicts between uvc and pwc drivers (some of the supported devices can be managed by both drivers, and it's _bad_), so please _backup_ and remove the pwc drivers present in your system. > and it creates the device as follows: > > # ls -la /dev/video* > lrwxrwxrwx 1 root root 6 Sep 21 01:23 /dev/video -> video0 > crw------- 1 joni root 81, 0 Sep 21 01:23 /dev/video0 Normal values to video devices, but the permissions are a bit odd. Mine: lrwxrwxrwx 1 root root 6 2006-09-18 19:55 /dev/video -> video1 crw-rw---- 1 root video 81, 0 2006-09-18 19:55 /dev/video0 crw-rw---- 1 root video 81, 1 2006-09-18 19:55 /dev/video1 Please note my video devices have permission 550 and my normal user is in group video. > The user joni is the user I normally use, however the modprobe is done > as root so I don't know why the device is owned by user joni. Anyway so > then I run 'Kopete --noconnect' as my normal user joni. It takes a while > to initialize and dmesg start to show a lots of messages like below: > > uvcvideo: Failed to query (132) UVC control 2 (unit 2) : -32. > uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110. > uvcvideo: Failed to query (130) UVC control 2 (unit 2) : -110. > uvcvideo: Failed to query (131) UVC control 2 (unit 2) : -75. > uvcvideo: Failed to query (132) UVC control 2 (unit 2) : -32. > uvcvideo: Failed to query (135) UVC control 2 (unit 2) : -110. It's very similar to this UVC's open bug: http://developer.berlios.de/bugs/?func=detailbug&bug_id=7605&group_id=5681 Partially-implemented features can cause weird things. But if you say me you can see the image properly in xawtv it means it's fixable in Kopete. > Then I go to the configure-->devices of kopete, which also takes a long > time and then the console shows me lots of lines like: > > read error 19, No such device A more complete log helps a lot. Inf fact it's essential. You can redirect both Kopete's standard out and atandard error streams via shell, like kopete --noconnect &> kopetelog.txt , then open the video panel, close it, close Kopete and then send the generated file as an attachment so I can theck the debug output of the video device routines. This is the stuff that will really help me looking for the bug. > And the image I get is green as you can see in snapshot1.png. I also > tried to do 'chmod 777 /dev/video0' and run kompete, but I get the same > result. The green tome is RGB 0x008700 (53% green)... It's common in colorspace convertion problems (YUV-to-RGB). I'm suspecting Kopete is trying to open the device using an unsupported colorspace and fails. The log would give me the relevant info to fix it. If you hurry a bit I can check how to fix it and the fix can be included in KDE 3.5.5 (it's about to being released). > Please advice and thanks a lot! Asap. As I don't have a similar model to test I depend on you to check if things are working fine. Please send me the log so I can to fix it quick for the release. Best regards, Cláudio da Silveira Pinheiro Kopete developer http://kopete.kde.org/team.php _______________________________________________ kopete-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kopete-devel
