v4l1 compat version 0.6 aka V4L2 apps stay working

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
get
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
example
YUV420P becomes YUV420, which are separate in v4l1.

Given the high rate of me pushing out releases I was planning to stop spamming
the list with tarbals (however small), but my personal webspace is down (yeah!)
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.

Regards,

Hans

Hi Hans,

Quoted 35 lines

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
get
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
example
YUV420P becomes YUV420, which are separate in v4l1.

Given the high rate of me pushing out releases I was planning to stop spamming
the list with tarbals (however small), but my personal webspace is down (yeah!)
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.

Quoted 4 lines

Regards,

Hans

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
http://www.linuxtv.org/v4lwiki/index.php/V4L2UserspaceLibrary
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?

- 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?

Regards,
Thierry