SUMMARY Currently, the mute key on the keyboard triggers global mute on all devices. The mute key should only mute the active or default device to more closely emulate the behavior on other platforms. I frequently mute my monitor's speakers when I intend to use my headphones or my USB headset to avoid accidentally having loud music or Youtube videos blaring out of it waking up my family in the middle of the night. Having global mute be the default action for the mute button is very frustrating as it messes with devices that I don't want to touch whenever I want to mute the monitor. It also makes the "Force mute all playback devices" menu option totally redundant. On Windows and Gnome, the mute button only mutes the selected default device. KDE should adhere to the standard. Plus, when new devices are added while global mute is enabled, the mute behavior becomes an inconsistent mess, with some devices being muted/unmuted while others are not. STEPS TO REPRODUCE 1. Press mute hotkey 2. Notice that all audio playback devices are muted, not just the default one. EXPECTED RESULT Mute hotkey should only mute the active (default) device. Perhaps another hotkey (Shift + Mute) can act as global mute. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.21.2 (available in About System) KDE Plasma Version: 5.21.2 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2
For me it only does mute the default devices, not all devices. Can you attach a screen recording showing with the applet open what happens when you hit the mute key? Also what kind of keyboard is it? Brand/manufacturer etc. Finally please run `xev`, press the mute key, and let us know what keycode is being transmitted. On mine, the keycode is "keycode 198 (keysym 0x1008ffb2, XF86AudioMicMute)"
I note that you mentioned in Bug 434218 that you're using PipeWire rather than PulseAudio. Is that true here too? If so, does it work correctly when you use PulseAudio instead of PipeWire?
Created attachment 136567 [details] Applet when mute key is pressed Here's the `xev` output: KeyRelease event, serial 43, synthetic NO, window 0x8000001, root 0x1d2, subw 0x0, time 41796751, (1335,862), root:(1335,891), state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False I've noticed on yours it says mic mute. Maybe your mute is for your microphone instead? See attached for the requested screenshot. I'll test Pulseaudio in a bit.
Oh my mistake, I'm so sorry. I thought you were talking about the mic mute key, not the output device mute key. I can confirm that it mutes all devices, not just the default one. This seems to be intentional, but of course that intention may be problematic. :)
If it is intentional, then I propose that this behavior be changed to be more inline with other platforms. Windows, Mac, and Gnome do not do this AFAIK. I also understand that just like bug 432487, the intention here could be to bias towards a simple use case, but this behavior very quickly devolves if users have more than one audio device, which is very common today with HDMI, USB, and Bluetooth devices becoming more and more popular. Here's what I propose: 1.) Mute hotkey should by default only mute default device to match other platforms 2.) The "Force mute all playback devices" menu entry should be a separate "Mute All" icon instead of being hidden in the "More actions" hamburger menu. 3.) "Mute All" should get its own hotkey. I propose "Shift-Mute" if possible. 4.) (Optional) The new "Mute All" icon should display the new hotkey in its tooltip to aid in discovery. 5.) Expose new "Shift-Mute" hotkey in Global Shortcuts settings so that people can swap the behavior if they want to. Additional UI clean up: 1.) "Configure Audio Devices" should be moved out of the "More actions" menu as a separate icon as that's actually a frequently used feature for people who need to switch between HSP/A2DP modes on their Bluetooth headsets. "More actions" will be empty and therefore should be removed. What do you think Nate? Also, sidenote, how much dev effort is going into the Plasma PA widget and are they currently too busy with other tasks? I am a former software dev looking to get back into the swing of things and would love to knock off these types of low hanging fruit if needed. However, I am unfamiliar with KDE development and will probably need a few pointers to get started. Let me know if I can help.
Your proposal seems reasonable to me. We do only mute the default microphone, so having the same behavior for muting output devices makes some sense. plasma-pa is chronically short on dev time, so your efforts would be much appreciated! The best way to get started would probably be to read through https://community.kde.org/Get_Involved/development and get a dev environment set up. I'd be happy to help.
Sounds good. Thanks for the link, Nate. I'll setup a development VM and get back to you.
Sorry for the delay, but I've finally got around to setting up a KDE dev environment on a VM and it is all working now. I will start looking through the source code and attempt a fix. To avoid cluttering up this bug report with logistical questions, would the best way to reach you be via the webchat.kde.org Matrix server?
So I've been looking through the source code and I believe that the main file I need to modify is $(KDESRC_BUILD_DIR)/src/plasma/plasma-pa/applet/contents/ui/main.qml. However I can not for the life of me figure out where it goes when I build the project. The plasma-pa Arch package also doesn't seem to include this file and I can't find this file anywhere on my system. Perhaps, I am just not very familiar with how the KDE project is laid out, but if someone could point me in the right direction, it would be greatly appreciated!
feel free to ping me on matrix directly or try the kde-devel room. :)
Apologies for the slow progress on this, but I have made a really quick and small patch for a single device mute behavior. Here's the WIP merge request: https://invent.kde.org/plasma/plasma-pa/-/merge_requests/60 Nate, there's two things I would like to ask for clarification on. They're both described in detail in the merge request.
No problem at all! Thanks for working on it.