PATCH: libv4l-really-sync-with-0.3.4.patch
Hi,
This patch _really_ syncs mercurial with the 0.3.4 tarbal I've just released,
at the last minute I got a bugreport that kopete was not working with the wrapper leading to the following changes:
* 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
Note that this applies on top of my previous 0.3.4 sync patch, and note that it adds a file under appl-patches !
Thanks & Regards,
Hans
v4l2-apps/lib/libv4l/ChangeLog +11 -0
@@ -3,6 +3,17 @@ * 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
v4l2-apps/lib/libv4l/appl-patches/kdenetwork-4.0.85-kopete.patch new file +12 -0
@@ -0,0 +1,12 @@ +diff -up kdenetwork-4.0.85/kopete/libkopete/avdevice/videodevice.cpp~ kdenetwork-4.0.85/kopete/libkopete/avdevice/videodevice.cpp +--- kdenetwork-4.0.85/kopete/libkopete/avdevice/videodevice.cpp~ 2008-07-07 22:40:56.000000000 +0200 ++++ kdenetwork-4.0.85/kopete/libkopete/avdevice/videodevice.cpp 2008-07-07 22:40:56.000000000 +0200 +@@ -679,6 +679,8 @@ kDebug() << "VIDIOC_S_FMT worked (" << e + if (fmt.fmt.pix.sizeimage < min) + fmt.fmt.pix.sizeimage = min; + m_buffer_size=fmt.fmt.pix.sizeimage ; ++ currentwidth = fmt.fmt.pix.width; ++ currentheight = fmt.fmt.pix.height; + } + break; + #endif
v4l2-apps/lib/libv4l/libv4l1/libv4l1.c +5 -0
@@ -453,6 +453,11 @@if ((index =v4l1_get_index (fd)) ==-1 )return syscall (SYS_ioctl, fd, request, arg); + +/* Appearantly the kernel and / or glibc ignore the 32 most significant bits +when long = 64 bits, and some applications pass an int holding the req to +ioctl, causing it to get sign extended, depending upon this behavior */ + request = (unsigned int )request;/* do we need to take the stream lock for this ioctl? */ switch (request) {
v4l2-apps/lib/libv4l/libv4l2/libv4l2.c +5 -0
@@ -541,6 +541,11 @@if ((index =v4l2_get_index (fd)) ==-1 )return syscall (SYS_ioctl, fd, request, arg); +/* Appearantly the kernel and / or glibc ignore the 32 most significant bits +when long = 64 bits, and some applications pass an int holding the req to +ioctl, causing it to get sign extended, depending upon this behavior */ + request = (unsigned int )request; +/* Is this a capture request and do we need to take the stream lock? */ switch (request) {case VIDIOC_ENUM_FMT :
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list