[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [kopete-devel] V4L2 in Kopete
From:       Taupter <taupter () gmail ! com>
Date:       2006-09-21 3:49:50
Message-ID: 200609210049.51339.taupter () gmail ! com
[Download RAW message or body]

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
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel

[prev in list] [next in list] [prev in thread] [next in thread]