If a GDM user connects a bluetooth headset, then the user's pulseaudio does not pick up the connected bluetooth device and it does not appear in the users audio mixer. This happens because GDM captures the bluetooth device on session start, because GDM needs pulseaudio in its login session for accessiblity (for example the screen reader requires it, see debian bug ). Bluetooth headset is connected, but ALSA/PulseAudio fails to pick up the connected device or there's no device to pick. This happens because GDM captures A2DP sink on session start, as GDM needs pulseaudio in the gdm session for accessibility. For example, the screen reader requires it. This can be fixed by providing a the following pulseaudio configuration to gdm by creating a file named /var/lib/gdm3/.config/pulse/default.pa with the following content: --- #!/usr/bin/pulseaudio -nF # load system wide configuration .include /etc/pulse/default.pa ### unload driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so unload-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so unload-module module-bluetooth-discover .endif --- Ebuilds >=gnome-base/gdm-3 should consider installing this file per default. Further references - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805414 - https://wiki.archlinux.org/index.php/Talk:Bluetooth_headset#GDMs_pulseaudio_instance_captures_bluetooth_headset - https://wiki.debian.org/BluetoothUser/a2dp (Woraround 2)
Some more related issues: - https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/303 - https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1703415
I think this is basically a duplicate of bug 642198, but more complete, so I might mark it the other way around. Though that issue was about DNS-SD issues, not bluetooth. Note that this is probably not such a big problem anymore with gdm-3.30 + wayland: gdm shuts down the gnome-shell session after you've logged in (but I guess theoretically there could be issues with it happening a little bit after user pulseaudio has started?). Doesn't mean we can't try to fix things regardless, but I don't see how we cleanly can, if we want to keep accessibility in mind, and we do. It can be hard to log in if you need screen reading to a bluetooth audio device.
(In reply to Mart Raudsepp from comment #2) [...] > Note that this is probably not such a big problem anymore with gdm-3.30 + > wayland: gdm shuts down the gnome-shell session after you've logged in (but > I guess theoretically there could be issues with it happening a little bit > after user pulseaudio has started?). Doesn't mean we can't try to fix things > regardless, but I don't see how we cleanly can, Indeed, it seems it won't affect Wayland users per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805414#122 > if we want to keep > accessibility in mind, and we do. It can be hard to log in if you need > screen reading to a bluetooth audio device. Personally I would wait a bit more to see if this is fixed in pulseaudio side with: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/merge_requests/10 If that gets stuck more months (I hope that not), maybe we could apply the workaround when USE "-accessibility" is set, I know it's a workaround and not optimal, but it would be better than forcing people to apply random workarounds they find when they suffer the problem
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f2394513fd33929540f0fe6c5500b41094038d29 commit f2394513fd33929540f0fe6c5500b41094038d29 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2019-05-05 11:31:53 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2019-05-05 11:53:57 +0000 gnome-base/gdm: workaround file perm and bluetooth sound issues Install a pulseaudio default config file which unloads bluetooth modules, to avoid logged in users failing to load these modules upon log-in due to device locks. As bluetooth sound may be important for a11y screen reader over bluetooth sound, a USE flag is provided to keep loading bluetooth modules; as this shouldn't be a common case (especially as normal sound still works, it's just about sound over bluetooth), this USE flag is default disabled. Add back file ownership tweaks, as users still somehow end up with wrong permissions. At least if the path where Xorg sessions log file gets written has wrong permissions, Xorg fails to start and gdm with it. Bug: https://bugs.gentoo.org/679526 Closes: https://bugs.gentoo.org/669146 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Mart Raudsepp <leio@gentoo.org> gnome-base/gdm/files/default.pa | 18 +++ gnome-base/gdm/gdm-3.30.3-r3.ebuild | 246 ++++++++++++++++++++++++++++++++++++ gnome-base/gdm/metadata.xml | 3 + 3 files changed, 267 insertions(+)
Bug left intentionally open to track a proper fix instead of this workaround
