Comment 23 for bug 1798400

This issue was annoying me for a while too. So I sat down and debugged bluez to see why the bind fails: LO is using the default channel (3) for the RFCOMM protocol as it should be. However, the bind call fails, because another process has already bound that channel via DBUS. Changing the default RFCOMM channel in the bluez source temporaliy to 2 (UDP, unused) and recompiling bluez made remote impress work immediately!

So I inspected the DBUS users via the old mdbus tool from openmoko and it turned out that the other process is PulseAudio: The HS profile needs the RFCOMM for the AT Commands and registers channel 3. Stop PA and impress remote works again.

So now we have two programs that need RFCOMM for the mobile phone. :-(
One solution would be that LO explicitly requests channel 2 instead of the default one. Channel 2 is UDP and unused to my knowledge. This will work until another programm needs RFCOMM and chooses 2 as a free channel...

Or, in the long run, there needs to be some kind of multipexing between the apps that use the RFCOMM protocol.