vivi version bump
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
@@ -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
@@ -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
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
@@ -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
@@ -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
@@ -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
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
Re: [patch] test code tweaks
Thanks for the details.
I am sending just one patch until I get the process done right. Then I can send the other two with ease :)
Carl K
--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list