On a recent linux system, with PA started up, launch libreoffice -impress.

This means that if one stopped PA, started Impress and then restarted PA, then it would be PA to fail the binding, even if LibO is not yet using it. When impress starts, it immediately tries to bind to the RFCOMM channel 3 even before a presentation is being started and without a switch to control this behavior. Incidentally, I think that there is the same issue on the Libreoffice side. Is there any need from PA to bind to channel 3 even when there is no BT connection to any device? If, in general, it cannot be possible to 'automatically' bind only when needed, would it be possible to provide a switch on the DBUS interface to manually activate/disactivate this binding? However, it is unclear to me why pulseaudio needs to stay bound to the channel unconditionally. This other process is PulseAudio: apparently the HS profile needs the RFCOMM for the AT Commands and registers channel 3.

However, in the last couple of years, when impress tries to bind to the channel it fails because another process has already bound that channel via DBUS. It looks like the impress remote works in bluetooh mode by using the default channel (3) for the RFCOMM protocol. However the problem has recently been diagnosed (By Felix Huber, if you follow the thread in the bug report). The issue has been open on Libreoffice for a long time now ( ). Impress is the presentation program in Libreoffice and the impress remote is a way to control the presentation from a mobile phone by means of an application. For the last couple of years it has been impossible to use the 'impress remote' over bluetooth on linux systems.

Impress linux