[pulseaudio-discuss] [PATCH 1/2] module-device-manager: Fix description restore

[Tanu Kaskinen]

On Thu, 2013-05-30 at 01:45 +0200, David Henningsson wrote:
> On 05/29/2013 04:57 PM, Tanu Kaskinen wrote:
> >
> > On Wed, 2013-05-22 at 14:45 +0300, Tanu Kaskinen wrote:
> >> On Wed, 2013-05-22 at 13:33 +0200, David Henningsson wrote:
> >>> e->description is a pointer, not a fixed char array. Hence it
> >>> makes no sense to use strncmp.
> >>>
> >>> This fixes a compiler warning when compiling under Ubuntu.
> >>>
> >>> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
> >>> ---
> >>>   src/modules/module-device-manager.c |    4 ++--
> >>>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/src/modules/module-device-manager.c b/src/modules/module-device-manager.c
> >>> index 207870d..390046f 100644
> >>> --- a/src/modules/module-device-manager.c
> >>> +++ b/src/modules/module-device-manager.c
> >>> @@ -889,7 +889,7 @@ static pa_hook_result_t sink_new_hook_callback(pa_core *c, pa_sink_new_data *new
> >>>       name = pa_sprintf_malloc("sink:%s", new_data->name);
> >>>
> >>>       if ((e = entry_read(u, name))) {
> >>> -        if (e->user_set_description && strncmp(e->description, pa_proplist_gets(new_data->proplist, PA_PROP_DEVICE_DESCRIPTION), sizeof(e->description)) != 0) {
> >>> +        if (e->user_set_description && strcmp(e->description, pa_proplist_gets(new_data->proplist, PA_PROP_DEVICE_DESCRIPTION)) != 0) {
> >>
> >> pa_proplist_gets() can return NULL, and if it does that, strcmp() will
> >> crash.
> >
> > Actually, I think we should make sure that all sink implementations set
> > PA_PROP_DEVICE_DESCRIPTION in new_data->proplist. Or even better, we
> > could have a separate description field in the new_data struct. I'm
> > dealing with sink descriptions myself currently, and I find it annoying
> > having to access them through proplists, and if I can't assume that the
> > property has been set, it's even more annoying.
> >
> 
> Hmm, can you explain why
>   1) You need a PA_PROP_DEVICE_DESCRIPTION for sinks (and sources, I 
> assume) in the first place?

I intend to use the sink/source description as the node description too
(for nodes that are backed by a sink or source, that is - if ports
exist, they are used as the node backend instead, but not all sinks and
sources are associated with a port).

>   2) Why you need it so much that we should artificially create one in 
> all sink implementations even if there is no relevant information to add?

How could there possibly be no relevant information to add? Surely every
sink can have a sane human-readable description?

pavucontrol needs a description anyway, because it uses sinks and
sources as UI elements. For this reason I wouldn't be surprised if the
situation already was such that every sink and source sets
PA_PROP_DEVICE_DESCRIPTION.

>   3) Why you can't write a helper function/macro if you find it annoying 
> to access the proplist in several places?
> 
> My biggest worry is 2) here - we shouldn't create more information just 
> for the sake of it. I don't know what you want it for, but maybe a fall 
> back would be better - e g, using the sink description if there is no 
> device description property. This would be handled by the helper 
> function suggested in 3).

Uh, it seems that you think that sinks have a separate description in
addition to PA_PROP_DEVICE_DESCRIPTION. If they did, I'd have no
problem.

-- 
Tanu