Still present in 6.2.0 RC 1

Can confirm on Arch Linux with LO version 6.2.3.2

Thank you for reporting the bug.
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build

Cannot test daily builds right now, but 6.3.0 beta 1 still has the issue.
Launching impress reports:
bluetoothd[1386]: RFCOMM server failed for LibreOffice Impress Remote: rfcomm_bind: Address already in use (98)
in the system logs and then the remote app cannot contact the host.

Issue persists with current LibO 6.3.1.2 and most likely due to the fact that the bluetooth stack on linux (bluez) has changed in the past years and impress has not cought up.

Problem is now more visible due to the startup tooltips in Impress 6.3.x which explicitly introduce the impress remote functionality inviting the users to test it. Goes like: start Impress -> see tooltip -> get interested -> download and install phone app -> try -> fail -> get disappointed and remove phone app.

Because the phone based remote is one of those little things with a great wow factor that makes LibO really shine out and amaze people when used in front of an audience, it would really be great if the functionality could be restored. It is literally a little big thing helping getting a foot in the door.

In fact, I suppose that if one could also add a "spotlight" and "zoom" functionality in it (in addition to the pointer) and the ability to use the phone accelerometers for moving the pointer (in place of the finger on the screen) it would make LibO a serious contender for all those coveting the "Logitech spotlight" that is currently the hot thing in presentations selling for over $100. See also https://github.com/jahnf/Projecteur .

Wonder if it could be useful to kindly ask Andrzej Hunt if he can look into the issue. If I am not wrong he is the author of the current bluez 5 code in Impress.

Issue still present in LibO 6.4.3.1.

