A set of different variables are used to hold dependencies. However,
no individual use of them is done.
This patch removes these variables and holds their objects directly
in the array of dependencies.
https://bugzilla.gnome.org/show_bug.cgi?id=792948
Following the meson porting guidelines, this patch renames the build
options. The list of changes is as follows:
- Remove the with prefix from string options.
- The character separator from multi-word options has been changed
to underscore.
It also changes the introspection and static meson variables to be
consistent with the one used for alsa.
https://bugzilla.gnome.org/show_bug.cgi?id=792948
ALSA support is not mandatory for libgnome-volume-control, but it
can not be made optional.
This patch makes the ALSA support optional by using an option.
https://bugzilla.gnome.org/show_bug.cgi?id=792919
The defines are only relevant for compiling libgvc itself, not for
any consumers of the library. In fact, setting G_LOG_DOMAIN is
likely to conflict with the log domain defined by the including
project ...
When on A2DP profile and a Bluetooth input is selected, we first need to
switch the profile to HFP/HSP, then select the default source to be that
profile. In some cases the latter step was forgotten, because
the variable "profile_swapping_device_id" was reset before it was
supposed to be used.
https://bugzilla.gnome.org/show_bug.cgi?id=736943
In both cases objects are inserted in hash table by adding an
extra ref, but the existing reference was never removed. Don't
add a reference instead, so we don't end up with a spare one.
Based on patch by Alberts Muktupāvels <alberts.muktupavels@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=765694
In a28e23d900, we said:
The callbacks will be called repeatedly, once with data, and later
on with eol == 0. Make sure to only free it when we get the eol call
instead of once we've applied the settings.
Whereas the docs say:
When requesting all of these [instances] at once, the callback will be
called multiple times, once for each object. When the list has been
exhausted, the callback will be called without an information structure
and the eol parameter set to a positive value.
If an error occurs, the callback will be invoked without an information
structure and eol set to a negative value.
So, in all, we need to free our callback data when eol is positive, or
negative. So, when it's not 0.
Seems we got lucky in the original commit because the test machine only
had a single soundcard.
The callbacks will be called repeatedly, once with data, and later
on with eol == 0. Make sure to only free it when we get the eol call
instead of once we've applied the settings.
Example valgrind output:
==31715== Invalid read of size 8
==31715== at 0x24529E09: port_status_data_free (gvc-mixer-control.c:2079)
==31715== by 0x1DB81344: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF3FE0: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF436A: pa_pdispatch_run (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DB7507D: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF6B5E: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF91BA: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9568: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9DF9: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1D96202A: ??? (in /usr/lib64/libpulse-mainloop-glib.so.0.0.5)
==31715== by 0x7AA7CF9: g_main_dispatch (gmain.c:3154)
==31715== by 0x7AA7CF9: g_main_context_dispatch (gmain.c:3769)
==31715== by 0x7AA8057: g_main_context_iterate.isra.29 (gmain.c:3840)
==31715== Address 0x2bd83480 is 0 bytes inside a block of size 16 free'd
==31715== at 0x4C2ED6A: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31715== by 0x7AAD2AD: g_free (gmem.c:189)
==31715== by 0x1DB81562: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF3FE0: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF436A: pa_pdispatch_run (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DB7507D: ??? (in /usr/lib64/libpulse.so.0.18.2)
==31715== by 0x1DDF6B5E: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF91BA: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9568: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1DDF9DF9: ??? (in /usr/lib64/pulseaudio/libpulsecommon-7.1.so)
==31715== by 0x1D96202A: ??? (in /usr/lib64/libpulse-mainloop-glib.so.0.0.5)
==31715== by 0x7AA7CF9: g_main_dispatch (gmain.c:3154)
==31715== by 0x7AA7CF9: g_main_context_dispatch (gmain.c:3769)
==31715== Block was alloc'd at
==31715== at 0x4C2F9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31715== by 0x7AAD1F0: g_malloc0 (gmem.c:124)
==31715== by 0x2452A39D: gvc_mixer_control_set_port_status_for_headset (gvc-mixer-control.c:2173)
==31715== by 0x2451BE81: audio_selection_done (gsd-media-keys-manager.c:2489)
==31715== by 0x7550ED3: emit_signal_instance_in_idle_cb (gdbusconnection.c:3701)
==31715== by 0x7AA7CF9: g_main_dispatch (gmain.c:3154)
==31715== by 0x7AA7CF9: g_main_context_dispatch (gmain.c:3769)
==31715== by 0x7AA8057: g_main_context_iterate.isra.29 (gmain.c:3840)
==31715== by 0x7AA8371: g_main_loop_run (gmain.c:4034)
==31715== by 0x5CEA204: gtk_main (gtkmain.c:1246)
==31715== by 0x403804: main (main.c:434)
Add "audio-device-selection-needed" which will be emitted when a
headphones, headset or microphone is plugged into a jack socket that
cannot detect which type it was.
Once the user of libgnome-volume-control has asked the user which type
of device this was, they can call gvc_mixer_control_set_headset_port()
to switch the ports for that configuration.
Note that gvc_mixer_control_set_headset_port() supports passing the
card ID, but the detection code only supports a single such device. When
we find hardware that can support > 1 such device, we can test and
implement support without breaking the API.
Based on the original code by David Henningsson <david.henningsson@canonical.com>
for the unity-settings-daemon
https://bugzilla.gnome.org/show_bug.cgi?id=755062
- Fix warning about comparison between signed and unsigned integer
expressions
- Change variable name 'output' to 'device' to fix warning:
declaration of 'output' shadows a parameter
- Fix warning about missing default case in switch
Card in pa_source_info that is used as card-index is uint32_t so it
is never less then 0. Also index in GvcMixerCard is already unsigned
int that is used to compare with card-index. This fixes build
warning - comparison between signed and unsigned integer expressions.
https://bugzilla.gnome.org/show_bug.cgi?id=752244
GvcMixerStream id is unsigned int and starts with 1, so we can use
0 as invalid id. This fixes build error/warning - comparison
between signed and unsigned integer expressions.
Entries are only hidden when available == PA_PORT_AVAILABLE_NO, so if an
entry toggles between PA_PORT_AVAILABLE_YES and
PA_PORT_AVAILABLE_UNKNOWN (Bluetooth headset switching between HSP/HFP
and A2DP for example), this should not result in new entries being created.
https://bugzilla.gnome.org/show_bug.cgi?id=697545
The "uint" type is not defined for standard C, and building with
-std=c99 enable stricter conformance and results in compilation failing.
Use "guint" instead.
Right now, makes sure "Off" profiles are not added, because when selected,
the item will disappear and there's no way to get it back (because it
disappeared). In the long term, handling the "off" profile correctly
would be better.
https://bugzilla.gnome.org/show_bug.cgi?id=693654
This will allow to have different icons for internal audio cards
(which are flagged generically as "audio-card"), depending on which
port is in use (ie. headphones or speakers).
This requires the new icon information, which is only exported by
PulseAudio 3.0. If it's not available, we fallback to card icons
like before.
https://bugzilla.gnome.org/show_bug.cgi?id=689931
