[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#805414: gdm3: disable pulseaudio to prevent capturing A2DP sink on session start



What happens to someone who only has a bluetooth keyboard and has a bluetooth dongle connected to their computer to use bluetooth temporarily since their usb keyboard broke?

On Mon, 3 Jul 2017, Felipe Sateler wrote:

Date: Mon, 3 Jul 2017 10:27:36
From: Felipe Sateler <fsateler@debian.org>
To: Antoine Beaupr? <anarcat@debian.org>,
    debian-accessibility@lists.debian.org
Cc: Michael Biebl <biebl@debian.org>, 805414@bugs.debian.org,
    Aurelien Jacobs <aurel@gnuage.org>
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)
Resent-From: debian-accessibility@lists.debian.org

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? <anarcat@debian.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
confirm it
works?

I cannot, unfortunately, test this anymore, as I have disabled the
pulseaudio socket as directed earlier, with:

rm /var/lib/gdm3/.config/systemd/user/sockets.target.wants/
pulseaudio.socket

I don't know what that was pointing to, so I can't quite restore that
behavior directly.

That's from the postinst:

UNIT=/usr/lib/systemd/user/pulseaudio.socket
USERUNITDIR=/var/lib/gdm3/.config/systemd/user
if ! [ -L $USERUNITDIR/sockets.target.wants/pulseaudio.socket ]; then
  mkdir -p $USERUNITDIR/sockets.target.wants
  ln -sf $UNIT $USERUNITDIR/sockets.target.wants
fi

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
speaker.

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:

https://wiki.debian.org/BluetoothUser/a2dp#Workaround_
2:_disable_pulseaudio.27s_bluetooth_in_gdm

which currently consists of adding the following
/var/lib/gdm3/.config/pulse/default.pa file:

#!/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

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?



--


Reply to: