gspca as part of the rawhide kernel?

[Hans de Goede]

Hi all,

As some of you know I've been working on improving webcam support under Fedora, 
see:
http://fedoraproject.org/wiki/Features/BetterWebcamSupport
http://hansdegoede.livejournal.com/

One of the things I've been working on is in beating gspcav2 (a v4l2 port of 
gspca) into shape, although I must admit most of the work has been done by 
Jean-François Moine, the latest version is available from his mercurial tree 
and it has been pulled into the official v4l-dvb tree for wider testing. Once 
it has been in the v4l-dvb tree it will make its way into the mainline hopefuly 
for 2.6.27, if not then certainly fotr 2.6.28.

To check it out see:
http://linuxtv.org/hg/~jfrancois/gspca/

Some time ago I've already done a review of the gspca_core and there are some 
locking issues to solve (I already know how, I just need to code them out).

Once this is done I would like to see gspcav2 be added to the Fedora kernel, as 
to make the:
http://fedoraproject.org/wiki/Features/BetterWebcamSupport

Feature a reality (also needs userspace work, I'm on this).

So my questions are:
1) would it be acceptable to cary the gspca driver as a patch (only new files
    and makefile / kconfig changes doesn't touch anything else) until it is
    merged upstream. Note that this is much needed for wider webcam support and
    that gspca is on its way to the mainline now, and I'll personally will be
    working on ironing out any issues upstream may have with gspca as is.

2) Assuming the answer to 1 is yes, how do I move forward, can I get be added
    to the kernel package acl, what are the procedures for adding a patch and
    building a new kernel, etc?


Thanks & Regards,

Hans

[Christopher Brown]

2008/7/3 Hans de Goede <j.w.r.degoede(a)hhs.nl&gt;:
>  Hi all,
>
>  As some of you know I've been working on improving webcam support under
>  Fedora, see:
>  http://fedoraproject.org/wiki/Features/BetterWebcamSupport
>  http://hansdegoede.livejournal.com/
>
>  One of the things I've been working on is in beating gspcav2 (a v4l2 port of
>  gspca) into shape, although I must admit most of the work has been done by
>  Jean-François Moine, the latest version is available from his mercurial tree
>  and it has been pulled into the official v4l-dvb tree for wider testing.
>  Once it has been in the v4l-dvb tree it will make its way into the mainline
>  hopefuly for 2.6.27, if not then certainly fotr 2.6.28.
>
>  To check it out see:
>  http://linuxtv.org/hg/~jfrancois/gspca/
>
>  Some time ago I've already done a review of the gspca_core and there are
>  some locking issues to solve (I already know how, I just need to code them
>  out).
>
>  Once this is done I would like to see gspcav2 be added to the Fedora kernel,
>  as to make the:
>  http://fedoraproject.org/wiki/Features/BetterWebcamSupport
>
>  Feature a reality (also needs userspace work, I'm on this).
>
>  So my questions are:
>  1) would it be acceptable to cary the gspca driver as a patch (only new
>  files
>    and makefile / kconfig changes doesn't touch anything else) until it is
>    merged upstream. Note that this is much needed for wider webcam support
>  and
>    that gspca is on its way to the mainline now, and I'll personally will be
>    working on ironing out any issues upstream may have with gspca as is.
>
>  2) Assuming the answer to 1 is yes, how do I move forward, can I get be
>  added
>    to the kernel package acl, what are the procedures for adding a patch and
>    building a new kernel, etc? 
Personally I'd love to see this in rawhide. If you have a patch that
applies against the current rawhide kernel then scratch-building one
in koji isn't too much of a greater leap. Maybe DaveJ and the other
kernel bods would be happier if i's cleanly applying and won't need
much maintenance. Just note in the kernel.spec to append a buildid
(e.g. gspca) - more info here:

http://fedoraproject.org/wiki/Docs/CustomKernel

Cheers

-- 
Christopher Brown

http://www.chruz.com

[Dave Jones]

