Red Hat Bugzilla – Bug 457796
PATCH(es): fixes + libv4l support + more fixes
Last modified: 2008-08-27 05:55:46 EDT
Created attachment 313380 [details]
Short intro: I'm a long time Linux developer currently working on improving
webcam support in Linux, see:
I'm one of the authors of the v4l2 rewrite of the gspca usb webcam driver
framework (which supports more then 100 different cams), this v4l2 rewrite has
been merged into the 2.6.27 kernel and thus will become available in the
official Linux kernel soon.
One of the parts of the v4l2 rewrite has been removing conversion from various
manufacturer cam specific video formats to more normal videoformats from the
drivers, as this really does not belong in kernel space.
As a result of this the gspca subdrivers can generate raw video frames in the
#define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S', '5', '0', '1') /* YUYV per line
#define V4L2_PIX_FMT_SPCA505 v4l2_fourcc('S', '5', '0', '5') /* YYUV per line
#define V4L2_PIX_FMT_SPCA508 v4l2_fourcc('S', '5', '0', '8') /* YUVY per line
#define V4L2_PIX_FMT_SPCA561 v4l2_fourcc('S', '5', '6', '1') /* compressed
#define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed
As we do not want to see each application implement (nor having to implement)
support for these various formats, as we like to have one code base and only
one code base for these formats. A library has been written (with me as the
main author) to convert from these formats to BGR24 or YUV420. For more on this
As such I've been working (for a number of days!) on a patch to add support for libv4l to xawtv. This has resulted in my doing a whole patch series, listed in the order in which the patches should be applied.
Some small fixes which are needed for xawtv-3.95 to work with some v4l2 devices at all.
Use libv4l2 to gain support for all kind of camera specific video formats
xawtv does not work on many videocards without specifying -nodga, this patch
fixes this by catching the error and continuing as if the server does not support DGA at all
Allow root to override the detected number of bytes per line, this is needed
to get direct pci transfers to the framebuffer to work on my ati x1950pro
Note that for xawtv to work properly atleast version 0.4.0 of libv4l is needed,
rawhide currently has 0.3.9 and I cannot build 0.4.0 due to an error in the kernel-headers package.
While writing all these patches and with all my recent v4l work in general I've become quite familiar with the xawtv code, so if you want I can become a co-maintainer (and push these patches myself).
Created attachment 313381 [details]
Created attachment 313382 [details]
Created attachment 313392 [details]
I would really like to see this fixed before F10-beta freeze so that the better webcam support feature can get some good testing in the Beta.
I am still thinking how to make libv4l2 support optional...
It seems that an option is not suitable here, as there are several applications (xawtv, streamer, fbtv, ...) and it is not good to hack all their cmdline interfaces.
Perhaps LD_PRELOAD is a way? If the only application still used by "end users" is "xawtv", then maybe just add "LD_PRRELOAD=..." into its .desktop file? (Saving all another utils unchanged).
P.S. Could you add autoconf stuff for libv4l2 patch as well?
(In reply to comment #5)
> I am still thinking how to make libv4l2 support optional...
Why would you want todo that? libv4l was explicitly designed to be transparent to the application.
With the current patch, libv4l does not get used / linked in to the lowlevel v4l-info, v4l-conf and v4lctl programs, so those are not affected, all the others actually stream data from the cam in one form or the other and thus need libv4l to work with cams which have funky video formats (IOW most of them!!).
> P.S. Could you add autoconf stuff for libv4l2 patch as well?
Why? Its a distro specific patch and we will always want to enable libv4l support, I will take a look at autoconf support when a new upstream is formed and patches need to become non distro specific so that they can be merged upstream.
> libv4l does not get used / linked in to the lowlevel
> v4l-info, v4l-conf and v4lctl programs
"v4lctl" actually uses libng drivers, ie. the patch affects it as well.
(In reply to comment #7)
> > libv4l does not get used / linked in to the lowlevel
> > v4l-info, v4l-conf and v4lctl programs
> "v4lctl" actually uses libng drivers, ie. the patch affects it as well.
Ah I didn't know that even then though, this is not a problem as libv4l does not touch any of the CTRL related ioctl's it passes them through to the kernel *completely* unmodified.
I've added your patches (I have a little touched them, and add manual stuff for the "-p pitch"). Additionally, I've added some debian ones.
The results are available in Koji:
Looks (In reply to comment #9)
> I've added your patches (I have a little touched them, and add manual stuff for
> the "-p pitch"). Additionally, I've added some debian ones.
> The results are available in Koji:
Works like a charm, including accessing webcams which do not work without libv4l and using my bttv tv card.