NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Brandon Philips]

On 15:31 Thu 31 Jan 2008, Guennadi Liakhovetski wrote:
> From: Steven Whitehouse <steve@chygwyn.com>
> 
> This adds two new fourcc codes (as per info at fourcc.org)
> for 16bpp mono and 16bpp Bayer formats.

This patch was merged in the following commit:
 http://linuxtv.org/hg/v4l-dvb/rev/d002378ff8c2

I have a number of issues:
 
- Why was V4L2_CID_AUTOEXPOSURE added!  I am working to get an auto
  exposure control into the spec but this was merged without discussion.
  Please remove this and wait for my patch.

- Why was a SoC config option added with this commit?

- mailimport changes in this commit too!  Why is mailimport running
  sudo!?! 

A mistake was obviously made here.

	Brandon


--- a/linux/drivers/media/video/Kconfig	Sun Jan 27 17:24:26 2008 +0000
+++ b/linux/drivers/media/video/Kconfig	Mon Feb 04 16:32:42 2008 -0200
@@ -836,4 +836,13 @@ config USB_STKWEBCAM
 
 endif # V4L_USB_DRIVERS
 
+config SOC_CAMERA
+	tristate "SoC camera support"
+	depends on VIDEO_V4L2
+	select VIDEOBUF_DMA_SG
+	help
+	  SoC Camera is a common API to several cameras, not connecting
+	  over a bus like PCI or USB. For example some i2c camera connected
+	  directly to the data bus of an SoC.
+
 endif # VIDEO_CAPTURE_DRIVERS
--- a/linux/include/linux/videodev2.h	Sun Jan 27 17:24:26 2008 +0000
+++ b/linux/include/linux/videodev2.h	Mon Feb 04 16:32:42 2008 -0200
@@ -281,6 +281,7 @@ struct v4l2_pix_format
 #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B','G','R','4') /* 32  BGR-8-8-8-8   */
 #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R','G','B','4') /* 32  RGB-8-8-8-8   */
 #define V4L2_PIX_FMT_GREY    v4l2_fourcc('G','R','E','Y') /*  8  Greyscale     */
+#define V4L2_PIX_FMT_Y16     v4l2_fourcc('Y','1','6',' ') /* 16  Greyscale     */
 #define V4L2_PIX_FMT_PAL8    v4l2_fourcc('P','A','L','8') /*  8  8-bit palette */
 #define V4L2_PIX_FMT_YVU410  v4l2_fourcc('Y','V','U','9') /*  9  YVU 4:1:0     */
 #define V4L2_PIX_FMT_YVU420  v4l2_fourcc('Y','V','1','2') /* 12  YVU 4:2:0     */
@@ -307,6 +308,7 @@ struct v4l2_pix_format
 
 /* see http://www.siliconimaging.com/RGB%20Bayer.htm */
 #define V4L2_PIX_FMT_SBGGR8  v4l2_fourcc('B','A','8','1') /*  8  BGBG.. GRGR.. */
+#define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B','Y','R','2') /* 16  BGBG.. GRGR.. */
 
 /* compressed formats */
 #define V4L2_PIX_FMT_MJPEG    v4l2_fourcc('M','J','P','G') /* Motion-JPEG   */
@@ -862,7 +864,8 @@ struct v4l2_querymenu
 #define V4L2_CID_VFLIP			(V4L2_CID_BASE+21)
 #define V4L2_CID_HCENTER		(V4L2_CID_BASE+22)
 #define V4L2_CID_VCENTER		(V4L2_CID_BASE+23)
-#define V4L2_CID_LASTP1			(V4L2_CID_BASE+24) /* last CID + 1 */
+#define V4L2_CID_AUTOEXPOSURE		(V4L2_CID_BASE+24)
+#define V4L2_CID_LASTP1			(V4L2_CID_BASE+25) /* last CID + 1 */
 
 /*  MPEG-class control IDs defined by V4L2 */
 #define V4L2_CID_MPEG_BASE 			(V4L2_CTRL_CLASS_MPEG | 0x900)
