Bug 228234

The same problem on Dell Latitude X-1 notebook. Similar workaround - switch off Bluetooth device from keyboard, then switching on and it works.
It seems there are also  more bugs in Bluetooth support. For example it is not possible set up the Discoverable mode from Yast - it works only by the help of command line - for example: hciconfig hci0 piscan.

(In reply to comment #0)
> I have an USB bluetooth device, D-Link DBT-122 which is permanently connected
> to my computer. After login to KDE desktop the bluetooth icon in the panel
> shows for a couple of seconds, then it disappears and leave an empty space in
> between the other icons.
So far i was not able to reproduce this with my bluetooth devices.
Maybe the hcisocket communication is broken... have to take a deeper look there.


(In reply to comment #1)
> It seems there are also  more bugs in Bluetooth support. For example it is not
> possible set up the Discoverable mode from Yast - it works only by the help of
> command line - for example: hciconfig hci0 piscan.
This is a known issue. The bluetooth device disappear after few seconds and is not discoverable. It is still connectable. The integration of changing the settings of the bluetooth device is missing in the KDE desktop. I plan to change this ASAP.

Same here. I can reproduce this with a Longshine USB dongle.

It is very easy to reproduce this problem. Tested on 3 machines (Laptop Dell Latitude X-1 and 2 desktop PC's) with different hardware and configuration. Please, try login to KDE after machine boot (kbluetoothd or bluetooth-applet must be in kicker panel before this test, of course...).

Seems it is more general problem. Similar problems with kbtobexclient, bluetooth-applet, gnome-obex-server...Not only after KDE login - in Gnome also.

I get the same bluetooth problem on a Sony VGNSZ3VWP/X (bluetooth is integrated). In dmesg I did notice it says hci_cmd_task: hci0 command tx timeout (just once). As others note if you stop and restart bluetooth it works fine (I can do this either by turning on/off the button or spicctrl -l0 then -l1)

i have exactly the same error so i confirm the bug. but it can by more general because i can't get my bluetooth headset to work and I'm using the same start script for it as in suse 10.1 where it worked

Can you try to reproduce the problem and check if the bluetooth service is started at all:
`rcbluetooth status`

It seems to me that the issue is independent of the bluetooth device and is the consequence of #230728

This bug is reproduced at every login so reproducing is easy..

rcbluetooth status ouput:

Checking service bluetooth (enabled) :
      hcid  (activated)
      hidd  (activated)                                              running
   hid2hci                                                           unused
      sdpd  (activated)                                              running
       opd                                                           unused
    rfcomm  (activated)
      pand                                                           unused
      dund                                                           unused

Somehow the hcid got not started...
Can check if you got any error if you start hcid by hand: 
`hcid -n`

hcid -n as normal user:
bash: hcid: command not found

hcid -n as su:
hcid[24897]: Bluetooth HCI daemon
hcid[24897]: syntax error line 24
hcid[24897]: Register path:/org/bluez fallback:1
hcid[24897]: HCI dev 0 registered
hcid[24897]: Register path:/org/bluez/hci0 fallback:0
hcid[24897]: HCI dev 0 already up
hcid[24897]: Device hci0 has been added
hcid[24897]: Starting security manager 0
hcid[24897]: Device hci0 has been activated

then nothing more, prompt is not back. The icon is still invisible. After a few minutes I aborted in the terminal with Ctrl+C, the output then was:
hcid[24897]: Unregister path:/org/bluez/hci0
hcid[24897]: Unregister path:/org/bluez
process 24897: Applications must not close shared connections - see dbus_connection_close() docs. This is a bug in the application.
  D-Bus not built with -rdynamic so unable to print a backtrace
Avbruten (SIGABRT)

We found the actual problem.

If the device is plugged in/activated while booting, then udev triggers the init script of bluetooth. The start of hcid will fail because dbus is not running in this early stage of boot and the hci daemon aborts.

Thats why also bluez-gnome and any other hcid depending application doesn't work.

I will prepare a fix for the bluetooth init script. In meanwhile a simple replug/reenable of your bluetooth dongle/device should help.

*** Bug 230728 has been marked as a duplicate of this bug. ***

I prepared a fix for the bluez-utils package, which get discussed on the developer mailing list of bluez. If you don't  want to wait until the fix got checked in upstream and the YOU update is prepared.. you can find the fixed bluez-utils package in my buildservice home project:

http://software.opensuse.org/download/home:/dgollub/openSUSE_10.2/

Please, let me know if this still doesn't fix anything...

The fix seems to work fine for me. As far as I'm concerned this bug can be changed to "fixed".
Great work Daniel, thank you!

CC'ing AJ for requesting a swampid.

Packages prepared and ready for checkin.

Yes, it also works for me, thanks!

Confirm it works for me too. Thanks!

Tested. It works fine. Thank you.

Approved: MaintenanceTracker-7913

released

Thanks for testing!

I'm sorry, but where are the released and fixed packages? I'm using all repositories (always updated) from opensuse.org for 10.2 and I still got this problem.

i have for example configured YOU with source http://ftp4.gwdg.de/pub/suse/update/10.2 and have automatically gotten this with the opensuse-updater:
rollo:~ # rpm -q bluez-utils
bluez-utils-3.7-29.2
rollo:~ # rpm -q --changelog bluez-utils|head -8
* Di Jan 16 2007 - dgollub@suse.de
- fixed "typo" in previous update

* Di Jan 09 2007 - dgollub@suse.de
- Fixed start of hci daemon when no dbus daemon is running
  (bug #228234, #230728)
- Fixed odp cleanup in init script
  (/var/lib/bluetooth/opd/ instead of /var/lib/bluetooth/)

and this one obviously works for me.

Note that in FACTORY this bug might still be present, since we are working with upstream on a different fix. Just use "chkconfig bluetooth on" as a workaround there.

I added this url to smart and it works fine now, thanks.