On Tue, 2014-03-11 at 18:13 +0000, Pete Beardmore wrote: > Quoting Tanu Kaskinen <tanu.kaskinen at linux.intel.com>: > > thanks for coming back so quickly > > > I don't know what you mean by abusing proplists, > > i was referring to the (some might say) pollution of the hash with > what is really just a temp variable that needs passing to the > pa_device_init_description(). it's not really a proper PROP, e.g. > existing in proplist.h for users to utilise. but i'm happy if you are Hmm, yes, the fact that it's just a temp variable is a bit ugly. The fact that it's not defined in proplist.h, however, is totally fine. My personal opinion is that we shouldn't have defined any "standard" properties in proplist.h to begin with, because once a property is documented in a public header, it becomes part of the stable API, and very similar to a field in a struct. A field in a struct is much nicer to work with, so there's no point in defining a stable API in proplists. > > ..I'd prefer the PA_PROP_DEVICE_CARD_DESCRIPTION > > initialization to happen in pa_sink_new()/pa_source_new() instead of in > > the alsa code, because there's nothing alsa specific in this logic. > > i tried it that way initially. however, by the time those functions > are called, their data->proplist args already contain a > PA_PROP_DEVICE_DESCRIPTION (ensured by the earlier call to > pa_device_init_description() from pa_alsa_sink/source_new), and this > in turn causes the pa_device_init_description() to return immediately > this second time around > > one could look to override this description, but by then it appears > too late, as we may not be dealing with a default (sink/source) device > description at all, and so prefixing a card device description could > be the wrong thing to do. hence i couldn't see any reasonable way to > keep the logic there Ok, I see the problem. I have an alternative proposal: pass the pa_card pointer to pa_alsa_init_description() and pa_device_init_description(), and then in pa_device_init_description() use the card's description to set the sink/source description. This way non-alsa specific logic stays in the generic part of the code. Also, we don't need to add the device.card.description property. -- Tanu
