...so it could happen that both the main thread at
> internal_bus_get
> dbus_bus_get_private
> avahi_dbus_bus_get
> avahi_client_new
> sd::AvahiNetworkService::setup
> sd::DiscoveryService::DiscoveryService
> sd::DiscoveryService::setup
> SdDLL::RegisterRemotes
[...]
as well as the thread
> internal_bus_get
> dbus_bus_get
> dbusConnectToNameOnBus
> sd::BluetoothServer::run
> threadFunc
> osl_thread_start_Impl
> start_thread
spawned from the main thread at
> sd::BluetoothServer::setup
> sd::RemoteServer::setup
> SdDLL::RegisterRemotes
[...]
are in D-Bus's internal_bus_get simultaneously (with disastrous consequences,
like SEGV) despite the _DBUS_LOCK(bus) there, unless you previously called
dbus_threads_init_default. (Which the D-Bus documentation makes you believe can
be called from multiple threads, though a look at the implemenation makes it
clear that it really should be called from the main thread before any other
threads are created---which we still don't do; oh my.)
Other places that (indirectly) use D-Bus (tubes/source/file-transfer-helper.c,
vcl/generic/fontmanager/fontconfig.cxx, vcl/unx/gtk/window/gtksalframe.cxx might
need this, too.
Change-Id: I912829c615b46b05a89c07bd044b04f1e5f5e7ba
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Allows LibreOffice to start with no bluetooth, and for it to
appear and disappear dynamically at run-time, cleaning up stale
bluetooth sockets, and re-binding successfully each time.
Change-Id: Ifa04c8cc1859c98adca94ac0e57c7ebd85f2f31f
Sure, each SAL_INFO output line includes the thread ID, but still,
good to avoid confusion from where this line is coming.
Change-Id: Idc531640e661ed363c7badbad8b83fbb43eaf3ad
Mostly the work of Thorsten, from December, adapted to compile against
the current remote control code, and with one or two crucial things
added. Plus lots of SAL_INFO calls added; once it works well many of
them can be dropped. Does not work properly yet, do not cherry-pick
just this to 4.0.
Change-Id: I53361b49a2b6938c768be1ea0fc17eb5e46b6aa4
I meant to do this for 4-0, not for master, as the commits mentioned in the message
show, this is not needed in master.
This reverts commit b60ccd4d4d.
Caused by 185e1be6cd1954b8cc5a302c879384f2549cd060,
fix is more or less d0d07cd297.
Change-Id: Ia7d228139126b3e60370b85c106bc970f4e68cce
Reviewed-on: https://gerrit.libreoffice.org/2154
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
Work in progress. It sets up the SDP service record and registers it,
and that seems to work. Does not do anything with it yet.
I wonder if the current approach to use the standard SerialPort
service class will work for Macs, as they by default have one
SerialPort service running, "Bluetooth-PDA-Sync", whatever that
is.
There is no code in the Android app to handle the case of there being
several Serial Port services on the computer it wants to connect to,
so what happens then when there are two will be interesting to see.
(I can't find in the Android API any way to enumerate services that
use the same service class. If there was, the app could choose the
correct one based on its name.)
So probably we should pretty soon switch to using a dedicated service
class UUID instead of using the standard serial port one. As we
already have the app out in the wild it will probably have to be
modified to look for both Serial Port and our own service then? Sigh.
Change-Id: I1bee6403642e9b8953b5a8fa8fb5fe6a9dc76a09
This reverts commit 0743ccea54.
This seems to be unnecessary and generates a lot of warning spam.
Conflicts:
sd/source/ui/remotecontrol/BluetoothServer.cxx
Change-Id: Ib0cda3ca560a5ddc4ba86d5a0c80774a992d7296
