| Age | Commit message (Collapse) | Author |
|---|
|
From: Hans de Goede <j.w.r.degoede@hhs.nl>
* 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
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
|
|
From: Hans de Goede <j.w.r.degoede@hhs.nl>
* 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
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
|
|
From: Hans de Goede <j.w.r.degoede@hhs.nl>
Fix all compiler warnings in libv4l
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
|
|
From: Hans de Goede <j.w.r.degoede@hhs.nl>
This patch syncs (updates) the libv4l in mercurial with (to) the latest 0.3.1
release.
- 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.
Signed-off-by: Hans de Goede <j.w.r.degoede@hhs.nl>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
|
|
From: Hans de Goede <j.w.r.degoede at hhs.nl>
libv4l2 offers v4l2_ prefixed versions of
open/close/etc. The API is 100% the same as directly opening /dev/videoX
using regular open/close/etc, the big difference is that format conversion
is done if necessary when capturing. That is if you (try to) set a capture
format which is not supported by the cam, but is supported by libv4lconvert,
then the try_fmt / set_fmt will succeed as if the cam supports the format
and on dqbuf / read the data will be converted for you and returned in
the request format.
v4l2convert: open/close/ioctl/mmap/munmap library call wrapper doing format conversion
for v4l2 applications which want to be able to simply capture bgr24 / yuv420
from v4l2 devices with more exotic frame formats.
Signed-off-by: Hans de Goede <j.w.r.degoede at hhs.nl>
Signed-off-by: Thierry MERLE <thierry.merle@free.fr>
|
