SRU LP #269123 stkwebcam kernel-module doesn't support all the webcams supported previously with stk11

[Jim Lieb]

On Thursday 15 January 2009 08:51:30 Stefan Bader wrote:
> Jim Lieb wrote:
> > On Thursday 15 January 2009 08:30:02 Stefan Bader wrote:
> >> Jim Lieb wrote:
> >>> This is a backport of the stk11xx driver from SourceForge.  It was in
> >>> Hardy but did not make it to Intrepid.  The patch is quite large due to
> >>> its inclusion of the (new) driver files.  Both reporters have confirmed
> >>> it works with both amd64 and i386.
> >>>
> >>> git://kernel.ubuntu.com/lieb/ubuntu-intrepid.git lp269123
> >>>
> >>> Proposing for SRU for Intrepid.
> >>>
> >>> The upgraded stkwebcam driver in Jaunty (2.6.28) should be tested
> >>> prior to proposing for Jaunty.  Those changes were not attempted due
> >>> to the rework between .27 and .28.
> >>>
> >>> Jim
> >>
> >> Alright, I had some time to look at the driver. The problem here is that
> >> this new driver takes the same IDs as the stk-webcam driver which is in
> >> Intrepid and also build and shipped. So for this reason the backported
> >> driver has to go into lbm.
> >>
> >> Stefan
> >
> > Sure if that is the consensus.  All I need is a pointer on how to do it. 
> > We already know that the driver works for the reporters.  Pointer please?
>
> Not sure we have a good doc there. Basically the mechanics are similar to
> the ubuntu dir. There is a separate git intrepid-lbm.git. You place the new
> driver into the updates dir there update Makefile to descend into that dir
> (configurable) and then turn on the configs in the debian/config dir. In
> the past it was usually done in two steps: first add the driver and Maefile
> change and in a second checkin turn on the configs.
>
> Stefan
I've had look at the lbm git and the one paragraph in KernelMaintenance and
I'm not sure I am more or less confused.  All I see in the git at this point
is the wireless-compat stuff with its firmware.  I'd like to get some guidance
because, although I can make either work, unwinding this thing can be a
big PITA for all concerned if is it's not "the plan".  I plead newbie
ignorance of process here.

* What is the criteria?  There are lots of competing drivers and modules
  all over the kernel.  What would make this special and a candidate for lum?
  As for conflicting usb ids, that's a job for udev and friends.  The driver
  already lives side by side with stkwebcam in /lilb/modules.

* If the consensus of the folks who have been around here longer than me
  is that it does go into lum, I have no problem and will re-target this into
  the lum git asap.  If so, do I add a ./updates/webcams dir for it to live
  under or do I plop it in as a driver at the same level?  The
  linkage in ./ubuntu seems pretty clear since it all falls under the kbuild
  and main kernel makefile environment.  There seems to be some magic
  here that I'd have do dup, i.e. where does $(src) in the top makefile
  come from/get set from?  Is there a doc/wiki/README for this? Things
  like the config files for the wireless are empty (of usable content other
  that comments...) and the Makefile is a one liner so there is not much
  to plagiarize.

BTW, I'm a bit uncomfortable with separate but "co-mingled" git trees
and the buried magic in multiple directory trees and the shell/makefile 
scripts to tie them together.  I've had some version skew nightmares
that still make me twitch so pardon my paranoia.  Is the ./ubuntu dir
such a candidate for keeping such entropy under control?

On another note that *should* be orthogonal to where the bits end up; is
there any module load time glue that we supply?  That is one of the
missing pieces between driver writers and udev rule writers at the moment.
Do we have policy/criteria for this and if so, where do I find it?

Thanks
-- 
Jim Lieb
Ubuntu Kernel Team
Canonical Ltd.