I'm seeing this too. My headphones go through a connect/disconnect cycle a few times and then quit. Unpairing and repairing does make it work. On Tue, Jan 30, 2018 at 1:47 AM, Vincent Petry <pvince81@xxxxxxxxxxxxxx> wrote: > Hello, > > On 01/25/2018 07:43 PM, Luiz Augusto von Dentz wrote: >> Hi Vincent, >> >> On Thu, Jan 25, 2018 at 4:44 AM, Vincent Petry <pvince81@xxxxxxxxxxxxxx> wrote: >>> Hello, >>> >>> I just joined the mailing list so can't directly reply to old messages, >>> so sending with same title. >>> >>> I'm experiencing the same issue as Robert here >>> https://www.spinics.net/lists/linux-bluetooth/msg73824.html, happening >>> on the same laptop Dell XPS 13 but with different sub-model 9333, but on >>> openSUSE Tumbleweed. >>> >>> It looks like the bluez component is in a wrong state when either >>> loading btusb with modprobe later on or resuming from suspend. The >>> workaround is to restart the systemd bluetooth daemon. I suspect that >>> plugging in USB bluetooth dongles would also have the same issue but I >>> don't have one to test. >> Does the system have any controller after resume? Does bluetoothctl >> report any device at all? > After resume from suspend, bluetoothctl sees the controller, yes and it > does report my usual three devices from the saved list. > > When I tell it to connect to the headset (which is turned on), I can > hear the headset beep shortly which is the signal for connection, but > then it disconnects again: > Attempting to connect to E3:XX:XX:XX:XX:XX > [CHG] Device E3:XX:XX:XX:XX:XX Connected: yes > Failed to connect: org.bluez.Error.Failed > [CHG] Device E3:XX:XX:XX:XX:XX Connected: no > > If I tell it to connect to my bluetooth watch it stays connected. > > Now I wanted to try accessing characteristics but the command > "select-attribute" has gone missing ? I also tried "help gatt" as it > seems to be a submenu but it says "Too many argumnets". Possibly another > bug in bluez ? (I can send a separate email for this one if you want) > > Anyway, I have a Python script that uses Dbus and said Python script is > able to connect to my watch and talk to it even in this state. > > So the bluez 5.48 regression seems to be specifically with headsets and > also with scanning/discovering. I don't have any other device types to > test with. > > The workaround is to restart the bluetooth service and enable bluetooth > afterwards. > > Please make sure to look at > https://bugzilla.suse.com/show_bug.cgi?id=1076898 for logs I posted. > > If you guys cannot reproduce the first regression I could try and bisect > bluez locally to find the breaking change. For this I need to know how > to set up bluez on my system after compiling. Is there any guide about > this ? Should I tell it to overwrite the existing libs and reboot or is > restarting the bluetooth service sufficient to make it use the newly > installed version ? > > Thanks, > > Vincent > >>> It used to work correctly before the upgrade from 5.47 to 5.48. >>> >>> See my original report here for details: >>> https://bugzilla.suse.com/show_bug.cgi?id=1076898 >>> Robert's report https://bugzilla.redhat.com/show_bug.cgi?id=1534857, >>> also confirmed by a third person. >>> >>> Please let us know if this is reproducible on your side or whether it's >>> an isolated case specific to our Dell hardware. >>> >>> Thanks, >>> >>> Vincent Petry >>> >>> >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in >>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
