* PATCH: libv4l-really-sync-with-0.3.4.patch
@ 2008-07-07 21:48 Hans de Goede
0 siblings, 0 replies; only message in thread
From: Hans de Goede @ 2008-07-07 21:48 UTC (permalink / raw)
To: Thierry Merle; +Cc: video4linux-list, v4l2 library
[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]
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
[-- Attachment #2: libv4l-really-sync-with-0.3.4.patch --]
[-- Type: text/x-patch, Size: 3444 bytes --]
diff -r b727e145976f v4l2-apps/lib/libv4l/ChangeLog
--- a/v4l2-apps/lib/libv4l/ChangeLog Mon Jul 07 23:35:40 2008 +0200
+++ b/v4l2-apps/lib/libv4l/ChangeLog Mon Jul 07 23:37:40 2008 +0200
@@ -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
diff -r b727e145976f v4l2-apps/lib/libv4l/appl-patches/kdenetwork-4.0.85-kopete.patch
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/v4l2-apps/lib/libv4l/appl-patches/kdenetwork-4.0.85-kopete.patch Mon Jul 07 23:37:40 2008 +0200
@@ -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
diff -r b727e145976f v4l2-apps/lib/libv4l/libv4l1/libv4l1.c
--- a/v4l2-apps/lib/libv4l/libv4l1/libv4l1.c Mon Jul 07 23:35:40 2008 +0200
+++ b/v4l2-apps/lib/libv4l/libv4l1/libv4l1.c Mon Jul 07 23:37:40 2008 +0200
@@ -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) {
diff -r b727e145976f v4l2-apps/lib/libv4l/libv4l2/libv4l2.c
--- a/v4l2-apps/lib/libv4l/libv4l2/libv4l2.c Mon Jul 07 23:35:40 2008 +0200
+++ b/v4l2-apps/lib/libv4l/libv4l2/libv4l2.c Mon Jul 07 23:37:40 2008 +0200
@@ -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:
[-- Attachment #3: Type: text/plain, Size: 164 bytes --]
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2008-07-07 21:42 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-07 21:48 PATCH: libv4l-really-sync-with-0.3.4.patch Hans de Goede
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox