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.
Regards,
Hans
--
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
