On Jun 11, 2011, at 11:14 PM, Hans de Goede wrote:
Hi,
On 06/11/2011 06:41 PM, Greg KH wrote:
On Fri, Jun 10, 2011 at 11:13:21PM -0500, Theodore Kilgore wrote:
Well, I guess I have not kept up with the latest. It didn't used
to do
that. I still can't help wondering if isochronous transport
through libusb
would really work for webcam application, though, because
userspace access
to a piece of hardware will almost surely be less direct than kernel
access. Sort of by instinct, I would say that there would be too
many
layers of code one on top of the other.
People have been running USB video cameras for years (i.e. 2.4 days)
using usbfs as a userspace driver just fine, and libusb really isn't
that "thick" at all so it should be very possible to do this.
Right, the problem with that approach though is that webcam using apps
expect a /dev/video node, so that would require some sort of
loopback v4l2 device (which in itself would be handy to have
sometimes),
and then looping back the data into the kernel.
IMHO it would be silly to convert our working kernel space drivers
to userspace, to then loopback the data into the kernel from the
userspace
drivers. Esp. since with userspace drivers one get all sort of
interesting
locking / sharing problems between them too.
As said before I think it is best to just add a new kernel API for
accessing
(the memory off) stillcam devices, teach libgphoto about this API
and move
the stillcam driver part for dual mode cameras into the kernel.
I think it would be more universal to teach apps that consume video
devices
to use a library API rather than depending on there being a /dev/video
node
which then strongly dictates the implementation of a video subsystem.
Using
a library API to hide the details means that not only can an
implementation
support going to /dev/video under the hood if it needs to but it would
also be
much easier to have this library enumerate all the devices that are
capable
of video on the system and leave the details of whether the camera is
handled
by a USB kernel driver or whether the camera is a network-connected
camera
or had some other interface into the system to the library backend
implementations.
For one thing, video camera driver developers could develop custom
drivers for
their particular cameras if they want to export features of the device
that the
class based video driver doesn't, or perhaps a developer wants to have
their
driver live in user-space so that they don't have to deal with the
kernel GPL
issues.
mike
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