--- a/mailimport	Sun Jan 27 17:24:26 2008 +0000
+++ b/mailimport	Mon Feb 04 16:32:42 2008 -0200
@@ -224,6 +224,10 @@ if [ -d "$NAME" ]; then
 	else
 		echo "Processing patches from tree $NAME"
 		for i in $NAME/*; do
+			if [ ! -r $i ]; then
+				sudo chmod og+r $i
+			fi
+
 			echo "$i"
 			proccess_patch "$i"
 		done

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Guennadi Liakhovetski]

On Mon, 4 Feb 2008, Brandon Philips wrote:

> On 15:31 Thu 31 Jan 2008, Guennadi Liakhovetski wrote:
> > From: Steven Whitehouse <steve@chygwyn.com>
> > 
> > This adds two new fourcc codes (as per info at fourcc.org)
> > for 16bpp mono and 16bpp Bayer formats.
> 
> This patch was merged in the following commit:
>  http://linuxtv.org/hg/v4l-dvb/rev/d002378ff8c2
> 
> I have a number of issues:
>  
> - Why was V4L2_CID_AUTOEXPOSURE added!  I am working to get an auto
>   exposure control into the spec but this was merged without discussion.
>   Please remove this and wait for my patch.
> 
> - Why was a SoC config option added with this commit?
> 
> - mailimport changes in this commit too!  Why is mailimport running
>   sudo!?! 
> 
> A mistake was obviously made here.

Yes, strange. In the original patch

http://marc.info/?l=linux-video&m=120179045830566&w=2

it was still ok.

Thanks
Guennadi

> 
> 	Brandon
> 
> 
> --- a/linux/drivers/media/video/Kconfig	Sun Jan 27 17:24:26 2008 +0000
> +++ b/linux/drivers/media/video/Kconfig	Mon Feb 04 16:32:42 2008 -0200
> @@ -836,4 +836,13 @@ config USB_STKWEBCAM
>  
>  endif # V4L_USB_DRIVERS
>  
> +config SOC_CAMERA
> +	tristate "SoC camera support"
> +	depends on VIDEO_V4L2
> +	select VIDEOBUF_DMA_SG
> +	help
> +	  SoC Camera is a common API to several cameras, not connecting
> +	  over a bus like PCI or USB. For example some i2c camera connected
> +	  directly to the data bus of an SoC.
> +
>  endif # VIDEO_CAPTURE_DRIVERS
> --- a/linux/include/linux/videodev2.h	Sun Jan 27 17:24:26 2008 +0000
> +++ b/linux/include/linux/videodev2.h	Mon Feb 04 16:32:42 2008 -0200
> @@ -281,6 +281,7 @@ struct v4l2_pix_format
>  #define V4L2_PIX_FMT_BGR32   v4l2_fourcc('B','G','R','4') /* 32  BGR-8-8-8-8   */
>  #define V4L2_PIX_FMT_RGB32   v4l2_fourcc('R','G','B','4') /* 32  RGB-8-8-8-8   */
>  #define V4L2_PIX_FMT_GREY    v4l2_fourcc('G','R','E','Y') /*  8  Greyscale     */
> +#define V4L2_PIX_FMT_Y16     v4l2_fourcc('Y','1','6',' ') /* 16  Greyscale     */
>  #define V4L2_PIX_FMT_PAL8    v4l2_fourcc('P','A','L','8') /*  8  8-bit palette */
>  #define V4L2_PIX_FMT_YVU410  v4l2_fourcc('Y','V','U','9') /*  9  YVU 4:1:0     */
>  #define V4L2_PIX_FMT_YVU420  v4l2_fourcc('Y','V','1','2') /* 12  YVU 4:2:0     */
> @@ -307,6 +308,7 @@ struct v4l2_pix_format
>  
>  /* see http://www.siliconimaging.com/RGB%20Bayer.htm */
>  #define V4L2_PIX_FMT_SBGGR8  v4l2_fourcc('B','A','8','1') /*  8  BGBG.. GRGR.. */
> +#define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B','Y','R','2') /* 16  BGBG.. GRGR.. */
>  
>  /* compressed formats */
>  #define V4L2_PIX_FMT_MJPEG    v4l2_fourcc('M','J','P','G') /* Motion-JPEG   */
> @@ -862,7 +864,8 @@ struct v4l2_querymenu
>  #define V4L2_CID_VFLIP			(V4L2_CID_BASE+21)
>  #define V4L2_CID_HCENTER		(V4L2_CID_BASE+22)
>  #define V4L2_CID_VCENTER		(V4L2_CID_BASE+23)
> -#define V4L2_CID_LASTP1			(V4L2_CID_BASE+24) /* last CID + 1 */
> +#define V4L2_CID_AUTOEXPOSURE		(V4L2_CID_BASE+24)
> +#define V4L2_CID_LASTP1			(V4L2_CID_BASE+25) /* last CID + 1 */
>  
>  /*  MPEG-class control IDs defined by V4L2 */
>  #define V4L2_CID_MPEG_BASE 			(V4L2_CTRL_CLASS_MPEG | 0x900)
> --- a/mailimport	Sun Jan 27 17:24:26 2008 +0000
> +++ b/mailimport	Mon Feb 04 16:32:42 2008 -0200
> @@ -224,6 +224,10 @@ if [ -d "$NAME" ]; then
>  	else
>  		echo "Processing patches from tree $NAME"
>  		for i in $NAME/*; do
> +			if [ ! -r $i ]; then
> +				sudo chmod og+r $i
> +			fi
> +
>  			echo "$i"
>  			proccess_patch "$i"
>  		done
> 

---
Guennadi Liakhovetski

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Brandon Philips]

On 08:16 Tue 05 Feb 2008, Guennadi Liakhovetski wrote:
> On Mon, 4 Feb 2008, Brandon Philips wrote:
> 
> > On 15:31 Thu 31 Jan 2008, Guennadi Liakhovetski wrote:
> > > From: Steven Whitehouse <steve@chygwyn.com>
> > > 
> > > This adds two new fourcc codes (as per info at fourcc.org)
> > > for 16bpp mono and 16bpp Bayer formats.
> > 
> > This patch was merged in the following commit:
> >  http://linuxtv.org/hg/v4l-dvb/rev/d002378ff8c2
> > 
> > I have a number of issues:
> >  
> > - Why was V4L2_CID_AUTOEXPOSURE added!  I am working to get an auto
> >   exposure control into the spec but this was merged without discussion.
> >   Please remove this and wait for my patch.
> > 
> > - Why was a SoC config option added with this commit?
> > 
> > - mailimport changes in this commit too!  Why is mailimport running
> >   sudo!?! 
> > 
> > A mistake was obviously made here.
> 
> Yes, strange. In the original patch
> 
> http://marc.info/?l=linux-video&m=120179045830566&w=2
> 
> it was still ok.

Yea, it must have been something on Mauro's end.

Thanks,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Mauro Carvalho Chehab]

On Tue, 5 Feb 2008 00:00:38 -0800
Brandon Philips <brandon@ifup.org> wrote:

> On 08:16 Tue 05 Feb 2008, Guennadi Liakhovetski wrote:
> > On Mon, 4 Feb 2008, Brandon Philips wrote:
> > 
> > > On 15:31 Thu 31 Jan 2008, Guennadi Liakhovetski wrote:
> > > > From: Steven Whitehouse <steve@chygwyn.com>
> > > > 
> > > > This adds two new fourcc codes (as per info at fourcc.org)
> > > > for 16bpp mono and 16bpp Bayer formats.
> > > 
> > > This patch was merged in the following commit:
> > >  http://linuxtv.org/hg/v4l-dvb/rev/d002378ff8c2
> > > 
> > > I have a number of issues:
> > >  
> > > - Why was V4L2_CID_AUTOEXPOSURE added!  I am working to get an auto
> > >   exposure control into the spec but this was merged without discussion.
> > >   Please remove this and wait for my patch.
> > > 
> > > - Why was a SoC config option added with this commit?
> > > 
> > > - mailimport changes in this commit too!  Why is mailimport running
> > >   sudo!?! 
> > > 
> > > A mistake was obviously made here.
> > 
> > Yes, strange. In the original patch
> > 
> > http://marc.info/?l=linux-video&m=120179045830566&w=2
> > 
> > it was still ok.
> 
> Yea, it must have been something on Mauro's end.

Yes. It was a silly mistake from my side... I'll revert soon. I'm currently
backporting kernel changes.

I should be using a separate tree for testing newer changesets. Unfortunately,
mercurial spends a large amount of disk space when you fork a tree, since it
doesn't support versioning, and the 160Gb disk on my notebook is almost full
with lots and lots of mercurial branches :( So, sometimes, bad things happen.

Maybe we've took the wrong direction when we've decided to select
mercurial. It were better and easier to use, on that time, but the -git
improvements happened too fast.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Michael Krufky]

Brandon Philips wrote:
> - mailimport changes in this commit too!  Why is mailimport running
>   sudo!?! 

I understand that unrelated changes were accidentally merged with a single commit, but why would we want this script to call sudo in the first place?

I think it's bad practice, for such a script to execute commands as root -- 

Can you explain, Mauro?

Regards,

-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Mauro Carvalho Chehab]

On Tue, 05 Feb 2008 08:23:28 -0500
Michael Krufky <mkrufky@linuxtv.org> wrote:

> Brandon Philips wrote:
> > - mailimport changes in this commit too!  Why is mailimport running
> >   sudo!?! 
> 
> I understand that unrelated changes were accidentally merged with a single commit, but why would we want this script to call sudo in the first place?
> 
> I think it's bad practice, for such a script to execute commands as root -- 
> 
> Can you explain, Mauro?

The script itself doesn't open any new vulnerabilities. Sudo only works if 
configured at /etc/sudoers.

This is needed for the script to work on certain configurations. 
Some emailers marks mailboxes and messages with "og-rw" permissions.
This means that other users can't access. If someone uses a different user
account for V4L/DVB development/testing, permissions should be changed, when
applying a patch series received by email.

Of course, this will only work if:

1) the user of the second account has sudo rights;

2) the user of the second account types his password (or, otherwise, sudo is
configured to not ask for passwords - on very weak environments).

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Brandon Philips]

On 12:01 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> On Tue, 05 Feb 2008 08:23:28 -0500
> Michael Krufky <mkrufky@linuxtv.org> wrote:
> 
> > Brandon Philips wrote:
> > > - mailimport changes in this commit too!  Why is mailimport running
> > >   sudo!?! 
> > 
> > I understand that unrelated changes were accidentally merged with a single commit, but why would we want this script to call sudo in the first place?
> > 
> > I think it's bad practice, for such a script to execute commands as root -- 
> > 
> > Can you explain, Mauro?
> 
> The script itself doesn't open any new vulnerabilities. Sudo only works if 
> configured at /etc/sudoers.

I don't use the script but I would certainly remove the sudo calls in my
local version if I started to.  A patch tool really shouldn't need sudo.
If the perms are wrong the user can write a wrapper script to fix them.

> 2) the user of the second account types his password (or, otherwise, sudo is
> configured to not ask for passwords - on very weak environments).

sudo defaults to a 15 grace period where it doesn't ask for a password
again.

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: NACK NACK! [PATCH] Add two new fourcc codes for 16bpp formats

[Michael Krufky]

Brandon Philips wrote:
> On 12:01 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
>> On Tue, 05 Feb 2008 08:23:28 -0500
>> Michael Krufky <mkrufky@linuxtv.org> wrote:
>>
>>> Brandon Philips wrote:
>>>> - mailimport changes in this commit too!  Why is mailimport running
>>>>   sudo!?! 
>>> I understand that unrelated changes were accidentally merged with a single commit, but why would we want this script to call sudo in the first place?
>>>
>>> I think it's bad practice, for such a script to execute commands as root -- 
>>>
>>> Can you explain, Mauro?
>> The script itself doesn't open any new vulnerabilities. Sudo only works if 
>> configured at /etc/sudoers.
> 
> I don't use the script but I would certainly remove the sudo calls in my
> local version if I started to.  A patch tool really shouldn't need sudo.
> If the perms are wrong the user can write a wrapper script to fix them.
> 
>> 2) the user of the second account types his password (or, otherwise, sudo is
>> configured to not ask for passwords - on very weak environments).
> 
> sudo defaults to a 15 grace period where it doesn't ask for a password
> again.


I agree with Brandon -- I think the use of sudo here is entirely inappropriate, and there are clearly other ways that a user can address file ownership / permissions issues without this.

-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Michael Krufky]

On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
> On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> > Maybe we've took the wrong direction when we've decided to select
> > mercurial. It were better and easier to use, on that time, but the -git
> > improvements happened too fast.
>
> We should consider a move to a full-tree git.  Particularly, it would be
> nice to be have v4l-dvb merging/building against other subsystems in the
> linux-next tree:
>
>   http://lkml.org/lkml/2008/2/11/512
>
> Also, it would save the silly pain of things like this meye.h thing and
> pulling in fixes from the rest of the community that patches against git
> trees.


When we moved from CVS to HG, we lost many developers.

Of the developers that remain, most of us are finally comfortable
working in mercurial.

I understand the benefits of moving to git, but that option was on the
table when we moved to mercurial from cvs, and it was shot down.

I would prefer that we stick with what we have for now -- for the sake
of our users / testers, and for the sake of our developers.

Lets not drive away more contributors.

Additionally, the moment we move development from hg to git, we are
bound to the development kernel -- we will no longer be able to work
against any stable kernel series, and we will lose all of our testers.

v4l/dvb is a bit different from kernel development of other
subsystems, in that we work on drivers for new devices.  Users will
not want to upgrade an entire kernel, let alone build that entire
kernel themselves, just so they can get new device support.  We will
quickly notice that users will be less daring to buy new hardware, and
will start buying older hardware known to have stable linux support.

As much as I wanted us all to use git back when we were discussing the
SCM move a few years ago, I am entirely against it right now.

Regards,

Mike Krufky

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Alex Deucher]

On Feb 13, 2008 6:24 PM, Michael Krufky <mkrufky@linuxtv.org> wrote:
> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
> > On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> > > Maybe we've took the wrong direction when we've decided to select
> > > mercurial. It were better and easier to use, on that time, but the -git
> > > improvements happened too fast.
> >
> > We should consider a move to a full-tree git.  Particularly, it would be
> > nice to be have v4l-dvb merging/building against other subsystems in the
> > linux-next tree:
> >
> >   http://lkml.org/lkml/2008/2/11/512
> >
> > Also, it would save the silly pain of things like this meye.h thing and
> > pulling in fixes from the rest of the community that patches against git
> > trees.
>
>
> When we moved from CVS to HG, we lost many developers.
>
> Of the developers that remain, most of us are finally comfortable
> working in mercurial.
>
> I understand the benefits of moving to git, but that option was on the
> table when we moved to mercurial from cvs, and it was shot down.
>
> I would prefer that we stick with what we have for now -- for the sake
> of our users / testers, and for the sake of our developers.
>
> Lets not drive away more contributors.
>
> Additionally, the moment we move development from hg to git, we are
> bound to the development kernel -- we will no longer be able to work
> against any stable kernel series, and we will lose all of our testers.

Why would git have any affect on what kernels you could test against?
It's just an scm like hg or cvs.

Alex

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[hermann pitton]

Am Mittwoch, den 13.02.2008, 18:24 -0500 schrieb Michael Krufky:
> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
> > On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> > > Maybe we've took the wrong direction when we've decided to select
> > > mercurial. It were better and easier to use, on that time, but the -git
> > > improvements happened too fast.
> >
> > We should consider a move to a full-tree git.  Particularly, it would be
> > nice to be have v4l-dvb merging/building against other subsystems in the
> > linux-next tree:
> >
> >   http://lkml.org/lkml/2008/2/11/512
> >
> > Also, it would save the silly pain of things like this meye.h thing and
> > pulling in fixes from the rest of the community that patches against git
> > trees.
> 
> 
> When we moved from CVS to HG, we lost many developers.
> 
> Of the developers that remain, most of us are finally comfortable
> working in mercurial.
> 
> I understand the benefits of moving to git, but that option was on the
> table when we moved to mercurial from cvs, and it was shot down.
> 
> I would prefer that we stick with what we have for now -- for the sake
> of our users / testers, and for the sake of our developers.
> 
> Lets not drive away more contributors.
> 
> Additionally, the moment we move development from hg to git, we are
> bound to the development kernel -- we will no longer be able to work
> against any stable kernel series, and we will lose all of our testers.
> 
> v4l/dvb is a bit different from kernel development of other
> subsystems, in that we work on drivers for new devices.  Users will
> not want to upgrade an entire kernel, let alone build that entire
> kernel themselves, just so they can get new device support.  We will
> quickly notice that users will be less daring to buy new hardware, and
> will start buying older hardware known to have stable linux support.
> 
> As much as I wanted us all to use git back when we were discussing the
> SCM move a few years ago, I am entirely against it right now.
> 
> Regards,
> 
> Mike Krufky
> 

Mike,

I totally agree with you.

All the work invested in the build system to attract more testers did
not help us to keep some basic community for testing.

For that, we are not better off as when Gerd and some inclined enough
fought for every tester. I stated already, that it looks like we have to
buy all new cards soon on our own budget, despite of what we have done.

The current checkpatch.pl hysteria on decades old code does the rest..

Cheers,
Hermann





--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Michael Krufky]

Alex Deucher wrote:
> On Feb 13, 2008 6:24 PM, Michael Krufky <mkrufky@linuxtv.org> wrote:
>> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
>>> On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
>>>> Maybe we've took the wrong direction when we've decided to select
>>>> mercurial. It were better and easier to use, on that time, but the -git
>>>> improvements happened too fast.
>>> We should consider a move to a full-tree git.  Particularly, it would be
>>> nice to be have v4l-dvb merging/building against other subsystems in the
>>> linux-next tree:
>>>
>>>   http://lkml.org/lkml/2008/2/11/512
>>>
>>> Also, it would save the silly pain of things like this meye.h thing and
>>> pulling in fixes from the rest of the community that patches against git
>>> trees.
>>
>> When we moved from CVS to HG, we lost many developers.
>>
>> Of the developers that remain, most of us are finally comfortable
>> working in mercurial.
>>
>> I understand the benefits of moving to git, but that option was on the
>> table when we moved to mercurial from cvs, and it was shot down.
>>
>> I would prefer that we stick with what we have for now -- for the sake
>> of our users / testers, and for the sake of our developers.
>>
>> Lets not drive away more contributors.
>>
>> Additionally, the moment we move development from hg to git, we are
>> bound to the development kernel -- we will no longer be able to work
>> against any stable kernel series, and we will lose all of our testers.
> 
> Why would git have any affect on what kernels you could test against?
> It's just an scm like hg or cvs.

Alex,

You are correct.  However, it is not just the SCM in question right now.

Quoting Brandon Philips, "We should consider a move to a full-tree git"

...he is not suggesting that we simply change SCM's -- rather, he is suggesting that we work within a full kernel tree, using git, just as the other subsystems do.

This model makes sense for kernel development, but this is not exactly kernel development -- it is kernel *driver* development.

We stand to lose too much by moving to this model.

Regards,

Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Brandon Philips]

On 18:24 Wed 13 Feb 2008, Michael Krufky wrote:
> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
> > On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> > > Maybe we've took the wrong direction when we've decided to select
> > > mercurial. It were better and easier to use, on that time, but the -git
> > > improvements happened too fast.
> >
> > We should consider a move to a full-tree git.  Particularly, it would be
> > nice to be have v4l-dvb merging/building against other subsystems in the
> > linux-next tree:
> >
> >   http://lkml.org/lkml/2008/2/11/512
> >
> > Also, it would save the silly pain of things like this meye.h thing and
> > pulling in fixes from the rest of the community that patches against git
> > trees.
> 
> Additionally, the moment we move development from hg to git, we are
> bound to the development kernel -- we will no longer be able to work
> against any stable kernel series, and we will lose all of our testers.

Good point.  Testers seem pretty happy with our current system.

I will look into auto-generating a full git tree from the hg v4l-dvb
repo.  That way we can participate in linux-next while still using
mercurial for development.

Cheers,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Michael Krufky]

Brandon Philips wrote:
> On 18:24 Wed 13 Feb 2008, Michael Krufky wrote:
>   
>> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
>>     
>>> On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
>>>       
>>>> Maybe we've took the wrong direction when we've decided to select
>>>> mercurial. It were better and easier to use, on that time, but the -git
>>>> improvements happened too fast.
>>>>         
>>> We should consider a move to a full-tree git.  Particularly, it would be
>>> nice to be have v4l-dvb merging/building against other subsystems in the
>>> linux-next tree:
>>>
>>>   http://lkml.org/lkml/2008/2/11/512
>>>
>>> Also, it would save the silly pain of things like this meye.h thing and
>>> pulling in fixes from the rest of the community that patches against git
>>> trees.
>>>       
>> Additionally, the moment we move development from hg to git, we are
>> bound to the development kernel -- we will no longer be able to work
>> against any stable kernel series, and we will lose all of our testers.
>>     
>
> Good point.  Testers seem pretty happy with our current system.
>
> I will look into auto-generating a full git tree from the hg v4l-dvb
> repo.  That way we can participate in linux-next while still using
> mercurial for development.

I like that *much* better -- good idea!

-Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 13 Feb 2008 21:35:37 -0500
Michael Krufky <mkrufky@linuxtv.org> wrote:

> Brandon Philips wrote:
> > On 18:24 Wed 13 Feb 2008, Michael Krufky wrote:
> >   
> >> On Feb 13, 2008 3:20 PM, Brandon Philips <bphilips@suse.de> wrote:
> >>     
> >>> On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> >>>       
> >>>> Maybe we've took the wrong direction when we've decided to select
> >>>> mercurial. It were better and easier to use, on that time, but the -git
> >>>> improvements happened too fast.
> >>>>         
> >>> We should consider a move to a full-tree git.  Particularly, it would be
> >>> nice to be have v4l-dvb merging/building against other subsystems in the
> >>> linux-next tree:
> >>>
> >>>   http://lkml.org/lkml/2008/2/11/512
> >>>
> >>> Also, it would save the silly pain of things like this meye.h thing and
> >>> pulling in fixes from the rest of the community that patches against git
> >>> trees.
> >>>       
> >> Additionally, the moment we move development from hg to git, we are
> >> bound to the development kernel -- we will no longer be able to work
> >> against any stable kernel series, and we will lose all of our testers.
> >>     
> >
> > Good point.  Testers seem pretty happy with our current system.
> >
> > I will look into auto-generating a full git tree from the hg v4l-dvb
> > repo.  That way we can participate in linux-next while still using
> > mercurial for development.

We do have a full git tree. I don't understand what you're meaning. This tree
is generated by script (although I prefer to generate it manually, it shouldn't
be hard to automate it).
> 
> I like that *much* better -- good idea!
> 
> -Mike




Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 13 Feb 2008 12:20:55 -0800
Brandon Philips <bphilips@suse.de> wrote:

> On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> > Maybe we've took the wrong direction when we've decided to select
> > mercurial. It were better and easier to use, on that time, but the -git
> > improvements happened too fast.
> 
> We should consider a move to a full-tree git.  Particularly, it would be
> nice to be have v4l-dvb merging/building against other subsystems in the
> linux-next tree:
> 
>   http://lkml.org/lkml/2008/2/11/512
> 
> Also, it would save the silly pain of things like this meye.h thing and
> pulling in fixes from the rest of the community that patches against git
> trees.

Just a few personal notes about my comment about git x hg and your request:

There are two separate things to discuss.

One is the SCM used by v4l/dvb. 

>From my personal experience with both, -git is currently much more advanced
than -hg. Git suffered lots of newer updates and feature additions, while hg
still didn't arise version 1.0 (the original plan from the developers were to
release version 1.0 in 2005, if my memories are not failing). 

AFAIK, Mercurial still lacks branches and a proper way to clone a tree without
needing to copy all files to the newer copy. This means that having lots of
repositories will mean to spend a large amount of disk space.

On the other hand, you can clone a git, with '-l' option. The common patches
won't be cloned, resulting on a very small repository.

Also, -git tree-way merge is much better than the way mercurial deals with.

-git trees have two different meta-tags to represent the tree owner _and_ the
patch author. A patch can be committed by a maintainer, preserving author's
ownership. On Mercurial, there's only one meta-tag. So, each developer needs to
manually add a line with:
	From: someone <some@email>
To represent the missing authorship. I need some scripts to convert this "From"
artificial field into an Author, before generating the -git.

Another point on -hg is that adding a SOB on a patch will change its MD5.
Mercurial will start to think that the patch with SOB is different from the one
without. The practical result of this is that SOB's can't be applied on trees
that are cloned. This affects mostly v4l-dvb tree, but also may cause some harm
if there are two developers working at the same code, collaborating one with the
other, and both adding SOB/reviewed-by. That's why the official master tree is
our kernelstyle -git: it is the only tree were I can safely add SOB (including
the maintainers's ones), reviewed-by, fix missing authorships, etc.

Lastly, on -git, _every_ merge produces a log. So, it is very easy to backtrack
tree merges. On mercurial, a merge commit happens only when the developer's
tree is not based against tip. So, you can't safely track if a patch were
merged from another tree, or if the patch came from email, committed by the
tree maintainer.

Technically, it would be possible to migrate to -git, preserving the way our
repository is built.

Yet, I don't believe that the gains would be enough to compensate the amount of
effort from all to develop and learn new procedures for their usage.

-

The other issue is to abandon our building system and just use -git.

This will likely cause a lack of users for testing the patchsets. This doesn't
seem to be a good idea.

-

So, I don't think we should move from -hg to -git.

-

About linux-next, this is really a good idea. I've already implemented a
linux-next -git tree for v4l-dvb. This tree is generated at the same time I
generate the master -git. Since I update this often, I think this will work
properly.

Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Brandon Philips]

On 17:46 Thu 14 Feb 2008, Mauro Carvalho Chehab wrote:
> On Wed, 13 Feb 2008 12:20:55 -0800
> Brandon Philips <bphilips@suse.de> wrote:
> 
> > On 10:24 Tue 05 Feb 2008, Mauro Carvalho Chehab wrote:
> > > Maybe we've took the wrong direction when we've decided to select
> > > mercurial. It were better and easier to use, on that time, but the -git
> > > improvements happened too fast.
> > 
> > We should consider a move to a full-tree git.  Particularly, it would be
> > nice to be have v4l-dvb merging/building against other subsystems in the
> > linux-next tree:
> > 
> >   http://lkml.org/lkml/2008/2/11/512
> > 
> > Also, it would save the silly pain of things like this meye.h thing and
> > pulling in fixes from the rest of the community that patches against git
> > trees.
> About linux-next, this is really a good idea. I've already implemented a
> linux-next -git tree for v4l-dvb. This tree is generated at the same time I
> generate the master -git. Since I update this often, I think this will work
> properly.

Great.  It should be interesting to see what happens with linux-next.

Cheers,

	Brandon

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Guennadi Liakhovetski]

Sorry for reviving this almost-a-year-old thread, but after my last 
failure to formst hg-commits correctly, I'd like to have this clarified 
before causing Mauro extra manual editing of my commits again.

On Thu, 14 Feb 2008, Mauro Carvalho Chehab wrote:

[snip]

> -git trees have two different meta-tags to represent the tree owner _and_ the
> patch author. A patch can be committed by a maintainer, preserving author's
> ownership. On Mercurial, there's only one meta-tag. So, each developer needs to
> manually add a line with:
> 	From: someone <some@email>
> To represent the missing authorship. I need some scripts to convert this "From"
> artificial field into an Author, before generating the -git.

later

On Tue, 22 Apr 2008, Mauro Carvalho Chehab wrote:

> In general, you ask me to pull a patch series with yours and also third part
> patches. Please, be sure to add a "From: " line at the patch, since Mercurial
> has no meta-tag to indicate patch authorship. The only meta tag for someone is
> "user". We use this meta-tag to help tracking from what tree a changeset were 
> merged.

and recently

On Mon, 8 Dec 2008, Mauro Carvalho Chehab wrote:

> On -git, you have two different fields: the committer and the patch author.
> Since mercurial has just one field, we should take some care, since, depending
> on the way you import things into mercurial, you may lead to bad author
> attribution.
> 
> To avoid this risk, we've added an extra tag on all mercurial commits. Also, my
> -git import scripts don't automatically merge any patch that comes without the 
> "from" field. Those patches require manual work to forward. This way, I have a 
> double check procedure there.

So, what should a patch header look like to be imported into hg per "hg 
import" for later push to linuxtv to be pulled by Mauro?

Looks like it should have two "From: " lines - one will be used by hg for 
the user field and should contain my address, the second "From: " line 
should contain the actual patch author? All quotes above mention only one 
"From: ", and this is what a git-format-patch produces, but it looks like 
this single "From: " is then consumed by hg to form its "user" field, so 
nothing is left for a subsequent re-export to git.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Michael Krufky]

Guennadi Liakhovetski wrote:
> Sorry for reviving this almost-a-year-old thread, but after my last 
> failure to formst hg-commits correctly, I'd like to have this clarified 
> before causing Mauro extra manual editing of my commits again.
>
> On Thu, 14 Feb 2008, Mauro Carvalho Chehab wrote:
>
> [snip]
>
>   
>> -git trees have two different meta-tags to represent the tree owner _and_ the
>> patch author. A patch can be committed by a maintainer, preserving author's
>> ownership. On Mercurial, there's only one meta-tag. So, each developer needs to
>> manually add a line with:
>> 	From: someone <some@email>
>> To represent the missing authorship. I need some scripts to convert this "From"
>> artificial field into an Author, before generating the -git.
>>     
>
> later
>
> On Tue, 22 Apr 2008, Mauro Carvalho Chehab wrote:
>
>   
>> In general, you ask me to pull a patch series with yours and also third part
>> patches. Please, be sure to add a "From: " line at the patch, since Mercurial
>> has no meta-tag to indicate patch authorship. The only meta tag for someone is
>> "user". We use this meta-tag to help tracking from what tree a changeset were 
>> merged.
>>     
>
> and recently
>
> On Mon, 8 Dec 2008, Mauro Carvalho Chehab wrote:
>
>   
>> On -git, you have two different fields: the committer and the patch author.
>> Since mercurial has just one field, we should take some care, since, depending
>> on the way you import things into mercurial, you may lead to bad author
>> attribution.
>>
>> To avoid this risk, we've added an extra tag on all mercurial commits. Also, my
>> -git import scripts don't automatically merge any patch that comes without the 
>> "from" field. Those patches require manual work to forward. This way, I have a 
>> double check procedure there.
>>     
>
> So, what should a patch header look like to be imported into hg per "hg 
> import" for later push to linuxtv to be pulled by Mauro?
>
> Looks like it should have two "From: " lines - one will be used by hg for 
> the user field and should contain my address, the second "From: " line 
> should contain the actual patch author? All quotes above mention only one 
> "From: ", and this is what a git-format-patch produces, but it looks like 
> this single "From: " is then consumed by hg to form its "user" field, so 
> nothing is left for a subsequent re-export to git.
>
> Thanks
> Guennadi
>
>   

Guennadi,

Please take a look at one of the hg patches within the repository:

http://linuxtv.org/hg/v4l-dvb/raw-rev/3cc7daa31234

This patch is the same type of output that you would get from using "hg export 3cc7daa31234"

Notice the "From:" line -- that line is used to indicate author.

Notice the "User" line (line 2) -- that line is used to indicate committer.

Does that help to clear it up for you?

Regards,

Mike

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Guennadi Liakhovetski]

On Wed, 17 Dec 2008, Michael Krufky wrote:

> Please take a look at one of the hg patches within the repository:
> 
> http://linuxtv.org/hg/v4l-dvb/raw-rev/3cc7daa31234
> 
> This patch is the same type of output that you would get from using "hg export
> 3cc7daa31234"
> 
> Notice the "From:" line -- that line is used to indicate author.
> 
> Notice the "User" line (line 2) -- that line is used to indicate committer.
> 
> Does that help to clear it up for you?

Maybe... So, if I take a patch produced by git-format-patch, and add a 
line at the top like

# User myname <myaddress@myprovider.com>

and then "hg import" this patch, then this line will be used by hg for the 
"user" field and the "From: " line that git produced will be kept... emn 
no, it will not, because it belongs to the header. But ok, I think, I know 
what should be done. I'll just move the "From: " from the header to below 
the "Subject: ", and, optionally add one more "# User " or "From: " for 
the user... uhhh...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 17 Dec 2008, Guennadi Liakhovetski wrote:

> On Wed, 17 Dec 2008, Michael Krufky wrote:
>
>> Please take a look at one of the hg patches within the repository:
>>
>> http://linuxtv.org/hg/v4l-dvb/raw-rev/3cc7daa31234
>>
>> This patch is the same type of output that you would get from using "hg export
>> 3cc7daa31234"
>>
>> Notice the "From:" line -- that line is used to indicate author.
>>
>> Notice the "User" line (line 2) -- that line is used to indicate committer.
>>
>> Does that help to clear it up for you?
>
> Maybe... So, if I take a patch produced by git-format-patch, and add a
> line at the top like
>
> # User myname <myaddress@myprovider.com>
>
> and then "hg import" this patch, then this line will be used by hg for the
> "user" field and the "From: " line that git produced will be kept... emn
> no, it will not, because it belongs to the header. But ok, I think, I know
> what should be done. I'll just move the "From: " from the header to below
> the "Subject: ", and, optionally add one more "# User " or "From: " for
> the user... uhhh...

I use here a simpler procedure to retrieve patches from other file 
systems. Instead of doing "hg import <patch>", I use:

./mailimport <patch>

The mailimport script do the proper patch import, and also allows you to 
review the patch before committing.

-- 
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
mchehab@infradead.org

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Guennadi Liakhovetski]

On Wed, 17 Dec 2008, Mauro Carvalho Chehab wrote:

> On Wed, 17 Dec 2008, Guennadi Liakhovetski wrote:
> 
> > Maybe... So, if I take a patch produced by git-format-patch, and add a
> > line at the top like
> > 
> > # User myname <myaddress@myprovider.com>
> > 
> > and then "hg import" this patch, then this line will be used by hg for the
> > "user" field and the "From: " line that git produced will be kept... emn
> > no, it will not, because it belongs to the header. But ok, I think, I know
> > what should be done. I'll just move the "From: " from the header to below
> > the "Subject: ", and, optionally add one more "# User " or "From: " for
> > the user... uhhh...
> 
> I use here a simpler procedure to retrieve patches from other file systems.
> Instead of doing "hg import <patch>", I use:
> 
> ./mailimport <patch>
> 
> The mailimport script do the proper patch import, and also allows you to
> review the patch before committing.

and in which form does the patch have to be when using mailimport? Would 
output from git-format-patch suit?

In the meantime here's an example of what my self-baked script produces 
(after "hg import" as seen per "hg export"):

# HG changeset patch
# User Guennadi Liakhovetski <g.liakhovetski@gmx.de>
# Date 1229533267 -3600
# Node ID 3fd17fb56af0a556ab85509fb50956a477b14916
# Parent  3cc7daa31234ca3c9bd0a58eb825f61499a65826
mt9m111: mt9m111_get_global_gain() - unsigned >= 0 is always true
From: roel kluin <roel.kluin@gmail.com>

unsigned >= 0 is always true and fix formula

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 drivers/media/video/mt9m111.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff -r 3cc7daa31234 -r 3fd17fb56af0 linux/drivers/media/video/mt9m111.c
--- a/linux/drivers/media/video/mt9m111.c       Tue Dec 16 23:04:56 2008 -0200
+++ b/linux/drivers/media/video/mt9m111.c       Wed Dec 17 18:01:07 2008 +0100
@@ -634,18 +634,15 @@ static int mt9m111_set_flip(struct soc_c
...

Should work, right?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: [v4l-dvb-maintainer] Moving to git for v4l-dvb

[Mauro Carvalho Chehab]

On Wed, 17 Dec 2008, Guennadi Liakhovetski wrote:

> On Wed, 17 Dec 2008, Mauro Carvalho Chehab wrote:
>
>> On Wed, 17 Dec 2008, Guennadi Liakhovetski wrote:
>>
>>> Maybe... So, if I take a patch produced by git-format-patch, and add a
>>> line at the top like
>>>
>>> # User myname <myaddress@myprovider.com>
>>>
>>> and then "hg import" this patch, then this line will be used by hg for the
>>> "user" field and the "From: " line that git produced will be kept... emn
>>> no, it will not, because it belongs to the header. But ok, I think, I know
>>> what should be done. I'll just move the "From: " from the header to below
>>> the "Subject: ", and, optionally add one more "# User " or "From: " for
>>> the user... uhhh...
>>
>> I use here a simpler procedure to retrieve patches from other file systems.
>> Instead of doing "hg import <patch>", I use:
>>
>> ./mailimport <patch>
>>
>> The mailimport script do the proper patch import, and also allows you to
>> review the patch before committing.
>
> and in which form does the patch have to be when using mailimport? Would
> output from git-format-patch suit?

I made it to accept several common formats, including -git and also akpm 
posts for -mm series.
>
> In the meantime here's an example of what my self-baked script produces
> (after "hg import" as seen per "hg export"):
>
> # HG changeset patch
> # User Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> # Date 1229533267 -3600
> # Node ID 3fd17fb56af0a556ab85509fb50956a477b14916
> # Parent  3cc7daa31234ca3c9bd0a58eb825f61499a65826
> mt9m111: mt9m111_get_global_gain() - unsigned >= 0 is always true
> From: roel kluin <roel.kluin@gmail.com>
>
> unsigned >= 0 is always true and fix formula
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> drivers/media/video/mt9m111.c |   13 +++++--------
> 1 files changed, 5 insertions(+), 8 deletions(-)
>
> diff -r 3cc7daa31234 -r 3fd17fb56af0 linux/drivers/media/video/mt9m111.c
> --- a/linux/drivers/media/video/mt9m111.c       Tue Dec 16 23:04:56 2008 -0200
> +++ b/linux/drivers/media/video/mt9m111.c       Wed Dec 17 18:01:07 2008 +0100
> @@ -634,18 +634,15 @@ static int mt9m111_set_flip(struct soc_c
> ...
>
> Should work, right?

Should work. We generally add a space after the first line and From:

-- 
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
mchehab@infradead.org

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list