On Tuesday 28 April 2009, Guennadi Liakhovetski wrote: > > > > > > and then you would need a user-space daemon to implement the actual > > > protocol. How would this be any better? > > > > It might be easier to do some things in-kernel. I/O wise, > > doing zerocopy to/from userspace for USB is not easy ... so > > low overhead filesystem access is easier from the kernel. > > That matters for handhelds with teensy weensy batteries. > > ...running Linux?...:-) Is there anything else to run? :) > > On the flip side, it may be easier to provide camera controls > > using existing userspace interfaces. That is, PTP commands > > to set shutter speed, f/stop, "capture image now", and so on > > would seem to be better in userspace. And you can still use > > various event calls to issue notifications to the host that > > "the user took a new picture" and so on. > > Exactly, that was (one of) the reason to do this in user space, to easily > interface to v4l2. > > > But I think the real advantage would be ability to build a > > PTP function as part of something else. Example, as well > > as "tethered camera" functionality (part of full PTP) you > > could concurrently provide a network link, an audio stream, > > and WLAN access. > > > > Doesn't PTP require a byte stream interface? > > No, there're no isochronous endpoints, if that's what you mean, no > streaming. Just commands and data blocks. Even capture of multiple images > handles each image separately. I meant as in contrast to packet boundaries mattering. If C[01234..][abcd...] are successive parts of commands labeled C[01234..], consider two packet streams: P0: C0a C1a C2a C3a P1: C3b P2: C3c C4a versus P0: C0a P1: C1a P2: C2a P3: C3a C3b P4: C3c P5: C4a Given a byte stream, it's always "C0a C1a C2a C3a C3b C3c C4a". But given a packet stream, you've got to parse packets and cope with multiple commands per packet, multiple packets per command, and combinations thereof. Doable, sure. But it complicates what would otherwise be very simple. > > > Gadgetfs is > > more like a packet interface. Offloading packetization > > would make your userspace simpler. > > > > > > > > > > > I guess it would be a lot simpler for userland and we wouldn't tie ptp > > > > to one userland application. > > > > > > Don't see how this would be simpler and you would then be tied to a kernel > > > module _and_ a user-space application. > > > > That I don't follow. You're already tied to a kernel module > > (gadgetfs) and userspace code. > > Right, but now this is just one already existing "generic" module, whereas > otherwise it would be a new special one:-) I see, I think. > > The flexibility would come from being able to hook up to > > more kernel modules -- simple gadget, or various flavors > > of composite. > > I see, but that would be a different project, I guess:-) I suspect you could easily have a common core of code, though. - Dave -- 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
