mirrors/pipewire
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/pipewire/pipewire.git synced 2025-11-03 09:01:54 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

bluez5: don't probe native backend presence

Browse source 
Don't do a blocking probe of native backend presence, because it may
trigger DBus activation for Bluez.  If the DBus activation fails, it
ends up blocking until timeout.

ofono/hsphfpd usually don't have DBus activation configured, so they
fail instantly (which is why this problem was not encountered, even
though they do blocking calls on startup in previous pipewire versions
too).

Instead, select the backend once we have Bluez objects listed.
This commit is contained in:
Pauli Virtanen 2021-09-24 22:50:34 +03:00 • committed by Wim Taymans
parent 40487e485d
commit 0af3c85806
2 changed files with 3 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

5
spa/plugins/bluez5/bluez5-dbus.c
View file

@ -3546,6 +3546,8 @@ static void get_managed_objects_reply(DBusPendingCall *pending, void *user_data)
dbus_message_iter_next(&it[1]);
}
reselect_backend(monitor);
monitor->objects_listed = true;
finish:
@ -4146,12 +4148,11 @@ impl_init(const struct spa_handle_factory *factory,
register_media_application(this);
/* Create backends. They're started after we get a reply from Bluez. */
this->backends[BACKEND_NATIVE] = backend_native_new(this, this->conn, info, this->quirks, support, n_support);
this->backends[BACKEND_OFONO] = backend_ofono_new(this, this->conn, info, this->quirks, support, n_support);
this->backends[BACKEND_HSPHFPD] = backend_hsphfpd_new(this, this->conn, info, this->quirks, support, n_support);
reselect_backend(this);
return 0;
fail: