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

[Jim Lieb]

Ok, I think I have enough to go on.  I'll move this stuff to lbm and take this
email chain and update the wiki from the experience.

On Friday 16 January 2009 00:09:27 Stefan Bader wrote:
> Jim Lieb wrote:
> > 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.
>
> The most important criteria being: can it cause side effects. This can be
> true for modules which already are in the kernel and are replaced by an
> upstream or more recent version. But also, as there are real life cases,
> when a newer driver takes ownership of HW that was/is handled by a
> different driver (or at least supposed to be).
> The problem here is that there are known issues with the automatic loading
> of modules. The given search path does not guarantee the precedence of one
> driver over the other. Also as this driver does take responsibility for
> more that one ID. Have all been non-working with the old driver or will
> some users experience regressions?
>
> > * 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
>
> You mean lbm. But yes, a subdir for a class of drivers with an additional
> dir for the individual driver makes sense. Especially when we split up the
> one big package into more manageable chunks.
>
> >   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.
>
> Not that I know of. In general it is the mechanism of the kernel to build
> external modules tied into debian packaging. So most magic comes from
> changing into the headers dir (the one that also contains .config and
> module versions) and then do a make M=<extmod dir>
>
> > 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?
>
> The alternative sounds more frightening to me. Putting things into this
> separate places at least shows there are changes to a released codebase
> that are modified. Less critical stuff gets into ubuntu (formerly lum) and
> the more risky into lbm which requires the user at least to make a known
> decision to install. Otherwise updates can break a system for no apparent
> reason.
>
> > 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?
>
> The glue at load time mostly is the search path of modules. And for
> completely separate new stuff this is just another module in anoter known
> location. The policy if you want to say so is the search paths/order
> defined in
> /etc/depmod.d/ubuntu.conf (installed by module-init-tools). Nothing scary.
> It gets hairy for drivers that share PCI or USB or whatever ID.
>
> Stefan

-- 
Jim Lieb
Ubuntu Kernel Team
Canonical Ltd.