Red Hat Bugzilla – Bug 460956
Patch(es): fix cheese on systems with more then1 v4l device
Last modified: 2008-09-03 16:53:15 EDT
Created attachment 315587 [details]
In the light of the better webcam project:
I've added a TV-card to my system to make sure that non of the changes I'm making to improve webcam support break use of other v4l devices.
The combination of a tv-card and a webcam turns out to trigger a whole slew of bugs in cheese. For which I've written a whole slew of patches.
Given that I'm very much into webcams now and know cheese pretty good to now, I would like to offer to co-maintain (or take over) cheese, and then commit all these patches myself (and take care of any fallout although I strongly believe there will be none). Does that sound like a plan?
Here is the list of patches:
First of all cheese lists /dev/vbi0 and /dev/radio0 as devices to select as source and then crashes in various ways because it does not know howto handle these devices, this is fixed by using ioctl's to check if the device has capture capability (filters out radio devices) and with a strcmp on the device for the vbi case (seems the only way), this is patch:
Cheese uses an hash table to allow for quick lookup of videoformats based on resolution, but this hash table is global (not per device), so looking in it can end up with a format from another device then the device which is currently used as source, this is fixed by:
These 2 patches are a must have for crash free operation with multiple devices!
In cases where the device supports the same resolution in multiple video formats, the resolution will get listed multiple times in the resolutions list in the preferences dialog. With my bttv card which supports grabbing in many different pixformats each resolution gets shown 16 times!
The following chain of patches fixes this:
Currently when a resolution is listed multiple times cheese will either request yuv or rgb mode for the v4l2 source depending on which entry was clicked, the first patch removes this behavior, letting gstreamers negotiation choose whatever is most appropriate.
The second patch is just some code refactoring without any functional changes, to make the third patch easier to read, the third patch actually filters out all the double resolutions. The last patch sorts the list of resolutions from small to big, as a random order list doesn't look good in the GUI.
All these patches are also submitted upstream:
Created attachment 315588 [details]
Created attachment 315589 [details]
Created attachment 315590 [details]
Created attachment 315591 [details]
Created attachment 315592 [details]
Hans, you are quite welcome to join in the cheese maintainership.
(In reply to comment #6)
> Hans, you are quite welcome to join in the cheese maintainership.
Ok, I've applied for the necessary right. Is it ok with you if I commit my patches (they are being merged upstream) I would like to have them in rawhide before the beta freeze, so that cheese will be in good shape in the beta as I plan to actively solicit for webcam testing with the beta.
Also is it ok if I start closing cheese bugs for which I have the hardware to reproduce them and for which I believe they have been fixed in rawhide?
I've approved your requests. Please feel free to commit those patches and look after cheese bugs as you see fit. Thanks. The one thing I'm pretty adamant about is that all patches we carry should have an upstream bug reference, but I'm sure you'll take care about that anyway.
A version with all the patches mentioned here applied is on its way to rawhide now, closing.