On Thu, Jul 03, 2008 at 09:45:06AM +0200, Hans de Goede wrote:
>  Hi all,
>  
>  As some of you know I've been working on improving webcam support under Fedora, 
>  see:
>  http://fedoraproject.org/wiki/Features/BetterWebcamSupport
>  http://hansdegoede.livejournal.com/
>  
>  One of the things I've been working on is in beating gspcav2 (a v4l2 port of 
>  gspca) into shape, although I must admit most of the work has been done by 
>  Jean-François Moine, the latest version is available from his mercurial tree 
>  and it has been pulled into the official v4l-dvb tree for wider testing. Once 
>  it has been in the v4l-dvb tree it will make its way into the mainline hopefuly 
>  for 2.6.27, if not then certainly fotr 2.6.28. 
F10 is going to be 2.6.27, so the former would be awesome, but if it ends up being
a .28 thing, us carrying it for a little while longer isn't a big deal.

Given there's motion on this going upstream, and it has a Fedora contributor
taking responsibility for it (ie, you), I'm ok with the idea of this going in.

>  So my questions are:
>  1) would it be acceptable to cary the gspca driver as a patch (only new files
>      and makefile / kconfig changes doesn't touch anything else) until it is
>      merged upstream. Note that this is much needed for wider webcam support and
>      that gspca is on its way to the mainline now, and I'll personally will be
>      working on ironing out any issues upstream may have with gspca as is. 
yep.
I'll give the patch an eyeballing when you commit it too.

>  2) Assuming the answer to 1 is yes, how do I move forward, can I get
> be added
>      to the kernel package acl, what are the procedures for adding a patch and
>      building a new kernel, etc? 
 
I should flesh out the wiki page some more with these questions.
But until I do..   hit up the accounts system and request access, and I'll
add you to the acl.  The only stuff that's really different from other packages is.

* instead of a PatchN:  %patch N pair where the N's have to match up, we have
  a PatchN: (where the value of N is irrelevant), just place it somewhere near
  something similar [the uvcvideo diff for eg].  Then, instead of a %patch
  entry we have an invocation of a macro called ApplyPatch which does everything %patch
  does, but with some extra smarts (like rejecting patches with fuzz).

* As for rawhide builds..  I usually kick one off shortly after the 3pm rebase.
  (That's when a new git snapshot runs from cron on kernel.org).  Sometimes I
postpone
  this a little if I'm expecting to add something else later.  The actual build
  is just like any other package (make tag  ; make build).  If in doubt about whether
  to start a build, ask on #fedora-kernel.  If no-one is planning to do one,
  (or no-one answers after a while :)  then just kick one off.

I'm actually quite excited about this.  You're the first 'real' external
committer
to the Fedora kernel.  (Well, dwmw2 has you beat by a week or two, but as he's
Red Hat alumni, I don't think that really counts :-)

	Dave

-- 
http://www.codemonkey.org.uk

[Hans de Goede]

Dave Jones wrote:
>  On Thu, Jul 03, 2008 at 09:45:06AM +0200, Hans de Goede wrote:
>   > Hi all,
>   > 
>   > As some of you know I've been working on improving webcam support under Fedora,
>
>   > see:
>   > http://fedoraproject.org/wiki/Features/BetterWebcamSupport
>   > http://hansdegoede.livejournal.com/
>   > 
>   > One of the things I've been working on is in beating gspcav2 (a v4l2 port of 
>   > gspca) into shape, although I must admit most of the work has been done by 
>   > Jean-François Moine, the latest version is available from his mercurial tree 
>   > and it has been pulled into the official v4l-dvb tree for wider testing. Once 
>   > it has been in the v4l-dvb tree it will make its way into the mainline hopefuly 
>   > for 2.6.27, if not then certainly fotr 2.6.28.
>  
>  F10 is going to be 2.6.27, so the former would be awesome, but if it ends up being
>  a .28 thing, us carrying it for a little while longer isn't a big deal.
>  
>  Given there's motion on this going upstream, and it has a Fedora contributor
>  taking responsibility for it (ie, you), I'm ok with the idea of this going in.
>   
Great!

>   > 2) Assuming the answer to 1 is yes, how do I move forward, can
> I get be added
>   >     to the kernel package acl, what are the procedures for adding a patch and
>   >     building a new kernel, etc?
>   
>  I should flesh out the wiki page some more with these questions.
>  But until I do..   hit up the accounts system and request access, and I'll
>  add you to the acl.  The only stuff that's really different from other packages is.
>   
Access requested.

