Version: (using KDE KDE 3.4.92) Installed from: Unlisted Binary Package OS: Linux My webcam's picture in kopete is shown in green colours. The same camera works fine on the same pc with gnomemeeting. dmesg output: usb 1-1: new full speed USB device using uhci_hcd and address 2 Linux video capture interface: v1.00 sn9c102: V4L2 driver for SN9C10x PC Camera Controllers v1:1.24a usb 1-1: SN9C10[12] PC Camera Controller detected (vid/pid 0x0C45/0x600D) usb 1-1: PAS106B image sensor detected usb 1-1: Initialization succeeded usb 1-1: V4L2 device registered as /dev/video0 usb 1-1: Optional device control through 'sysfs' interface ready usbcore: registered new driver sn9c102
Am Mittwoch, 19. Oktober 2005 14:45 schrieb pholie: > usb 1-1: V4L2 device registered as /dev/video0 afaik v4l2 is not fully supported by now.. if it works: fine. if not: you must wait ;)
Ah, then ok. I thought it should be working by now. An idea when it will be done? It doesn't seem like it can get into 3.5 final.
Am Mittwoch, 19. Oktober 2005 17:18 schrieb pholie: [bugs.kde.org quoted mail] hum.. it's done when it's done ;) no it wont be in kde3.5
I think the green come from the color auto-adjustment option that is broken. just try disabling it. I'm not totally sure.
Hi all! I have experienced the same issue with my webcam - ov519 with ov51x-jpeg. The work around for me was to force palette to either 13 - VIDEO_PALETTE_YUV422P - or VIDEO_PALETTE_RGB24, number 4. Hope this can help...
This problem is caused by the drivers. The ioctl (VIDIOC_SETSTD) used to change video mode, according to the V4L2 specification, should return and error 515 when the mode is not supported. Some modules don't obey the specification, returning a different value or not claiming a failure at all, because the VIDIOC_ENUMSTD supposedly should return all the available modes when called and the programmer should use it instead to detect the mode. The pwc driver had this problems (now fixed), and some other drivers still behave erraticly (even some of the drivers provided by V4L2's Linux Kernel maintainers. If you try kdetv and other similar programs you'll find from time to time a device that has green/psychodelic/younameit colors (I commited some changes to the kdetv to fix _one_ of these issues a long ago with the spca5xx driver). Changes to kopete's code are being made to handle these _driver_ problems, but it may be a while before all of them are fixed. Some changes in the structure of the code are being made to allow pluggable modules and support for other devices, and these are a bit bigger than I wanted it to. As for now I have no internet connection at home so I cannot commit code (I'm not allowed to do it from work), so I'm stuck here waiting for the ISP to install it. Development is occurring in the 0.12 branch.
VIDIOC_*STD ioctls are not the point here (the sn9c102 driver returns -EINVAL when they are invoked, becouse they have no sense with webcams). Make sure the application supports the Bayer or compressed pixel format given by the driver. See the V4L2 for informations about video format negotation between driver and applications. Additional info: www.linux-projects.org (see Sections)
I looked into this as a user was complaining of it with the sq905 driver and I was able to reproduce it with kopete-0.12beta2. I've had a quick look at the code and I think there is a bug in VideoDevice::setPixelFormat for V4L2 devices. If the VIDIOC_S_FMT ioctl succeeds it assumes it has set the new format but the V4L2 documentation says the driver should change the format to something it does support if it can't do what is requested. It also tries to request formats that it doesn't know how to decode. The workaround buggy driver option doesn't make it very clear to the user that it is actually selecting V4L instead of V4L2 so will also work around lack of application support for V4L2. It also fails to stick sometimes - I think it doesn't like the fact that a device can have slightly different names and input options when it is addressed via V4L instead of V4L2 - at one point I got things in a state where it alternatively used V4L and worked and V4L2 and didn't.
From http://v4l2spec.bytesex.org/spec-single/v4l2.html#VIDIOC-G-FMT "When the requested buffer type is not supported drivers return an EINVAL error code on a VIDIOC_S_FMT attempt.". That's the way the current code is checking formats. It currently supports RGB and YUV formats (including conversions). Bayer or compressed pixel formats are not supported ATM cause I don't have a card/webcam that has these pixelformats, so I can't test something against a device I don't own, and patching without having means of testing the patch is not very clever as it can worsen the situation for people who already have working devices. If somebody has a device, develops a patch and it works, I can test it to check if it doesn't change adversely already supported devices I'll commit that code. The "Workaround buggy driver" option doesn't clearly states it will force device to operate in V4L2 _on_purpose_. Kopete does not run only in Linux; BSD people use it and (hopefully) webcams will be supported, and when (and if) Kopete4 runs on Windows it should support webcams there too, so this option must be as much platform-agnostic as possible, and used only when things go really wrong. See, V4L should be dead a long ago but drivers are still developed using this API (spca5xx), there's an "early" V4L2 (for pre-2.6 kernels) and a "new" V4L2 APIs. Only in the last 6 months V4L2 API got 6 new versions (from 0.8 to .13). It's just a moving target as ALSA was before the 1.0 release. Right now they're discussing in V4L mailing list about the _standard_api_ for _compressed_formats_! Some drivers (the new pwc as an example) implement calls that return values not conformant to either V4L and V4L2 expected values. spca5xx driver, at least in my hardware (Creative Webcam NX Pro) treat brightness and contrast as the _same_thing_. Putting lots of workaround in Kopete's code is not the right way; we must fix what's wrong with Kopete code and ask driver writers (as I already did and sent patches) to put things according to the canonical APIs.
If someone makes a patch for kopete I can test if it works. Just let me know.
I quite agree that kopete can't hope to work around all the possible driver bugs. As deputy maintainer for the sq905 driver I'd like to make it work with kopete. My reading of http://v4l2spec.bytesex.org/spec/r6935.htm is that the driver should only return EINVAL if v4l2_format.type doesn't contain a supported value, i.e. if you are asking a webcam to do video overlay. If v4l2_format.pix.pixelformat.colorspace isn't supported the driver should change it to a value that is supported and return 0. If you can convince me I've misunderstood then I'll change the driver. If you intend to leave the behaviour that kopete tries all possible colourspaces, even ones that it can't decode then you should probably start searching with the formats you can decode and stop with the first one that the driver accepts.
Created attachment 18139 [details] do not still work in kopete i use kde 3.5.5 and ov51x-jpeg (ov51x and ov519-decomp) driver from http://www.rastageeks.org/ov51x-jpeg/index.php/Main_Page with an Hercules Classic webcam. sad to see it works with some other software except kopete
Created attachment 18207 [details] Patch to enable Bayer & sn9x102 huffman compressed formats
Geoff the patch you attached is missing the new sourcefiles you added.
Anything new ? I use the uvcvideo driver (modified for iSight) but it doesn't work in kopete. It is V4L2 only as far as i know. I don't know how kopete works, but it works with the gstreamer pipeline. Why can't kopete use gstreamer ?
can confirm the isight problem. video is greenish and colors are wrong.
Geoff, could you regenerate your patch after 'svn add'ing any new files? I think taupter added bayer but I don't know about sn9x102 huffman. Thanks.
By the way, uvcvideo should work in KDE 3.5.8.
Created attachment 22183 [details] Proper patch to enable sn9x102 and bayer RGB formats Here's the patch re-made against the 3.5 branch and with the previously missing files included.
Ok. Commits 762475 and 762481 by yours truly should fix this issue for good. :D Please report asap as I don't have the needed hardware to test it, and if successful I need to port it to 4.0.x and 4.1.x.
Fixed. KDE 4's Kopete has problems detecting some devices due to bugs in drivers like sn9c102, pwc, uvc (some devices) and others. Trying to fix these issues with driver maintainers.
*** Bug 149539 has been marked as a duplicate of this bug. ***
Hi. Could anyone give details on how to apply that patch? I'm quite a newbie with Linux. Thank you very much.
Diego, Just download the newest driver from the maintainer's page and you're set.
Hi Cláudio, :-S Could you please specify which the maintainer's page is? I am afraid... Thank you
Still have problem with my Chicony webcam in laptop. It shows green picture and webcam is offline (she didnt started - power light on my webcam didnt shined) but in luvcview it works properly
Also have this problem with latest uvc driver - both with kopete, and with 'webkam' program I have recently found - the webcam's light is not shining, though /dev/video0 is locked by kopete process. This is my post to the uvc-devel mailing list: I have Hp Pavilion dv6000 notebook with built-in webcam > lsusb Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 002: ID 03f0:171d Hewlett-Packard Wireless (Bluetooth + WLAN)Interface [Integrated Module] Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 064e:a110 Suyin Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub From here it seems that my webcam is this entry: Bus 002 Device 002: ID 064e:a110 Suyin Corp. from here http://linux-uvc.berlios.de/ searching by device id gives the following line: 064e:a110 HP Webcam (HP TX2000 notebooks) SuYin (supported) I'm using driver compiled from svn I wanted to write that it does not work here for me - luvcview shows blue screen, but just started it again and found interesting thing - it shows blue screen only when the webcam window is located on the left half of the monitor - when I move it to the right half the picture appears! Fullscreen works ok. KdeTV has exactly the same behavior - blue screen to the left, picture on the right. Kopete only shows green screen, thought it locks the /dev/video0 device and shows hp webcam in the available device list. Ekiga just shows error message and even does not lock the device. I don't care about ekiga, but having some advice on how to make kopete work with it would be nice. Just in case, here is the luvcview output: > luvcview luvcview 0.2.4 SDL information: Video driver: x11 A window manager is available Device information: Device path: /dev/video0 Stream settings: Frame format: YUYV (MJPG is not supported by device) Frame size: 640x480 Frame rate: 30 fps thank's