Skip to contentSkip to conversation

vivi version bump

PATCH New Carl Karsten 2 participants 4 messages Oct 30, 2008 – Nov 8, 2008 Media (V4L/DVB)

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 vivi version bump

New features have been added, so VIVI_MINOR_VERSION gets bumped.

linux/drivers/media/video/vivi.c +1 -1
diff -r 931fa560184d linux/drivers/media/video/vivi.c
@@ -53,7 +53,7 @@
 #include "font.h"
 
 #define VIVI_MAJOR_VERSION 0
-#define VIVI_MINOR_VERSION 5
+#define VIVI_MINOR_VERSION 6
 #define VIVI_RELEASE 0
 #define VIVI_VERSION \
 

Carl Karsten

linux/drivers/media/video/vivi.c +1 -1
diff -r 931fa560184d linux/drivers/media/video/vivi.c
@@ -53,7 +53,7 @@
 #include "font.h"
 
 #define VIVI_MAJOR_VERSION 0
-#define VIVI_MINOR_VERSION 5
+#define VIVI_MINOR_VERSION 6
 #define VIVI_RELEASE 0
 #define VIVI_VERSION \
 	KERNEL_VERSION(VIVI_MAJOR_VERSION, VIVI_MINOR_VERSION, VIVI_RELEASE)

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#1 lore raw

PATCH 1/1 test code tweaks

I have mods to 3 files that are all independent. Should they be split into separate patches/posts, or is adding them here fine?

And, what is the procedure to deal with a patch that supersedes a patch posted but not applied?

v4l2_tests.diff

vivi: New features have been added, so VIVI_MINOR_VERSION gets bumped.

tests/Makefile: given this is for testing, it makes sense for debug symbols to be included.

capture_example.c: Added command line option for number of frames to grab, changed the default to 70, show the defaults in help, added a Version (1.3 because I consider the original to be 1.0 and at least 2 changes have been made.)

Carl K

linux/drivers/media/video/vivi.c +1 -1
diff -r 46604f47fca1 linux/drivers/media/video/vivi.c
@@ -53,7 +53,7 @@
 #include "font.h"
 
 #define VIVI_MAJOR_VERSION 0
-#define VIVI_MINOR_VERSION 5
+#define VIVI_MINOR_VERSION 6
 #define VIVI_RELEASE 0
 #define VIVI_VERSION \
 	KERNEL_VERSION(VIVI_MAJOR_VERSION, VIVI_MINOR_VERSION, VIVI_RELEASE)
v4l2-apps/test/Makefile +2 -1
diff -r 46604f47fca1 v4l2-apps/test/Makefile
@@ -1,6 +1,7 @@
 # Makefile for linuxtv.org v4l2-apps/test
 
 CPPFLAGS += -I../include
+CFLAGS = -g
 
 binaries = ioctl-test 		\
 	   sliced-vbi-test 	\
@@ -26,6 +27,6 @@
 driver-test: driver-test.o ../lib/libv4l2.a
 
 pixfmt-test: pixfmt-test.o
-	$(CC) $(LDFLAGS) $^ $(LOADLIBES) $(LDLIBS) -o $@ -lX11
+	$(CC) $(LDFLAGS) $^ $(LOADLIBES) $(LDLIBS) $(CFLAGS) -o $@ -lX11
 
 include ../Make.rules
v4l2-apps/test/capture_example.c +16 -5
diff -r 46604f47fca1 v4l2-apps/test/capture_example.c
@@ -47,6 +47,7 @@
 static unsigned int     n_buffers;
 static int		out_buf;
 static int              force_format;
+static int              frame_count = 70;
 
 static void errno_exit(const char *s)
 {
@@ -171,7 +172,7 @@
 {
 	unsigned int count;
 
-	count = 1000;
+	count = frame_count;
 
 	while (count-- > 0) {
 		for (;;) {
@@ -558,19 +559,21 @@
 {
 	fprintf(fp,
 		 "Usage: %s [options]\n\n"
+		 "Version 1.3\n"
 		 "Options:\n"
-		 "-d | --device name   Video device name [/dev/video0]\n"
+		 "-d | --device name   Video device name [%s]\n"
 		 "-h | --help          Print this message\n"
-		 "-m | --mmap          Use memory mapped buffers\n"
+		 "-m | --mmap          Use memory mapped buffers [default]\n"
 		 "-r | --read          Use read() calls\n"
 		 "-u | --userp         Use application allocated buffers\n"
 		 "-o | --output        Outputs stream to stdout\n"
 		 "-f | --format        Force format to 640x480 YUYV\n"
+		 "-c | --count         Number of frames to grab [%i]\n"
 		 "",
-		 argv[0]);
+		 argv[0],dev_name,frame_count );
 }
 
-static const char short_options[] = "d:hmruof";
+static const char short_options[] = "d:hmruofc:";
 
 static const struct option
 long_options[] = {
@@ -581,6 +584,7 @@
 	{ "userp",  no_argument,       NULL, 'u' },
 	{ "output", no_argument,       NULL, 'o' },
 	{ "format", no_argument,       NULL, 'f' },
+	{ "count",  required_argument, NULL, 'c' },
 	{ 0, 0, 0, 0 }
 };
 
@@ -630,6 +634,13 @@
 			force_format++;
 			break;
 
+		case 'c':
+		        errno = 0;
+			frame_count = strtol(optarg, NULL, 0);
+			if (errno)
+				errno_exit(optarg);
+			break;
+
 		default:
 			usage(stderr, argc, argv);
 			exit(EXIT_FAILURE);

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

#2 lore raw

Re: [patch] test code tweaks

Quoted 2 lines · On Fri, 07 Nov 2008 22:55:44 -0600 Carl Karsten <[email protected]> wrote:

I have mods to 3 files that are all independent. Should they be split into separate patches/posts, or is adding them here fine?

Please, split in a series of patches, from [PATCH 1/3] to [PATCH 3/3]. You should notice that the patches will be imported by a script, so you should use the subject as a short summary of the patch, and the body of the email as a more complete description explaining what's inside, with your SOB, followed by the patch itself, inlined.

If you want to write a comment about the series that aren't meant to appear at the patch description, create a [PATCH 0/3] email with your descriptions.

Please read [1] if you want more details. You'll also see another explanation at [2]. You should notice that the text inside the brackets will be removed by the import scripts.

[1] http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README.patches
[2] http://linux.yyz.us/patch-format.html

Quoted 2 lines

And, what is the procedure to deal with a patch that supersedes a patch posted but not applied?

Reply at the first email with the new patch inside. Anyway, the better is to avoid this, since there's always a risk of the first patch being applied. If this happens, then you'll need to rebase your patch.

There's no way to unapply a patch at the tree (technically, you may strip a patch at the local tree, but, once applied on a public repository, you shouldn't do it. the other replicas would broke). If the patch is just completely screwed, a patch reverting it can be written, but this will cause some trash at the SCM logs, and should be avoided.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list