Re: [Spca50x-devs] v4l1 compat version 0.6 aka V4L2 apps stay working
- Date: Tue, 10 Jun 2008 18:23:57 +0200
- From: Hans de Goede <j.w.r.degoede@xxxxxx>
- Subject: Re: [Spca50x-devs] v4l1 compat version 0.6 aka V4L2 apps stay working
Thierry Merle wrote:
> Hi Hans,
>> Hi All,
>> Changes since last version:
>> v4l1-compat-0.6 (V4L2 apps stay working)
>> * Do not go into emulation mode of rgb24 immediately, but only after a
>> GPICT ioctl which has not been preceded by a SPICT ioctl, AKA do not
>> in the way of V4L2 read calls by doing conversion on them
>> * Do not get in the way of mmap calls made by V4L2 applications
>> * Fix swapping of red and blue in bayer -> bgr24 decode routine
>> * Remember the v4l1 palette asked for with SPICT and return that, as
>> otherwise we loose information when going v4l1 -> v4l2 -> v4l1, for
>> YUV420P becomes YUV420, which are separate in v4l1.
>> Given the high rate of me pushing out releases I was planning to stop
>> the list with tarbals (however small), but my personal webspace is down
>> so one more time in spam modues, sorry.
>> With this version all apps tried sofar:
>> * spcaview read / mmap mode, yuv420 and bgr24
>> * ekiga v4l1 read / mmap mode
>> * camorama including changing capture resolution while streaming
>> Work fine, note with some cams camorama might need a small bugfix though,
>> as it
>> assumes that cams have a resolution exactly half of their max resolution
>> available, and as such ignores then width/height returned by VIDEOCSWIN,
>> assuming it got what it asked for, the patch against camorama 0.19
>> attached to
>> my 0.5 announcement mail fixes this.
> I took a look at your library, seems simple and interesting!
> You are overloading open/close/ioctl/read/mmap and catch these operations
> on /dev/videoX path to do whatever you want, like frame conversion.
> This is a simpler solution than the one on
> that is complex and incomplete regarding the implementation, sadly.
> - You said that arts is using the same system. Does it conflict with the
> use of arts from an application point of view?
Not that I know of it also intercepts open and a few others like my lib does,
also through using LD_PRELOAD, when you've arts installed there is an artsdsp
command, so to run an app foo which wants to use oss soundoutput though arts
one could do:
And then the artsdsp shell script would set the necessary env. variables
causing libartsdsp.so.0 to be LD_PRELOAD-ed, intercepting open / write of / to
/dev/dsp redirecting that to arts.
> - The device driver will still have to declare the compressed pixel
> formats (V4L2_PIX_FMT_MJPEG, ...) to interface the library. The usbvision
> device provides a proprietary pixel format but I cannot name it; how we
> will cope with that?
Just make up your own fourcc code and V4L2_PIX_FMT_MJPEG define and get that
added to include/linux/videodev2.h (and make your driver report this format)
after that I would be happy to take patches to add support for this format to
In the future I plan to even do v4l2 -> v4l2 emulation doing conversion only,
so that not all v4l2 apps need to know about all exotic formats like
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Spca50x-devs mailing list