Bug 295349

Can you check if your device is set as trusted in the Bluetooth systemsettings?

Also, can you check this with a live cd of Kubuntu 12.04 or another distribution with modern pacakges?

Thanks !

Yes, the mouse is trusted (I mentioned it in the report). As for 12.04, I will check that as soon as I get to that workplace.

I've upgraded to 12.04 and the problem still persists. Please, reopen.

Thanks for reply !

Can you test with Ubuntu 12.04 liveusb/livecd ? that will basically tell us whether it is a BlueDevil bug or rather a downstream bug.

Thanks !

Booting from a livecd/liveusb is rather complicated because the MacBook is not my personal laptop. 12.04 just got released, is there any difference to the livecd?

Anyway, I tried to boot from livecd and it didn't help. By default, the Bluetooth adapter is not visible and no bt devices attached. After making the adapter visible and manually searching and adding my mouse it got connected.

I said Ubuntu livecd with unity/gnome not with KDE, so we can know if the problem is in our side (KDE) or somewhere else.

Thansk for all the testing !

I have same problem.  OpenSUSE 12.1 with KDE 4.8.2, libbluedevil 1.9.2 and bluedevil 1.2.3.  Mouse is marked as trusted in KDE Control Panel.

Same question then, can you reproduce this bug pairing your mouse with GNOME's software? 
> I have same problem.  OpenSUSE 12.1 with KDE 4.8.2, libbluedevil 1.9.2 and
> bluedevil 1.2.3.  Mouse is marked as trusted in KDE Control Panel.

I'm asking this test because I doubt there is anything in the KDE side of things that would make this bug, we don't have a "Don't allow reconnect" flag or something of the kind.

Thanks !

Sorry, I didn't catch that you were speaking of original Ubuntu, not Kubuntu. In Ubuntu the situation is the same, by default the adapter is not visible, no bt devices attached, the mouse doesn't work until added.

>I'm asking this test because I doubt there is anything in the KDE side of things that would make this bug, we don't have a "Don't allow reconnect" flag or something of the kind.

Is it possible that some action should be done by KDE upon boot in order to connect the mouse? Who does the auto-connect? Are there any logs that I can provide to help?

Also, is there a quick fix? Can I create a script to force reconnect from the command line on startup? I tried hidd, it works for some time but eventually (probably, after the laptop sleeps) the mouse disconnects and it cannot be reconnected via KDE menus. Only disabling and re-enabling the bt adapter helps, then I can connect the mouse manually from KDE.

With Gnome, the Bluetooth mouse does not reconnect automatically after a power cycle.  This does seem to point to an underlying OS issue.  Additional information: bluez 4.99, hcidump 2.3.

Created attachment 72800 [details]
hcidump output

I have the same. Once connected mouse is working till reboot. After reboot the bluetooth tray icon displays mouse is connected, mouse turn on LED, but nothing works. hcidump output is attached.
I ran hcidump, turn on bluetooth and then turn on mouse.

Is this still reproducible with a more recent stack? Can anybody check with at least Kubuntu 12.10 or latest Fedora?

Thanks !

For additional info, I had a mouse that behave like this, now it is fixed (that's why I'm asking if it is working well now).

Closing the thread for lack of activity.

Please, please! if you are still able to reproduce this with latest BlueDevil and latest BlueZ 4 please feel free to reopen the bug.

Also, we are working hard to move to BlueZ5, that might fix your issue.

thanks for reporting !

Forgot to set it as resolved

Could you repoen this? I have the same problem under KDE 4.11.2, kernel 3.11.0-8, Kubuntu 13.10 beta 2. My bluetooth keyboard (MS Sculpt Mobile) connects no problem after restart/suspend but my mouse (MS Sculpt Comfort) does not. I have to repair it ever time.

I tried Fedora 20 alpha 1 (Gnome 3.10) and everything works, so it is likely a KDE issue. I also tried installing all the latest bluez tools and related packages. Nothing helps. I wonder if the gnome utilities work.

