Los auriculares Bluetooth funcionan bien hasta que se duerme. Sin embargo, después de reanudar el sueño, parecen conectarse por un breve momento antes de desconectarse. En blueman, el error dado es Recurso temporalmente no disponible. Este problema surgió solo después de actualizar a 18.04 LTS.
Aquí está la salida del terminal para lsusb:
Bus 001 Device 002: ID 8087:8001 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 1bcf:0002 Sunplus Innovation Technology Inc.
Bus 002 Device 003: ID 04f2:b477 Chicony Electronics Co., Ltd
Bus 002 Device 002: ID 0a5c:21f1 Broadcom Corp. HP Portable Bumble Bee
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Mejor respuesta
actualizar bluez a>=5.28.2
18.04 se envía con un paquete buggy bluez por ahora; la versión más nueva está disponible en este PPA:https://launchpad.net/~bluetooth/+archive/ubuntu/bluez:
sudo add-apt-repository ppa:bluetooth/bluez
sudo apt install bluez
solución alternativa para el subprograma Bluetooth defectuoso (¿específico de Unity?)
Este es probablemente el problema que mencionó @solstice:el subprograma de menú BT no me permite habilitar Bluetooth después de reanudar la suspensión. No importa si el interruptor de palanca está apagado o encendido, el ícono BT está deshabilitado y la salida rfkill no cambia:
$ rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
12: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
Puede alternar BT manualmente ejecutando (sustituya su propia ID):
rfkill block 12
rfkill unblock 12
y el subprograma BT debería recogerlo correctamente ahora. En este punto, debería poder conectarse a sus dispositivos. Por ahora, lo he pirateado usando un script que hace esto automáticamente después de reanudar:
$ cat /lib/systemd/system-sleep/bt
#!/bin/sh
case $1 in
post)
sleep 5
rfkill block `rfkill list | grep hci | cut -d: -f1`
sleep 1
rfkill unblock `rfkill list | grep hci | cut -d: -f1`
;;
esac
El número de identificación junto a hci0 en la salida de la lista rfkill parece incrementarse después de cada suspensión/reanudación. Deshabilitar/habilitar BT usando el menú BT debería cambiar la salida ("bloqueado suave:sí" para BT deshabilitado a través del menú), pero no es así. Mi conjetura es que el applet recuerda la ID de dispositivo incorrecta y, por lo tanto, intenta habilitar un dispositivo que ya no existe.
Relacionado:¿Fuentes de software de copia de seguridad?