Date: Mon, 3 Jul 2017 10:27:36
From: Felipe Sateler <email@example.com>
To: Antoine Beaupr? <firstname.lastname@example.org>,
Cc: Michael Biebl <email@example.com>, firstname.lastname@example.org,
Aurelien Jacobs <email@example.com>
Subject: Re: Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP
sink on session start
Resent-Date: Mon, 3 Jul 2017 14:28:34 +0000 (UTC)
Adding the a11y list to CC.
Dear a11y team, a short summary for you: Currently, pulseaudio does not
negotiate bluetooth devices the same way it does with alsa devices, with a
result that is undesirable: if the gdm login screen grabs the BT device, it
becomes unavailable in the logged in session. The change being discussed
here is to disable bluetooth in the gdm login screen.
On Mon, Jul 3, 2017 at 10:20 AM, Antoine Beaupr? <firstname.lastname@example.org> wrote:
On 2017-07-03 15:46:20, Michael Biebl wrote:
Am 03.07.2017 um 00:05 schrieb Antoine Beaupr?:
On 2017-07-02 23:43:55, Michael Biebl wrote:
Am 02.07.2017 um 23:36 schrieb Antoine Beaupr?:
On 2017-07-02 23:16:19, Michael Biebl wrote:
Have you tested the workaround from the arch wiki and can you
I cannot, unfortunately, test this anymore, as I have disabled the
pulseaudio socket as directed earlier, with:
I don't know what that was pointing to, so I can't quite restore that
That's from the postinst:
if ! [ -L $USERUNITDIR/sockets.target.wants/pulseaudio.socket ]; then
mkdir -p $USERUNITDIR/sockets.target.wants
ln -sf $UNIT $USERUNITDIR/sockets.target.wants
You can run that manually or simply re-install the gdm3 package so that
code is run again.
Thanks! I believe I have rolled back the workarounds and implemented the
fix default.pa documented in the Arch wiki. Everything seems to work
normally now, ie. I can correctly connect through A2DP to my bluetooth
Since concerns were raised that this might break existing a11y setups, I
don't plan to make an upload with this change.
I don't understand the impact this could have regarding
accessibility. There are, as far as I know, currently no usable way to
have bluetooth audio working at all in the gdm3 login prompt, because
there's no way to associate a device, so there's no loss of
functionality here. But there *is* a loss of functionality for
everyone (*including* screen reader users) *after* the user is logged
in: they cannot correctly configure bluetooth devices!
Bluetooth pairings are global. Once you configured them in your user
session, they will become available to gdm too.
Can we get a better idea of the use case you are worried about here?
Here is where the input of the a11y team would be very appreciated. Is
disabling bluetooth in the login screen likely to cause problem?
To be really clear here, the change I am proposing is the one documented
in the Arch wiki and now also in the Debian wiki:
which currently consists of adding the following
# load system wide configuration
### unload driver modules for Bluetooth hardware
How would this break accessibility?
My own thought is that if your only speakers are BT, how are you going to
have the screen read if there is no BT?