On Wed, 2018-04-04 at 18:53 +0200, Pali Rohár wrote: > On Wednesday 04 April 2018 16:47:57 David Woodhouse wrote: > > I've now counted three types of headset control that we should support, > > ideally through a consistent interface. > > > > > >  � The first is Bluetooth HFP/HSP for which support is already present > >   and just needs to be connected up. > > > >  � Second is the USB HID devices, including most "Skype for Business" > >   certified headsets. I have a Pidgin plugin which drives these > >   directly, but it would be better for PulseAudio to open the HID > >   device for itself and for the controls to be associated with the > >   specific hardware. > > > >  � Third is the Android/etc. 3.5mm jack where button presses are > >   implemented as short-circuit or specific resistances from the mic > >   pin to ground: > >   https://source.android.com/devices/accessories/headset/plug-headset-spec > >   The Linux kernel has support for these (at least for a few codec > >   chips), and they appear as events on an input device along with the > >   jack insertion/removal events. Which I note we also don't support in > >   PA yet? Although there were patches in 2011 at > >   https://www.mail-archive.com/pulseaudio-discuss at mail.0pointer.de/msg09830.html > > > > > > Are there any more? Thanks. > Nokia ECI headsets - 3.5mm jack with bi-directional ECI bus on MIC bias. > In most cases those headsets contain buttons, but ECI bus supports also > some memory read/write operations. But IIRC it is not possible to use > them with ordinary sound cards (activating MIC bias is too slow for ECI) > and Nokia implemented ECI protocol in their phones at ASIC level, some > translation of ECI to I2C. ECI protocol itself is undocumented, but I > saw some images from oscilloscope from which protocol could be decoded. That one I think is a kernel problem. If implemented in Linux, it would presumably end up appearing to userspace just the same way as #3 above, with a separate input device emitting events for the button presses. Userspace doesn't necessarily need to care, right? > Other Nokia headsets (non-ECI) - again 3.5mm jack, but supports only one > button press. Maybe similar to your "third" one. Yeah, probably. And either way, I think it's still the kernel's problem to work out the hardware details and just emit events. > Bluetooth A2DP with AVRCP - but this should be already supported. With the possible exception of volume control, I suspect AVRCP support is mostly outside the scope of PulseAudio. For volume controls we might want to ensure that they affect the *correct* device volume, in the A2DP+AVRCP case where there clearly is a "correct" device. But not the case of a pure AVRCP remote control. We have this problem with volume control on USB headsets already. They provide a HID device which emits KEY_VOLUMEUP / KEY_VOLUMEDOWN events. So right now as I'm listening to a podcast on my headset, if I press a volume button not only does it immediately change the headset volume, but the system *also* sees that "keypress" and adjusts the volume of the laptop's built-in speakers too. Which is wrong. That volume keypress should have been handled in the context of the device it came from. We *do* get that right for HFP, I believe. Other than volume control, the main common headset control features are:  � on/off hook.  � mute (mic).  � ring  � Additional feature button(s) At least for the SfB-certified USB headsets, the hook and mute controls need management. When the mute/hook buttons are pressed, userspace has to update the mute/hook status on the device accordingly, otherwise things don't work right (subsequent presses are ignored, etc.). I suspect the correct approach is revive the patches which opened the input device for the jack, then do something similar to open the HID dev associated with a USB headset. Then to define hook/mute/ring properties and get signals working on the PA side, and hook that up to at least the GStreamer pulses{rc,ink} elements. Then applications like Pidgin and Ekiga can do a saner version of the headset management, through GStreamer. -------------- 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/903904bb/attachment.bin>
