On Friday 01 December 2006 1:58 pm, Chris Ostler wrote: > I'm writing a driver for a composite (telephony) device which has three > interfaces. Due to the design of the device, the interfaces will never be > used in isolation - you have to use all three to get any useful > functionality.
When you say "driver" do you mean host or peripheral side driver? > That said, there are essentially three 'channels' of communication: a > bi-directional control channel, and two bi-directional audio channels. I'd > like to present this as: > /dev/cg%d - the control channel > /dev/cg%da - the first audio channel > /dev/cg%db - the second audio channel > > Ideally, I'd like to bind the driver to the device, and then register the > three device nodes. However, it seems that binding is done at the > interface level. I seem to recall some discussion of binding at the device > level, but I didn't see any examples of this. On the host side, that's not supported right now. On the peripheral side, that's all you've got ... so the problem is reversed: how to best link several functions into one composite gadget. > Even better would be to be able to register the two audio channels with > ALSA, adding flexibility with respect to supported audio formats (thus > supporting more than the 8000Hz mono uLaw native to the device). I don't think anything would prevent your connecting the channels to ALSA. Except I think it would expect to control things, and I'm not sure where that leaves your control channel ... > My questions then are: > 1) What's the proper way to bind to a device instead of an interface? You may be better off thinking of this differently. If you can make your driver bind to the control interface, then you should be able to usb_driver_claim_interface() to grab the interfaces for the audio channels. But I can imagine you might run into some issues there with the current ALSA audio support not being set up to be very subservient to your control interface. You might need to hack that driver code a bit ... it'd be good if you could avoid forking, but that'd certainly be a near-term expedient option. > 2) How should the audio device nodes be created? Let udev (or maybe mdev from busybox) handle that. > 3) Is there an easy way for defining the audio channels to be 'cards', and > use ALSA to do the rest of the lifting? I expect there is, but I'm not an ALSA expert. :) - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