I see the bug as still unconfirmed after more than one year. I wonder if it could be confirmed, given that the same issue has also been reported for redhat (https://bugzilla.redhat.com/show_bug.cgi?id=1581879)

The bug is also confirmed in the ubuntu launchpad at https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1798400.

Users there are reporting that they are experiencing the issue in ubuntu (from bionic, I think) and gentoo. This adds to the reports in fedora and to the confirmation here on arch linux.

I think that this is enough to mark as "NEW"

Andrzej, I am CC-ing you on this, because I believe that you were one of the original corder of the BT code for the impress remote on linux. I hope that you may able to provide some advice on this. If I'm wrong, please take my apology for the noise.

Can confirm that my samsung galaxy running Android 9 and linux mint 19.3 are still not working appropriately with the impress remote. It refuses to connect via bluetooth no matter what I do.

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.

Thanks for the analysis!

From it, I still wonder whether this is a pulseaudio bug, though. Why is pulseaudio ever binding to RFCOMM channel 3 *before* there is any need to do so? That is, until I am not connected to any device using channel 3, why is pulseaudio already using it up?

In other words, it seems reasonable to me to have the laptop connected to the phone as a headset and in this case not to have the impress remote working. But in case I start impress before setting up a bluetooth connection to the phone, why should be the pulseaudio binding already there?

The premise is that my ignorance on BT is complete. After some investigation, it is my understanding that RFCOMM channels are to RFCOMM communication a bit like ports in TCP and UDP, with the main difference that while there are really a lot of TCP/UDP ports and some of them are reserved as "well known ports", the number of channels in RFCOMM is extremely limited, so that there cannot be well known ports. Furthermore, I understand that no one should "hardwire" RFCOMM channels and that channels should be released whenever not strictly needed.

If this understanding from myself is correct, there may be issues both in LibO and in PA.
From my understanding:

- LibO and the Impress remote should not hardwire RFCOMM channel 3. I understand that they should dynamically allocate a channel and make it discoverable via SDP.

- Impress should not keep binded to an RFCOMM channel all the time. There should be a visible option to switch on and off the binding (probably there should be a couple of impress remote related options in the "Slide Show -> Slide Show Settings" window, including one to fire up the BT rfcomm binding).

- PA should probably similarly not hardwire channel 3 for its HSP role, but here the situation seems more complex, because it may be the case that PA needs to strive for compatibility with devices that do not play to the rules.

- PA should probably have a DBUS interface to switch on and off the RFCOMM binding, so that to use an application needing RFCOMM channel 3, one does not need to take down the whole of PA.

I have opened a bug on PA too. See it at  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/827.  That report is bad, because when I made it my understanding of BT was even poorer than it is now.

In any case, it seems to me that the current issue could be fixed completely on the LibO side, by dynamically allocating the channel and by letting the app running on the phone discover it via SDP.

The bug is still there as of LibO 7.3.x. Up in comment 12 (https://bugs.documentfoundation.org/show_bug.cgi?id=120663#c12) there is a nice analysis of the underlying problem why the remote cannot work.

Established that, I think that most users go used to the fact that the remote functionality does not work in linux. Personally, I have uninstalled the android app on the phone so I do not have an unfortunate reminder about it. In fact, the real issue is probably the advertisement of a functionality that is not there.

For the time being I suggest disabling the remote-via-bluetooth functionality in linux and closing the bug by simply saying that the remote via bluetooth cannot be supported on linux where there are evidently issues that span other software pieces such as the bluetooth stack and pulse audio. To the best of my understanding, these involve the hijacking of the default rfcomm channel by pulse audio before it even needs it and the lack of a standard approach to let other applications find a free channel to use and advertise it to their counterparts.

Alternatively (but I would not consider this a good solution), the configuration options could be enhanced to add the possibility to choose a bluetooth channel in libreoffice and in the mobile phone application, so that the user can manually work around the fact that the predefined channel is locked by some other application.

As a final point, note that even if the remote-via-wifi may seem a good alternative, in fact in most cases it is practically useless.  In most cases, presentations will not be given at a place where you control the network, but at sites with site-provided wifi, such as universities, schools, conference places, business sites, etc. All these locations tend to have wifi deployments that block stuff on the ports used by impress remote.

Noticed that among the many tips of the day, LibO also suggests to use Android or IPhone to remotely control an Impress presentation.  The "more info" page then excplicitly declares that the feature is cross platform "GNU/Linux, Windows or macOS." either via Bluetooth or Wifi.

However to use the feature with bluetooth on linux has been impossible for the last 5 years, because the feature is broken on this platform (this bug provides a diagnosis of the underlying issue). Using the feature with wifi is equally problematic, because those places where you need to deliver a presentation are typically those very places where you do not control the wifi network that may make it impossible for the computer and the phone to communicate.

As a consequence, this tip of the day looks inappropriate on linux, making many users waste a significant amount of time trying to use a feature that simply cannot work. May I suggest removing this tip of the day on linux?

Noticed that in the forthcoming LibO 24.2, the "remote" is being given prominence, by moving its settings from the Tools ▸ Options ▸ LibreOffice Impress configuration dialog to the Slide Show ▸ Slide Show Settings menu.

IMHO this makes it quite important to have this feature working as intended on all the supported platforms.

The remote is meant to work either with a WIFI connection or a Bluetooth one.

The current bug is about the Bluetooth connection. 

Bluetooth Connection
--------------------

As of today, because of the issue at hand, the Bluetooth connection is completely unusable on standard Linux distributions that use Pulseaudio (a detailed discussion why is in the previous comments).

Notwithstanding the fact that this but is about the Bluetooth connection, I am providing also a few notes about the Wifi connection to highlight why the Bluetooth connection is so important and should be fixed.

WIFI Connection
---------------

Unfortunately, the WIFI option is practically unusable in almost every professional working environment, including universities and conferencing sites. This is because in all these environments the network is completely out of the user control, restricted in any possible way, heavily firewalled, with the wifi framework consisting of multiple access points under the same SSID. In a similar arrangement the possibility of the remote to reach LibO at a non-standard TCP port is erratic if not negligible.

The impossibility to use the WIFI connection precisely in those real world environments where the usage of the remote would be most important is the reason why a working Bluetooth connection is needed.

Note that in practice the WIFI connection situation could be improved by suggesting the possibility to let the presenter laptop connect to the internet via the mobile phone hotspot. This would need the remote app to try to connect to LibO not just via the phone default interface, but also on the network used for the hotspot.