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. 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. 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? 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. The flexibility would come from being able to hook up to more kernel modules -- simple gadget, or various flavors of composite. - 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
