Fedora Account System
Red Hat Associate
Red Hat Customer
In openQA, we have a test where we check the volume icon at the top right in GNOME correctly reflects changes to the volume levels. The test works by running commands like this: amixer -D pipewire sset Master 0% and then checking the volume icon changed as expected. This worked fine until Fedora-Rawhide-20260402.n.0 , where it stopped working. The only relevant package I can see in the changelog for that compose is wireplumber: Package: wireplumber-0.5.14-1.fc45 Old package: wireplumber-0.5.13-1.fc44 so I'm filing against that. When the test worked, the output of the command looked like this: Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined Playback channels: Front Left - Front Right Limits: Playback 0 - 65536 Mono: Front Left: Playback 0 [0%] [on] Front Right: Playback 0 [0%] [on] and the icon changed to a speaker with an 'x' next to it, as expected. Now the test is failing, the output of the command looks slightly different: Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined Playback channels: Mono Limits: Playback 0 - 65536 Mono: Playback 0 [0%] [on] and the panel icon does not change, it continues to show an 'active' speaker icon indicating about 50% volume. Is this a bug in wireplumber? Bug in GNOME? Do we need to change the command openQA runs? Thanks!
Also reported upstream: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/5259
This bug appears to have been reported against 'rawhide' during the Fedora Linux 45 development cycle. Changing version to 45.
Per https://gitlab.freedesktop.org/pipewire/wireplumber/-/work_items/946#note_3626196 I dug into this a bit more and found it's specific to openQA's particular default qemu sound device configuration, and managed to work around it by changing that setting - https://forge.fedoraproject.org/quality/os-autoinst-distri-fedora/commit/b04c4040b48281be081ff2e0a62543a015fc1d4e . Based on that investigation I think it's probably not worth worrying too much about this - there does seem to be a real behavior change / issue, but I suspect it's unlikely to cause noticeable issues for real-world setups.