On Fri, 2018-04-06 at 14:05 +0200, Pali Rohár wrote: > This opens question about another problem: Who, how and when should > handle events from input devices? Integrated PS/2 keyboard on laptop is also > input device, external USB (or PS/2) keyboard on desktop is also input > device. And they could have also MIC_MUTE or MUTE buttons. Should these > buttons mute all sound cards? Or only those which are "integrated" (e.g. > not bluetooth headsets)? And who should handle these mute buttons? > Pulseaudio? Desktop hotkey daemon (e.g. KDE has own)? Or some new daemon > for these actions? Because currently e.g. KDE already handles mute > buttons/keys by its own. I think those â?? generic input devices which aren't associated with a specific audio device â?? are fine as they are, being handled by the desktop as you say. But I think device-specific controls are different, and should probably be handled through PulseAudio. Right now I have a Pidgin plugin¹ which opens any USB HID it can find, and then treats that as "the" headset for a call regardless of which audio device is actually in use. Which is clearly wrong, and is the underlying reason for me starting to look into how to do this "properly". > I agree with you, that mic mute button on USB/bluetooth headset should > mute just microphone on that headset. It's actually a bit more than that. Muting was the main reason I started looking in to this, in fact. Conference protocols have a network-level 'mute' where the software actually stops sending audio frames. Previously, if a user muted the headset then they wouldn't appear as "muted" on the call; they'd just be sending audio frames which happened to contain a lot of zeroes. And if the user was muted in software (by the conference organiser or the client UI), pressing the headset mute button didn't ummute them on the wire. Now it all works correctly. For Bluetooth HSP devices, it looks like this might *already* work through PA+GStreamer. There's a "mute" property on the gstpulsesrc element, which I ought to be able to monitor and set within the Pidgin GStreamer pipeline to coordinate with the protocol-level mute status. Given that, it seems to make a lot of sense to do it that way for the HID/jack devices too. It means the application doesn't have to attempt to match the discovered HID/input devices to the audio device in use in the pipeline, and it also makes the permissions on those device nodes easier to handle. ¹ http://git.infradead.org/users/dwmw2/pidgin-headset.git -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180406/933f9911/attachment.bin>
