Created attachment 63608 [details] screen-shots about the different mentioned stages Version: unspecified (using KDE 4.7.1) OS: Linux Hello, my Bluetooth adapter is Linux compatible and it works pretty well, but usually Bluedevil does not detect it after resume from suspend to RAM. I attach a various screen-shots about the different mentioned stages. Reproducible: Always Steps to Reproduce: 1) Bluedevil detects the adapter and it works well (stage1). 2) I suspend to RAM. 3) I resume computer, then Bluedevil applet has disappeared (stage2). 4) I run bluedevil-monolithic, then the applet appears, but it does not detect the adapter, it says "Bluetooth is off" (stage3), and if I click on it, says "No adapters found"(stage4). 5) I suspend to RAM again, and resume computer again, then I am again in stage3 and stage4. 6) I suspend computer again, and resume computer again, then I am back to stage1 and all works well again. Actual Results: 3) I resume computer, then Bluedevil applet has disappeared (stage2). 4) I run bluedevil-monolithic, then the applet appears, but it does not detect the adapter, it says "Bluetooth is off" (stage3), and if I click on it, says "No adapters found"(stage4). 5) I suspend to RAM again, and resume computer again, then I am again in stage3 and stage4. 6) I suspend computer again, and resume computer again, then I am back to stage1 and all works well again. Expected Results: After resume from RAM, Bluedevil applet shouldn't never disappear, and bluetooth adapter should be always detected. This happens in Bluedevil 1.1 and Bluedevil 1.2. This happens on Kubuntu and also in OpenSUSE. I need to test the behavior in other environments with other bluetooth tools (GNOME, Unity, etc..). Will it be kernel, blueZ, or Bluedevil related?
This looks like a dupe of https://bugs.kde.org/show_bug.cgi?id=277692 but this one looks better explained.
This is a known upstream bug in BlueZ, if you restart your bluetooth device you will see how this is fixed. as further proof, you can execute qdbus --system org.bluez and you will see no response (but a timeout) :/ Going to close this bug as upstream since it is a known issue and there is people working on it. Thanks for reporting, and if you thing that this is BlueDevil's fault don't hesitate to reopen the bug but I'm quite confident about what I said.
In kubuntu oneiric, I experience similar behaviour. However, "qdbus --system org.bluez" does not hang(just doesn't print anything about hci0). But, as described, restarting bluetooth ("sudo service bluetooth restart" in ubuntu) fixes it.