From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: "need4weed@gmail.com" <need4weed@gmail.com>,
Elmar Kleijn <elmar_kleijn@hotmail.com>,
video4linux-list@redhat.com, spca50x-devs@lists.sourceforge.net
Subject: v4l1 compat version 0.5 aka perfect camorama release
Date: Sun, 08 Jun 2008 20:07:23 +0200 [thread overview]
Message-ID: <484C1FDB.8060205@hhs.nl> (raw)
[-- Attachment #1: Type: text/plain, Size: 1944 bytes --]
Hi All,
Changes since last version:
v4l1-compat-0.5
---------------
* 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.
With this version all apps tried sofar:
* spcaview read / mmap mode, yuv420 and bgr24
* ekiga v4l1 read / mmap mode
* camorama including changing capture resolution while streaming
Work fine, note with some cams camorama might need a small bugfix though, as it
assumes that cams have a resolution exactly half of their max resolution
available, and as such ignores then width/height returned by VIDEOCSWIN,
assuming it got what it asked for, the attached patch against camorama 0.19
fixes this.
Regards,
Hans
[-- Attachment #2: v4l1-compat-0.5.tar.gz --]
[-- Type: application/x-gzip, Size: 28680 bytes --]
[-- Attachment #3: camorama-0.19-size-may-differ-from-requested.patch --]
[-- Type: text/plain, Size: 1123 bytes --]
--- camorama-0.19/src/callbacks.c 2007-09-16 15:36:55.000000000 +0200
+++ camorama-0.19.new/src/callbacks.c 2008-06-08 16:24:00.000000000 +0200
@@ -387,9 +387,6 @@
}
}
- cam->pixmap = gdk_pixmap_new (NULL, cam->x, cam->y, cam->desk_depth);
- gtk_widget_set_size_request (glade_xml_get_widget (cam->xml, "da"),
- cam->x, cam->y);
/*
* if(cam->read == FALSE) {
@@ -441,6 +438,11 @@
* * }
*/
get_win_info (cam);
+
+ cam->pixmap = gdk_pixmap_new (NULL, cam->x, cam->y, cam->desk_depth);
+ gtk_widget_set_size_request (glade_xml_get_widget (cam->xml, "da"),
+ cam->x, cam->y);
+
frame = 0;
gtk_window_resize (GTK_WINDOW
(glade_xml_get_widget (cam->xml, "main_window")), 320,
--- camorama-0.19/src/v4l.c 2007-09-16 14:48:05.000000000 +0200
+++ camorama-0.19.new/src/v4l.c 2008-06-08 14:15:21.000000000 +0200
@@ -231,7 +231,8 @@
g_free(msg);
exit(0);
}
-
+ cam->x = cam->vid_win.width;
+ cam->y = cam->vid_win.height;
}
void set_buffer(cam * cam)
[-- Attachment #4: 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
reply other threads:[~2008-06-08 18:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=484C1FDB.8060205@hhs.nl \
--to=j.w.r.degoede@hhs.nl \
--cc=elmar_kleijn@hotmail.com \
--cc=need4weed@gmail.com \
--cc=spca50x-devs@lists.sourceforge.net \
--cc=video4linux-list@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox