[PATCH 3/6] Cards now has ports directly, and device port has list of profiles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2011-11-08 at 20:16 +0200, Tanu Kaskinen wrote:
> On Tue, 2011-11-08 at 14:21 +0100, David Henningsson wrote:
> > On 11/08/2011 11:30 AM, Arun Raghavan wrote:
> > > On Thu, 2011-11-03 at 21:04 +0200, Tanu Kaskinen wrote:
> > >> Somehow keeping a list of profiles in the ports doesn't feel right -
> > >> it's as if that list would have been thrown there just to make things
> > >> convenient for some random code... But I guess there's a reason, which
> > >> just isn't apparent from this patch yet, for having that list there.
> > >
> > > This is my largest concern as well.
> > 
> > There is nothing wrong with every port knowing what profiles that port 
> > is a part of; it follows naturally with having port belonging to cards.
> 
> I think I agree after all. I tried to come up with a better
> counterargument than "it doesn't feel right", but I failed.

Here's my reasoning -- if you look at this from a pure ALSA perspective,
profiles are a list of PCMs and associated mixer paths. Put this way,
the jack -> profile pointer could makes sense.

More generically, though, profiles represent some set of mutually
exclusive input/output paths. Defining them this way, there isn't really
a relation between the ports and profiles, only between the ports and
the input/output paths that the profiles represent. (which is why I
believe my alternative makes sense)

Looking at it merely as the code stands today, the first interpretation
makes sense -- we only really support ports on ALSA devices. But that's
only the short-term view, and IMO it makes more sense to take the
long-term view when defining your classes and their relations.

-- Arun



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux