Hi,
On Mon, Aug 22, 2011 at 06:30:36PM +0530, Jassi Brar wrote:
> > I understand your point, but then we will have two gadget drivers (and
> > two function drivers) for the same thing (USB Audio), it's the same
> > thing with the storage gadgets and we have decided on dropping one of
> > them recently, so I'm not keen on accepting another gadget driver which
> > will essentially do the same thing.
> No dear, not the same thing.
> As I said, they differ by features as well as USB-Spec... only the
> 'audio' thing is common.
and that's what I meant by same thing. How different is UAC_1 from
UAC_2.
> > If audio2.c can achieve audio.c's functionality, then you can start by
> > re-factoring audio.c so that it come closer to what audio2.c is today.
> audio.c and audio2.c have almost nothing in common. Please have a look
> at the code.
> Making audio.c closer to audio2.c would mean :-
> * Changing all of the descriptors of audio.c {uac_1 -> uac_2}
> * Removing all alsa related code and adding virtual alsa sound card.
> At the end, audio.c would have been changed completely and Linux-usb-gadget
> lost the UAC_1 compliance.
it shouldn't loose compliance. If it does it was probably not done
right.
> > WRT UAC_1/UAC_2 compliance, you can use a Kconfig entry, or two separate
> > USB configurations (one with UAC_1 and another UAC_2). So there are ways
> > to make this all work while still keeping backwards compatibility.
> IIUC, you mean adding UAC_2 compliance and virtual sound-card i/f to
> audio.c, while
> preserving the it's original functionality ?
yes.
> But that would mean having two drivers in one file, because they are
> so different.
then make only a differnt function driver, f_uac2.c, which gets added as
another interface (or configuration) to audio.c.
> Otherwise, please have a look at audio.c and audio2.c and suggest what
> exactly you mean.
audio.c doesn't do anything audio related. It's just adding the
configuration to composite layer. The real specification is implemented
in f_audio.c (should probably be called f_uac1.c, though).
Then only thing different between audio.c and audio2.c is bDeviceClass,
bDeviceSubClass and bDeviceProtocol, but that can be easily handled with
Kconfig choice and/or module parameter.
--
balbi
Attachment:
signature.asc
Description: Digital signature
