Message-ID: <alpine.LNX.2.00.1108101300500.25084@banach.math.auburn.edu>
Date:	Wed, 10 Aug 2011 13:33:25 -0500 (CDT)
From:	Theodore Kilgore <kilgota@...ach.math.auburn.edu>
To:	Alan Stern <stern@...land.harvard.edu>
cc:	Hans de Goede <hdegoede@...hat.com>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Greg KH <greg@...ah.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	linux-usb@...r.kernel.org, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, libusb-devel@...ts.sourceforge.net,
	Alexander Graf <agraf@...e.de>,
	Gerd Hoffmann <kraxel@...hat.com>, hector@...cansoft.com,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	pbonzini@...hat.com, Anthony Liguori <aliguori@...ibm.com>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Oliver Neukum <oliver@...kum.org>, Felipe Balbi <balbi@...com>,
	Clemens Ladisch <clemens@...isch.de>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Adam Baker <linux@...er-net.org.uk>
Subject: Re: USB mini-summit at LinuxCon Vancouver



On Wed, 10 Aug 2011, Alan Stern wrote:

> On Wed, 10 Aug 2011, Theodore Kilgore wrote:
> 
> > > Okay, I didn't realize that the different cameras used different webcam 
> > > drivers as well as different stillcam drivers.
> > 
> > Oh, yes. They are Proprietary devices. And that means what it says. :-)
> > And all different from each other, too.
> >  
> > > As far as I can see, there's nothing to stop anybody from adding the 
> > > stillcam functionality into the webcam drivers right now.  If some 
> > > common code can be abstracted out into a shared source file, so much 
> > > the better.
> > > 
> > > That would solve the problem, right?
> > 
> > I think everyone involved believes that it would solve the problem. 
> > 
> > The question has been all along whether or not there is any other way 
> > which would work. Also the question of what, exactly, "belongs" in the 
> > kernel and what does not. For, if something has been historically 
> > supported in userspace (stillcam support, in this case) and has worked 
> > well there, I would think it is kind of too bad to have to move said 
> > support into the kernel just because the same hardware requires kernel 
> > support for another functionality and the two sides clash. I mean, the 
> > kernel is already big enough, no? But the logic that Hans has set forth 
> > seems rather compelling. 
> 
> The alternative seems to be to define a device-sharing protocol for USB
> drivers.  Kernel drivers would implement a new callback (asking them to
> give up control of the device), and usbfs would implement new ioctls by
> which a program could ask for and relinquish control of a device.  The
> amount of rewriting needed would be relatively small.
> 
> A few loose ends would remain, such as how to handle suspends, resumes,
> resets, and disconnects.  Assuming usbfs is the only driver that will
> want to share a device in this way, we could handle them.
> 
> Hans, what do you think?
> 
> Alan Stern

Alan,

Hans seems to have argued cogently for doing all of this in the kernel and 
for abandoning the usbfs-based drivers for these particular drivers for 
dual-mode cameras and, I would conjecture, for drivers for dual-mode 
hardware in general. Therefore, I anticipate that he won't like that very 
much.

My position:

I do not have preconceptions about how the problem gets handled, and at 
this point I remain agnostic and believe that all approaches ought to be 
carefully analysed. I can imagine, abstractly, that things like this 
could be handled by

-- moving all basic functionality to the kernel, and fixing the 
relevant libgphoto2 drivers to look to the kernel instead of to libusb. 
(What Hans argues for, and I am not opposed if his arguments convince 
other concerned parties)

-- doing some kind of patch job to make current arrangement somehow to 
work better (this seems to be the position of Adam Baker; I do share
the skepticism Hans has expressed about how well this could all be 
pasted together)

-- doing something like the previous, but also figuring out how to bring 
udev rules into play, which would make it all work better (just tossing 
this one in, for laughs, but who knows someone might like it)

-- moving the kernel webcam drivers out of the kernel and doing with these 
cameras _everything_ including webcam function through libusb. I myself do 
not have the imagination to be able to figure out how this could be done 
without a rather humongous amount of work (for example, which streaming 
apps that are currently available would be able to live with this?) but 
unless I misunderstand what he was saying, Greg K-H seems to think that 
this would be the best thing to do.

Which one of these possibile approaches gets adopted is a policy issue 
which I would consider is ultimately way above my pay grade.

My main motivation for bringing up the issue was to get it to the front 
burner so that _something_ gets done. It is a matter which has been left 
alone for too long. Therefore, I am very glad that the matter is being 
addressed.

Let me add to this that I have gotten permission for time off and for a 
expense money which might possibly cover my air fare. I hope to arrive in 
Vancouver by sometime on Monday and intend to attend the mini-summit. I 
suggest that we get all intersted parties together and figure out what is 
the best way to go.

I hope everyone who is actively concerned can meet in Vancouver, and if 
all goes well then on Monday as well as Tuesday. I can hang around for 
another day or two after Tuesday, but I do not expect to register for 
LinuxCon or be involved in it. When I leave Vancouver I will probably go 
to Seattle and spend a couple of days with my oldest son, the musician, 
before coming home on the next weekend.

Theodore Kilgore
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists