v4l2-apps: move libraries around to make the directory tree flatter

From: Hans Verkuil <hverkuil@xs4all.nl>

Instead of having libv4l2util in v4l2-apps/lib and libv4l in v4l2-apps/lib/libv4l,
both are now moved to v4l2-apps/libv4l2util and v4l2-apps/libv4l.

This is much cleaner and less confusing.

Priority: normal

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>

1 files changed, 0 insertions, 247 deletions

diff --git a/v4l2-apps/lib/libv4l/ChangeLog b/v4l2-apps/lib/libv4l/ChangeLog
deleted file mode 100644
index dd53eced9..000000000
--- a/v4l2-apps/lib/libv4l/ChangeLog
+++ /dev/null
@@ -1,247 +0,0 @@
-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=<path>/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.