| Summary: | After switching audio devices using the radio buttons, sometimes both the old and new devices' buttons get stuck in a "selected" state | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Aaron Liu <aaronliu0130> |
| Component: | Audio Volume widget | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | 1997cui, 89q1r14hd, anton, hypertextcoffee, info, isma.af, john.kizer, mariusz.libera, nate, nicolas.fella |
| Priority: | HI | ||
| Version First Reported In: | 6.3.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Multiple playback and recording devices' associated radio buttons being selected at once | ||
I'm here from #archlinux-testing on Libera IRC, it works for me correctly and deselect others. Operating System: Arch Linux KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.12.17-hardened1-1-hardened (64-bit) Graphics Platform: Wayland Processors: 12 × 12th Gen Intel® Core™ i5-1235U Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics I think it has to do with Qt6; Amin has Qt 6.8.2 while I have 6.9.0beta3. Can also confirm issue on Fedora 44. Plasma 6.3.2 KDE Framworks 6.11.0 QT 6.8.2 Kernel 6.13.5 Wayland (In reply to george from comment #3) > Can also confirm issue on Fedora 44. > Plasma 6.3.2 > KDE Frameworks 6.11.0 > QT 6.8.2 > Kernel 6.13.5 > Wayland Sorry, F41 not F44. ...that would invalidate my Qt 6.9 hypothesis, even though that aligns with my upgrade timeline more... (I have Arch's kde-unstable testing repos, which shipped Plasma 6.3.2 a ways before the problem started.) I can reproduce this on my Fedora KDE 41 device: Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.3 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.13.7-200.fc41.x86_64 (64-bit) Do you have a 100% reproducible case? I can *sometimes* reproduce it, but have thus far been unable to figure out the pattern. I don't know how generalizable it is, but: * I can't reproduce it on any of my three output devices, which are all "plugged in" * I can 100% reproduce it by trying to switch input devices from my USB headphones to the motherboard's built-in microphone port, which is noted as "unplugged" in the Sound KCM...perhaps it has something to do with an attempted change getting rejected because there's nothing attached? (Total guess, sorry!) When I reported this this was always reproducible. Now it seems to be fixed.. *** Bug 504640 has been marked as a duplicate of this bug. *** (In reply to Aaron Liu from comment #9) > When I reported this this was always reproducible. Now it seems to be fixed.. Reproduced with latest KDE neon dev (neon-unstable-developer-20250512-0038) https://youtu.be/Wn-yM_cnkAE?t=49 (bug appears on 0:49) I"m quite sure there's an already open bug about this. But in light of how relatively common this is, perhaps plasma-pa could provide a better UX. My suggestion is to not toggle the radio button immediately but rather have a spinner or similar next to the sink/source or, if possible, as a custom radio button that's flashing or spinning to indicate an attempt to switch the default but only show the fully selected radio button after the default sink or source has actually changed. Unfortunately I do not know where exactly it gets stuck or how that shows up, just that having multiple default sinks or sources in plasma-pa is often due to the audio manager (WirePlumber or the legacy Pulseudio) having bugged out. I think it would be much simpler to grey everything out (and maybe add a spinner overlay). *** Bug 484908 has been marked as a duplicate of this bug. *** *** Bug 513535 has been marked as a duplicate of this bug. *** Oh, that's neat. Mariusz, if you happen to encounter this again, can you maybe check the output of `wpctl status`? It would be interesting to see, if that tool is reporting the correct state (the default sink and source have * prefix to their listings) and whether it's possible to use `wpctl set-default <id>` or `wpctl clear-default <id>` to return to a sane state or not. The id should be the same as what wpctl showed for its list command.
Also I think when I last encountered this, it was possible to recover by restarting the audio stack instead of Plasma, which on Arch is done with `systemctl --user restart pipewire{,-pulse}.socket`, assuming you're using the PipeWire audio stack.
(In reply to Niklāvs Koļesņikovs from comment #16) > Oh, that's neat. Mariusz, if you happen to encounter this again, can you > maybe check the output of `wpctl status`? It would be interesting to see, if > that tool is reporting the correct state (the default sink and source have * > prefix to their listings) and whether it's possible to use `wpctl > set-default <id>` or `wpctl clear-default <id>` to return to a sane state or > not. The id should be the same as what wpctl showed for its list command. > > Also I think when I last encountered this, it was possible to recover by > restarting the audio stack instead of Plasma, which on Arch is done with > `systemctl --user restart pipewire{,-pulse}.socket`, assuming you're using > the PipeWire audio stack. `wpctl status` displays the correct status matching System Settings Sound kcm. `wpctl set-default` functions correctly, but neither it nor `wpctl clear-default` fixes the applet. using `systemctl --user restart wireplumber.service` fixed the applet, but maybe it also restarts pipewire as a dependency? So far I don't even know what triggers this bug. |
Created attachment 179046 [details] Multiple playback and recording devices' associated radio buttons being selected at once SUMMARY In the audio widget's devices tab, the radio buttons (circular checkboxes) are not and cannot be deselected. This is a purely visual problem. STEPS TO REPRODUCE 1. Attach multiple playback devices or multiple recording devices 2. Select an unselected audio device OBSERVED RESULT While we do switch to the selected audio device, the old device's radio button is not cleared. EXPECTED RESULT The old radio button is cleared. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Operating System: EndeavourOS KDE Plasma Version: 6.3.2 KDE Frameworks Version: 6.11.0 Qt Version: 6.9.0 Kernel Version: 6.13.5-zen1-1.1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 2700X Eight-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series ADDITIONAL INFORMATION A similar thing happens in sound system settings, though this time the radio buttons do not select instead of not deselecting. No other radio buttons I've found have any of these problems.