Created attachment 350770 [details] emerge --info After my weekly update yesterday I ended up with no bluetooth device detected! The update was mostly kde-4.10.3 and some few packages including bluedevil and its libs. Symptoms: Blue devil didn't get started when booting neither when switch off/on the wifi switch. Starting it manually it "says" that no devices can be detected! hcitool scan and rfcomm -a didn't see any device either! module btusb is automatically loaded both when booting or switching on the wifi. Bluetooth is working fine in a previous update copy system on another partition!
If hcitool scan doesn't come up with anything, then it's not a bug with KDE, it's a bug elsewhere on the system.
I compared lots of things from "working" version system with current system including log files. Everything looks the same. So, I decided to emerge the previous version (1.3) of bluedevil and I have bluetooth again. In summary: bluedevil-1.3.1: hcitool scan shows nothing; lsusb and rfkill list both show the device. I DON'T HAVE BLUETOOTH. bluedevil-1.3: hcitool scan shows nothing; lsusb and rfkill list both show the device. I HAVE BLUETOOTH. May be bluedevil-1.3 should be put back in the tree.
I had the same thing, after I turned bluetooth off in the system tray (BlueDevil)... It worked again changing "mode off" to "mode on" in /var/lib/bluetooth/*/config, and /etc/init.d/bluetooth restart
Sounds like a regression on the KDE side from what I understand from these two comments; or at least, the regression should point out where the issue lies. Perhaps a diff could be ran between both versions; if that's too big, the user may opt to bisect the commits. If you think this should be assigned to somebody else, then please state to whom or assign it yourself; I don't see any indication why this is not a KDE bug, other than hcitool not working, but that doesn't seem to matter. If it really does matter, assign this bug to pacho@g.o; that is, if you consider this a bluez bug.
From a backup, I see that "mode" was set to "connectable". BlueDevil changes "mode" to "off", after which it can't be changed back. Rest of the file doesn't change. --- config ----- name gentoo-0 pairable yes onmode connectable mode connectable class 0x5a0100 ---
I did a diff between the two versions of bluedevil and most of them consisted in changing a method defaultAdapter by usableAdapter. This last has a "discovery" method. May be it uses the same process as hcitool to descover devices not finding any device! BTW, my log file has the following lines when starting bluetooth service (/etc/init.d/bluetooth): Jun 13 21:13:09 [bluetoothd] Bluetooth daemon 4.101 Jun 13 21:13:09 [bluetoothd] Starting SDP server Jun 13 21:13:09 [bluetoothd] Listening for HCI events on hci0 Jun 13 21:13:09 [bluetoothd] HCI dev 0 up Jun 13 21:13:09 [bluetoothd] input-headset driver probe failed for device ... Jun 13 21:13:09 [bluetoothd] input-headset driver probe failed for device ... Jun 13 21:13:09 [bluetoothd] input-headset driver probe failed for device ... Jun 13 21:13:09 [bluetoothd] input-headset driver probe failed for device <my device MAC> Jun 13 21:13:09 [bluetoothd] Unable to load keys to adapter_ops: Function not implemented (38) Jun 13 21:13:09 [bluetoothd] HCI dev 0 down Jun 13 21:13:09 [bluetoothd] Adapter /org/bluez/15770/hci0 has been disabled Jun 13 21:13:09 [bluetoothd] mce replied with an error: org.freedesktop.DBus.Error.ServiceUnknown, The name com.nokia.mce was not provided by any .service files I have emerged bluez with USE=debug, but no output messages so far after using hcitool scan!
Summary of last try: 1. Turn blutooth on using bbluedevil-1.3 or as in comment 3 2. emerge bluedevil-1.3.1 3. Reboot or just restart service bluetooth 4. Bluetooth works fine. 5. Turn bluetooth off either using bluedevil or switching off the device. 6. No more bluetooth from this point on. To recover I need to proceed as in comment3 i.e. changing "mode off" to "mode on" in /var/lib/bluetooth/*/config, and /etc/init.d/bluetooth restart Then I have bluetooth again. hcitool still doesn't find any device.
I'm not sure if it's the same problem, but I also noticed problems after upgrade to bluedevil-1.3.1 - disabling adapter via systray, actually turns it off + BT icon disappears. Only way to get it back is to issue "hciconfig hci0 reset". I've opened related bug on kde tracker some time ago @ https://bugs.kde.org/show_bug.cgi?id=319403 but no response yet. Related packages used: ksystraycmd 4.10.5 solid 4.10.5 solid-runtime 4.10.5 libbluedevil 1.9.3 bluedevil 1.3.1 Thanks to Dave for pointing me here.
Please test with bluedevil-1.3.2 libbluedevil-1.9.4 Is it still failing?
(In reply to Manuel Rüger from comment #9) > Please test with bluedevil-1.3.2 libbluedevil-1.9.4 Here the problem is gone, upgrading to these versions. Thanks!
(In reply to Manuel Rüger from comment #9) > Is it still failing? Upgraded to mentioned versions, but the problem persists here.
I think I have a fix, kind of, at least. KDE did indeed change something for the worse. Please go to System Settings -> Bluetooth -> Adapters. Is your device there with the "powered" box unchecked? If so, check that to re-enable it.
(In reply to Chris Reffett from comment #12) > I think I have a fix, kind of, at least. KDE did indeed change something for > the worse. Please go to System Settings -> Bluetooth -> Adapters. Is your > device there with the "powered" box unchecked? If so, check that to > re-enable it. Device is still there, ticking checkbox + hitting apply button re-enables adapter and BT icon re-appears in systray. This is way more convenient than issuing command in console as root, but still.. bluetooth icon disappearing from systray when disabling adapter is not something that was happening before bluedevil-1.3.1 update. I'll update related bug info @ KDE tracker. Thanks for info Chris.
There are substantial changes in bluedevil-2.0_rc1, any luck with that?
Upgrading to bluedevil-2.0_rc1 does seem to fix all the issues I had.
That's good to hear. It should be stabilised in the near future too.
net-wireless/bluedevil-2.0_rc1 is stable on amd64, x86. So i guess this can be closed as ppc/ppc64 is almost dead in desktop env