My headset does not auto connect on Mint 16 KDE.

I had the same problem on my MacBook Pro Retina 13" (`sudo dmidecode -s system-product-name` output: "MacBookPro10,2"), connecting a bluetooth mouse (Logitech M557).

When the mouse had beed disconnected, due to powercycling either the laptop or the mouse, it would apparently try to reconnect. This would show up in the bluetooth tray icon as well as the list of connected bluetooth devices as a flash of connected state. That is: It would appear to be connected for a brief second, but then appear as unconnected again. This would happen when jiggling the mouse or pressing its buttons.

However, the mouse now reconnects properly, after I ran `sudo hciconfig hci0 reset` as advised here: http://askubuntu.com/a/428369/3523

I have no idea what that command does or why it works :)

Oh, it looks like I was cheering prematurely. The `hciconfig reset`-trick makes things work until the next reboot. After a system reboot, the mouse would no longer reconnect automatically.

Please reopen this BZ. It's still an issue - I have to re-pair my mouse on every single reboot or resume from hibernate. I'm happy to provide any configuration or debugging information needed.

Fedora 20 (current)
Atheros Communications, Inc. AR3011 Bluetooth
bluedevil-2.0.0-0.13.36f0438agit20140630.fc20.x86_64
libbluedevil-2.0-0.9.rc1.fc20.x86_64
bluez-5.18-1.fc20.x86_64
bluez-libs-5.18-1.fc20.x86_64

Reopening based on recent comments.

I have the same behavior as Comment 21 and Comment 22, but my bluetooth speaker re connect without problems

After some research, I think I found the problem.

Using bluetoothctl to pair the mouse, it auto-reconnects perfectly after turning it off and on, after suspends, and after reboots. But using the KDE Bluetooth Device Manager to pair it, it does not reconnect.

Using bluetoothctl with the following instructions: https://wiki.archlinux.org/index.php/Bluetooth_Mouse#Bluez5_instructions , I get the following config file for my mouse at /var/lib/bluetooth/<computermac>/<mousemac>/info:
=======snip=======
[LinkKey]
Key=<long hexadecimal string>                                                             
Type=5                                                                                           
PINLength=0                                                                                      
                                                                                                 
[General]                                                                                        
Name=HP Touch to Pair Mouse                                                                      
Class=0x000580                                                                                   
SupportedTechnologies=BR/EDR;                                                                    
Trusted=true                                                                                     
Blocked=false                                                                                    
Services=00001000-0000-1000-8000-00805f9b34fb;00001124-0000-1000-8000-00805f9b34fb;00001200-0000-1000-8000-00805f9b34fb;

[DeviceID]
Source=2
Vendor=1008
Product=1100
Version=264
=======snip=======

However, if I use the KDE Bluetooth Device Manager, I get the following config file:
=======snip=======
[General]
Name=HP Touch to Pair Mouse
Class=0x002580
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=00001000-0000-1000-8000-00805f9b34fb;00001124-0000-1000-8000-00805f9b34fb;00001200-0000-1000-8000-00805f9b34fb;

[DeviceID]
Source=2
Vendor=1008
Product=1100
Version=264
=======snip=======

Two things are different between the two:
- Class is different (0x000580 vs. 0x002580).
- The KDE-created config file does not have the [LinkKey] section.

So the solution would be to make bluedevil do whatever bluetoothctl does.

I have had some good experience with manually supplying a PIN when connecting the mouse with KDE's interface. The PIN I supply is simply 0000. This seems to make reconnect work.

Actually, the pairing wizard is doing exactly the same as bluetoothctl (at least with Bluez 5, not sure about 4) so it's strange you would get different entries in /var/lib/bluetooth.
In any case, the latest Bluedevil will try to re-connect on startup/resume from suspend to the devices that were previously connected on shutdown/suspend, so this may fix the issue.

If you still have this issue in Plasma 5, please open a new bug.