>  * instead of a PatchN:  %patch N pair where the N's have to match
> up, we have
>    a PatchN: (where the value of N is irrelevant), just place it somewhere near
>    something similar [the uvcvideo diff for eg].  Then, instead of a %patch
>    entry we have an invocation of a macro called ApplyPatch which does everything %patch
>    does, but with some extra smarts (like rejecting patches with fuzz).
>  
>  * As for rawhide builds..  I usually kick one off shortly after the 3pm rebase.
>    (That's when a new git snapshot runs from cron on kernel.org).  Sometimes I
> postpone
>    this a little if I'm expecting to add something else later.  The actual build
>    is just like any other package (make tag  ; make build).  If in doubt about whether
>    to start a build, ask on #fedora-kernel.  If no-one is planning to do one,
>    (or no-one answers after a while :)  then just kick one off.
>   
Thanks for the info. I currently have the following score with my testing cams 
(I've been buying every cam I can find which costs less then 20 euros):

2 are untested (-ENOTIME)
2 do not have a driver available in the kernel or in gspca
   (but do have some initial attemps located at sourceforge I plan on working
    on those later)
1 does not work even though it has a driver, I need to make usbsnoop dumps of
   this one under windows.
2 work, but do not have any exposure setting, which is a show stopper, as
   without modifyable exposure either they don't work in daylight or not with
   artifical light.
5 work good

Yesterday and most of today I've been working on finding out howto do exposure 
on the 2 cams without exposure setting. I've figured that out now and found out 
where the average lumination is found in the frameheader, so I'm busy adding 
autoexposure to these 2 now. As an added bonus I've also figured out howto 
activate the 50hz artificial light filter on one of them, killing the annoying 
flicker when using it with artificial light.

When that is done (hopefully tonight) I still need to take a good look at the 
locking in the gspca core and fix a few issues there, then I'll prepare a patch 
against the latest kernel in rawhide and add gspca to the kernel!

Regards,

Hans

[Hans de Goede]

Dave Jones wrote:
>  On Thu, Jul 03, 2008 at 09:45:06AM +0200, Hans de Goede wrote:
>   > Hi all,
>   > 
>   > As some of you know I've been working on improving webcam support under Fedora,
>
>   > see:
>   > http://fedoraproject.org/wiki/Features/BetterWebcamSupport
>   > http://hansdegoede.livejournal.com/
>   > 
>   > One of the things I've been working on is in beating gspcav2 (a v4l2 port of 
>   > gspca) into shape, although I must admit most of the work has been done by 
>   > Jean-François Moine, the latest version is available from his mercurial tree 
>   > and it has been pulled into the official v4l-dvb tree for wider testing. Once 
>   > it has been in the v4l-dvb tree it will make its way into the mainline hopefuly 
>   > for 2.6.27, if not then certainly fotr 2.6.28.
>  
>  F10 is going to be 2.6.27, so the former would be awesome, but if it ends up being
>  a .28 thing, us carrying it for a little while longer isn't a big deal.
>  
>  Given there's motion on this going upstream, and it has a Fedora contributor
>  taking responsibility for it (ie, you), I'm ok with the idea of this going in.
>   
Good news, I've just heard from v4l-dvb upstream (Mauro) that his pull request 
to Linus for the 2.6.27 merge window will include gspca, so I guess I won't be 
adding this as an additional patch to the rawhide kernel. I may add some small 
bugfix patches on top of gspca in case of important fixes which miss getting 
merged for one reason or the other, but the big chunk is coming through the 
mainline.

Regards,

Hans