libv4l-0.5.8 ------------ * Add support for UYVY (for USB Apple iSight) patch by Julien BLACHE * Remove v4lconvert_yvyu_to_yuv420 function as its functionality is duplicate with v4lconvert_yuyv_to_yuv420 * Use Requires.private where appropiate in .pc files (patch by Gregor Jasny) * Switch to using USB-id's instead of USB product string, as not all devices set a unique product string. This fixes the upside down issues with genius e-messenger 112 cams * Add support for sn9c20x-i420 format patch by Vasily Khoruzhick libv4l-0.5.7 ------------ * Fix a nasty (and stupid) bug in the special try_fmt handling for UVC cams * Add some more verbose logging of various calls when asking libv4l to log calls to a file, to assist in (future) debugging libv4l-0.5.6 ------------ * Always do a s_fmt on uvc cams even if this changes nothing, as not doing the s_fmt triggers a bug in the uvcvideo driver in kernel <= 2.6.28 (with certain cams) libv4l-0.5.5 ------------ * Avoid the use of try_fmt as much as possible on UVC cams, instead use the results of the enum_framesizes ioctl. This is because: 1) try_fmt actually causes IO with UVC cams making apps which do lot of querrying of device capabilities slow (cheese) 2) some buggy cams don't like getting lots of UVC video probes and crash when they do libv4l-0.5.4 ------------ * Don't report DQBUF errors when errno is EAGAIN, this fixes flooding the screen with errors when applications use non blocking mode * Add support for downscaling to make apps which want low resolutions (skype, spcaview) happy when used with cams which can only do high resolutions (by Lukáš Karas ). * Add support for converting to YV12 planar (next to the already supported YU12 / I420) * Implement RGB/BGR24 -> YU/YV12 conversion libv4l-0.5.3 ------------ * When conversion requires multiple passes don't alloc the needed temporary buffer on the stack, as some apps (ekiga) use so much stack themselves this causes us to run out of stack space libv4l-0.5.2 ------------ * Add Philips SPC210NC to list of cams with upside down sensor, reported by Rieker Flaik * Work around some drivers (pwc) not properly reflecting what one gets after a s_fmt in their try_fmt answer * Check that s_fmt atleast gives us the width, height and pixelformat try_fmt promised us, and if not disable conversion * Only check width, height and pixelformat when checking if we are doing conversion, instead of doing a memcmp, as that are the only things which the convert code checks * Take into account that the buffers only contain half of the lines when field is V4L2_FIELD_ALTERNATE libv4l-0.5.1 ------------ * Add support for software cropping from 352x288 -> 320x240 / 176x144 -> 160x120, so that apps which will only work with vga resolutions like 320x240 (Skype!) will work with cams/drivers which do not support cropping CIF resolutions to VGA resolutions in hardware. This makes all 2.6.27 gspca supported cams, except for the pac7302 which only does 640x480 (and skype wants 320x240), work with skype * The v4lconvert_convert function was becoming a bit of a mess, so split the functionailiy into separate v4lconvert_convert_pixfmt, v4lconvert_rotate and v4lconvert_crop functions, and make v4lconvert_convert a frontend to these * Do not link the wrapper libs against libpthread (patch from Gregor Jasny) libv4l-0.5.0 ------------ * Add support for enumerating framesizes and frameintervals of emulated formats when the driver supports it for the real format * Make sure the video device always gets opened RW even if the application asks for RO * Add Genius E-Messenger 112 (093a:2476) to list of cams which have their sensor upside down libv4l-0.4.3 ------------ * Add suport for YUYV and YVYU packed pixel formats (Jean-Francois Moine) * Prefer compressed pixformats for resolutions > 176x144 libv4l-0.4.2 ------------ * The bayer pixel order in gspca's sonixb driver was different from that in the sn9c102 driver from the mainline kernel, a recent gspca patch fixes this, adjust libv4l to match (and make it work properly with the sn9c102 driver). libv4l-0.4.1 ------------ * When the driver supports read() and we are not converting let the driver handle read() instead of emulating it with mmap mode * Fix errors and warnings when compiling with ICC (Gregor Jasny) * Add support to libv4lconvert for rotating images 90 (for Pixart 7302 cams) or 180 (Philips SPC200NC / Philips SPC300NC) degrees * Add support for Pixart custom JPEG format * Hide non public symbols (Gregor Jasny) * Fix and enable x86_64 asm jpeg decompress helper functions (Gregor Jasny) libv4l-0.4.0 ------------ * Be more relaxed in our checks for mixing read and mmap access, we were being more strict in this then certain kernel drivers (bttv) making xawtv unhappy * With some drivers the buffers must be mapped before queuing, so when converting map the (real) buffers before calling the qbuf ioctl * Add support for conversion to RGB24 (before we only supported BGR24) based on a patch by Jean-Francois Moine * When the hardware supports a format natively prefer using the native version over converting from another supported format * Various Makefile and pkgconfig file improvements by Gregor Jasny (Debian) * Drop the appl-patches dir, all application patches are now available and tracked here: http://linuxtv.org/v4lwiki/index.php/Libv4l_Progress libv4l-0.3.9 ------------ * Not only see /dev/video* but also /dev/v4l/* as video devices (only affects libv4l1 and the wrappers) patch from Brandon Philips * Silence the creation of the .pc files in the Makefiles (Brandon Philips) * Part of the copyright headers refered GPL instead of LGPL due to a copy and paste error (Brandon Philips) libv4l-0.3.8 ------------ * work around wrong REQUEST_BUFFERS ioctl return code from certain drivers * add pkg-config (.pc) files for easier detection if libv4l is available * check capabilities for streaming, if the driver cannot do streaming don't insert ourselves between the application and the driver * intercept get capabilites and report read capability (which we always offer) * query buffer: indicate the mapping state of our (fake) buffer in the flags libv4l-0.3.7 ------------ * Add spca505/6 and spca508 cam specific formats (YUYV per line variations) libv4l-0.3.6 ------------ * Add missing COPYING.LIB file libv4l-0.3.5 ------------ * Make JPEG decoding more robust libv4l-0.3.4 (the brownpaperbag release) ---------------------------------------- * The mmap64 support in 0.3.3, has caused a bug in libv4l1 when running on 32 bit systems (who uses those now a days?), this bug caused v4l1 compatibility to not work at all, this release fixes this * Some apps (xawtv, kopete) use an ioctl wrapper internally for various reasons. This wrappers request argument is an int, but the real ioctl's request argument is an unsigned long. Passing the VIDIOC_xxx defines through to the wrapper, and then to the real ioctl, causes the request to get sign extended on 64 bit args. The kernel seems to ignore the upper 32 bits, causing the sign extension to not make a difference. libv4l now also ignores the upper 32 bits of the libv4lx_ioctl request argument on 64 bit archs * Add a bugfix patch for kopete in the appl-patches dir, currently it assumes that it got the width and height it asked for when doing a S_FMT, which is a wrong assumption libv4l-0.3.3 ------------ * Add open64 and mmap64 wrappers to the LD_PRELOAD wrapper libs, so that they also work for applications compiled with FILE_OFFSET_BITS=64, this fixes using them with v4l-info * While looking at xawtv in general, found a few bugs in xawtv itself, added a patch to fix those to the appl-patches dir * Talking about the appl-patches dir, restore that as it accidentally got dropped from 0.3.2 * Be more verbose in various places when it comes to logging (esp errors) * Change v4lconvert_enum_fmt code a bit, so that it is easier to add more supported destination formats to libv4lconvert * Don't return -EINVAL from try_fmt when we cannot convert because the cam doesn't have any formats we know. Instead just return as format whatever the cam returns from try_fmt, this new behavior is compliant with the v4l2 api as documented libv4l-0.3.2 ------------ * Add support for converting from sn9c10x compressed data * Add support for converting from pac207 compressed data * Add "make install" Makefile target libv4l-0.3.1 ------------ * Only serialize V4L2_BUF_TYPE_VIDEO_CAPTURE type ioctls * Do not return an uninitialized variable as result code for GPICT (fixes vlc, but see below) * Add an apps-patches directory which includes: * vlc-0.8.6-libv4l1.patch, modify vlc's v4l1 plugin to directly call into libv4l1, in the end we want all apps todo this as its better then LD_PRELOAD tricks, but for vlc this is needed as vlc's plugin system causes LD_PRELOAD to not work on symbols in the plugins * camorama-0.19-fixes.patch, small bugfixes to camorama's v4l1 support, this patch only fixes _real_ bugs in camorama and does not change it to work with v4l1compat. Although it does work better with these bugs fixed :) With this patch and LD_PRELOAD=/v4l1compat.so it works flawless. libv4l-0.3 ---------- * add extern "C" magic to public header files for c++ usage (Gregor Jasny) * Make libv4l1 and libv4l2 multithread use safe, see README.multi-threading * Add v4lx_dup() calls (and intercept dup() from the wrappers) this fixes use with gstreamer's v4l2 plugin (tested with cheese) * Hopefully definitely fix compile errors on systems with a broken videodev2.h libv4l-0.2 ---------- *** API change *** * Change v4lconvert api so that the v4lconvert struct always gets allocated by the library, this to make it opaque, so that we can avoid future API and ABI changes * Add support for yuv420 -> bgr24 conversion * When converting from v4l2 pixelformat to v4l12 palette return VIDEO_PALETTE_YUV420P instead of VIDEO_PALETTE_YUV420 for V4L2_PIX_FMT_YUV420 as that is what most apps seem to expect * override kernel v4l1 compat min / max size with our own more accurate values * fix v4l1 munmap bug where it didn't recognise the buffer being unmapped was our fake buffer (fixes gstreamer v4l1 support, checked with cheese) * add support for reporting the emulated pixelformats with ENUM_FMT, this defaults to off, and can be activated by passing a flag to enable it to v4l2_fd_open. This gets enabled by default the wrappers. * v4l2: mmap the real device buffers before doing conversion when DQBUF gets called before the application has called mmap (avoid crash). libv4l-0.1 ---------- * major shuffle / rewrite now split into libv4l1, libv4l2, libv4lconvert and 2 wrappers for binary compatibility * rewritten LGPL bayer decoding * many many other changes and fixes 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. v4l1-compat-0.5 (perfect camorama) ---------------------------------- * Allow changing of format after the buffers have been mapped, by tearing down the entire house, changing the fundament and then rebuilding it. Now changing the capture resolution in camorama works! * Fix jpeg decoding error reporting * Allow jpeg's with a height which is a multiple of 8 (was 16) * Remove a number of pretty new VIDIOCXXX -> string mappings from log.c, fixing compiling with somewhat older kernels v4l1-compat 0.4 --------------- * Do not even try to change the format in v4l1_compat_set_format(), unless _really_ necessary. * Cleanup ambigious use of src_format (no functional changes) * Drop the mmap hack for zerocopy access under certain conditions, one of them that the cam can deliver the requested format. Although avoiding the memcpy in this scenarios is a good thing todo, there were several issues with the 0.3 implementation of this, fixing all these means adding lots of special cases all over the code. So instead we just drop support and always do atleast a memcpy (or a conversion). If an application cannot live with the speed penalty this imposes it should be ported to v4l2. * Now that we've gotten rid of the zerocopy mmap hack, we can safely allow mixing read and mmap based IO. * Explictly include linux/ioctl.h, to fix compile with kernel headers where linux/videodev.h doesn't. v4l1-compat 0.3 --------------- * Don't allow multiple opens, in theory our code can handle it, but not all v4l2 devices like it (ekiga does it and uvc doesn't like it). v4l1-compat 0.2 --------------- * When mmap gets passed an fd of -1 (anonymous map) don't look for it in our list of managed fds, as we use -1 to mark unused entries (fixes ekiga crashing). Also check for an fd of -1 in the other calls we intercept. * In close() start with removing the fd from our list of managed fds, this must be done first, because as soon as we've done the actual close syscall, the fd maybe returned by an open in another thread and we don't want to intercept calls to this new fd. * Make unknown v4l1 palette types a normal level log messages instead of an error. * When an applicaiton changes the width / height through the CMCAPTURE ioctl remember the new width and height. * If the devices initial v4l2 pixformat has no corresponding v4l1 palette, try setting a format which does (and which we emulate when necessary) so that applicactions which just query the current format (GPICT) and then take whatever they get will work (partially fixes camorama) * Implement our own SWIN instead of using kernel compat layer, for more flexibility and better error checking v4l1-compat 0.1 --------------- * Initial public release.