On Tue, 28 Apr 2009, David Brownell wrote: > On Thursday 23 April 2009, Guennadi Liakhovetski wrote: > > On Thu, 23 Apr 2009, Felipe Balbi wrote: > > > > > On Thu, Apr 23, 2009 at 12:34:43PM +0200, ext Guennadi Liakhovetski wrote: > > > > Hi all, > > > > > > > > the ptp-gadget user-space driver has reached version 1.0 (tag v1.0 under > > > > git://git.denx.de/ptp-gadget.git), which marks stricter standard > > > > compliance to the extent that also MS Windows hosts (tested with XP SP3) > > > > now also work with it. Enjoy. > > > > > > how, why not using the u_serial.c fw from composite gadget fw and on > > > userland just having a daemon reading and writing to the /dev/ttyGS* > > > created devnodes ?? > > > > I don't know exactly how u_serial.c works, but from a brief look it looks > > like it just provides some library, > > A library that provides a pretty robust, flow-controlled byte stream > interface. For your purposes, it won't matter that it's hooked up > to the TTY layer ... except that by doing so, you can (a) combine with > other components, and (b) not have to care about packet boundaries. > > > > that then gets #include'ed by other > > drivers, e.g., serial.c or cdc2.c. Which then implement specific USB > > functionality, create USB device, configuration, interface descriptors, > > etc. So, you would need a ptp.c, implementing ptp USB device descriptors, > > That's all implementation details; noise. The #include is just > because "gcc --combine ..." doesn't yet work for kernel code. > > Another option for that "ptp.c" would be to get rid of the userspace > component, and just provide direct access through VFS. I think there > would be virtue in such a thing -- a *file sharing* protocol over USB, > not a "raw disk" protocol like mass storage -- but could understand > if that's not the direction you want to go. > > > > 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?...:-) > 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. > 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:-) > 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:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@xxxxxxx -- 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
